免责声明
亲爱的读者！ 如果您不知道React和Redux是什么，那么进一步阅读毫无意义，进一步的技术废话。 我认真地理解了本文的目的，要求使用这些库-尽管我会尽力写清楚，但本文并非入门级。 这是基于实践的个人经验和见解。
使用Redux有什么问题？
然后我决定写，但是在我的项目和成千上万的项目中使用redux到底有什么问题？ 自2016年4月（三年）以来，我一直在编写react / redux应用程序。 现在已经发现一些有趣的东西了……然后有讲座和报告，特别是针对初学者的，但是没有成年人回头，也没有回顾。 同时，有人将星号放入检查“不是一个小时13小时”的程序包中，我将打破流行的刻板印象。
但是不需要redux！
你说，在某些方面你是对的。 自2018年以来无法使用-互联网上有大量关于此主题的文章，但是到目前为止，由于获得了“不使用”，因此获得了一个集体农场，下面将清楚其原因。 替代方案的数量超出规模，甚至更大。
我们使用Redux，因为它是公认的标准（至少对于反应而言），所以Redux的可预测性和可靠性对我们很重要。 但是我们真的很想念它
认领
可能是的，要弄清楚这些要点是什么，您首先需要根据自己的意愿回到过去，扎根，即打开光荣的redux的文档并阅读假设。 我只会考虑其中的第一个。 如果您感兴趣，请分享评论，我将分析更多要点。
真理的唯一来源...
在这里我们伏击。 当然，它说可能只有一个故事，redux以此方式声明其与磁通架构的区别。 但是，如果从更宽泛的角度来看：在实际项目中是否遵守规则？ 你会说：很。 我声明（声明）1面，我将其转移到提供者，然后...
从技术上讲，该过程已正确描述。 但是我可以说，人们容易遭受感知，逻辑的扭曲，而且由于程序员仍然是人……嗯，您了解我的目标（如果您不理解，程序员容易遭受感知，逻辑等的扭曲）。
这里的主要变形是，我和我的许多同事一样，都习惯于这样一个事实，即如果我们不将术语“存储”用于除redux之外的其他任何事情，那么就没有其他人了。
反应来了
一种被称为内部状态的技术特征就是要吐出这种假设。 它只是在任何方便的地方创建一个内部状态类型的存储。 有一个组件-存在一种状态，该状态具有用于更新和影响该组件的机制。 使用上的差异（存储状态，更新和广播更改）几乎是看不见的。 您可以反对：不清楚为什么您不喜欢组件状态。 他不喜欢编辑，他们怎么能被比较！ 好，内部存储什么标志。
请理解，本质与您重命名项目的事实无关。 星期一有大锤，这不是星期几。 是的，每个星期一都很辛苦，其他日子和大锤都比较容易。 但是，从名字上来说，大锤并没有停止成为打击乐器。
Redux的规模和状态反应组件的规模不同，但是今天使用的本质是其中之一。
我将以这种方式进行解释：在大多数情况下，来自组件内部状态的数据通过props传递给子级，但是，无论它多么明显，redux数据在与react集成时，也会通过props进入组件。 从接受道具的组件的角度来看，外部没有关系。 也就是说，对于最终用户-该Redux存储，该内部状态-是相同的。
同样，此内部状态可能不依赖于声明该内部状态的组件的属性。 然后，我们得到隔离，使这种内部状态的存储量超出您的想象。
为了使其真正处于内部，它应该只影响声明它的组件，而不会给子组件造成泄漏。 有困难吗？ 相当多，因为其含义几乎完全消失了。 这是内部状态是商店的另一个迹象。 毕竟，我们只是从“存储状态，更新和广播更改”的目的中删除了一点，即广播更改。 一切，状态迷失了。
也就是说，具有内部状态的主要问题是，它与redux竞争数据，从长远来看会丢失并废弃。 我们有各种各样的技术，例如提升状态（这是在需要主机元素的兄弟时，因此状态部分以及使用它的所有逻辑都被带到了父级，花费了大量时间重写和测试工作逻辑），等等。在改进和很多喜悦中。 这就是在开发阶段破坏我们软件的所有噪音。 我们还没有达到销售量，但是软件已经是那样了。
也就是说，对于所有的迹象和问题，我们不仅有一个故事，而且还有许多与此有关的问题。 最后一件事可能是：
我也喜欢redux，因为它具有那种devtools。 当我开始时，我们使用了一个记录器，该记录器简单地合并了所有操作，但是没有给出正在发生的事情的完整情况。 现在-这是主要的助手和朋友。 在React上，他们也有代表。 通常，devtools是任何pubsub远离Redux的原因。 就像一只蓝鲸的蚂蚁。
问题 （没有DNA证明）：
- 通过react devtools更改内部状态有时不会导致更新或所需结果-我在与redux集成时犯了错误。
- 内部状态中断了redux devtools中的timetravel。 由于具有内部状态架构，因此无法通过redux架构使用具有时间旅行的超级功能。 内部状态只是不关心redux的变化，它有自己的状态。 Timetravel不能解决问题。 有些元素根本就不会更新，部分更新等。所有这些具有异步代码同步功能的史诗无处不在。
一个例子，当然是从实践中吸取的
您正在为您开发一个新项目，或者您的同事在一年前编写了一些功能，现在您需要对其进行扩展。 通常，需要完成别人的代码。 您开始调查，并了解编辑器中没有数据。 代码中没有任何操作，reduce可以存储所需的数据。 然后，您将开始通过组件树进行搜索，以寻找最有价值的东西，甚至找到它们（!!!）几块。 您问同事，但是答案是标准的：我不记得写信给州更快，我们没有时间等等。 您去了源头了解到它的当前状态不涉及修订。 您正在重写经过测试的有效代码，以进行更改并添加新功能。
内部状态形式的有害替代品的存在确实是肮脏的事。 毕竟，它现在很便宜，而且一年后发生的事情都没有关系。隐喻很少
它看起来像不好的食物-看起来又好吃又便宜，但是一年或三年后-胃肠道不再服从并过着自己的生活。 您花费大量的时间和金钱来恢复以前的健康状况，但并不总是能成功。
Redux和React Internal State是大型企业和小型企业的
竞争者之一。 主要产品是数据和影响力。 软件是其产品的消费者。 有很多类比，但是本质保持不变-开发软件时-我们不需要竞争。
我们是程序代码的“独裁者”，任何竞争都应被压制，自由市场应被禁止，计划经济和国家垄断应主导消费者。哎呀，有些事让我感到厌烦。 总的来说，一切都应按计划进行。 我们拥有冲刺，发布和更多内容，并且该软件具有有限的成本，并且存在生命周期/进入市场。 这非常重要，我们不能容忍船上的骚乱和图书馆的起义。
结论很简单。
不要将其他存储库与redux一起使用。 异常只能使情况非常孤立。 例如，原则上在没有相应层的情况下不受Redux控制的组件也不会影响它。
例子
我在一个分支中开发了独立模块，然后在另一个分支中重构了商店-通常，我管理商店和状态的方法是一个单独的发布主题。 我开始重构模块，但是在编写模块的开始和结束时，都重构了测试，向导没有消失。 重构很大，需要计划周到的解决方案-通常，您不能只接受并重构。
因此，了解商店中即将发生的变化后，我没有使用它来开发新功能。 这将有时会增加更新废弃的重构和测试的成本。
我所做的：我注册了最少的数据。 数据及其结构没有受到重构的影响，生成它们的代码也受到了破坏，保存等。我没有向编辑器写入任何字节。 我检查用户是否已登录以及其他几个字段。
对于我的需求，我使用通道和简单的API来清洗PubSub。 是的，是的，pubsab。 缺乏正常的痛苦。 时间旅行-痛苦。 通常，我计划以devtools的形式编写chrome扩展，并且有可能在github上发布重新实现作为redux的竞争对手。 我对redux有很多抱怨，我不会在本文中提出，但是PubSub实际上没有。 除了我还记得redux logger的事实...
因此，模块具有自己的存储，与服务器的连接。
也就是说，redux根本不影响模块，实际上不影响此存储（预订中只有三个字段），但是模块和PubSub完全不影响redux。 这种分离不包括竞争。
问题“在哪里存储数据？” 在开发模块时，我从未遇到过。 但是当涉及到redux与内部状态时，这个问题几乎总是不断出现。 我决定一劳永逸地回答这个问题。
我的架构意见是：
如果将数据存储在redux中（全部，甚至是“内部”），如果将其作为主存储库连接到您的react-project，请不要使用会与其竞争的存储库。 这将提高该库及其devtools的可靠性和影响力（逐步跟踪和跟踪所有数据可加快开发速度并加快可能出现的问题的查找-同步更改更陡峭，更容易异步）。
也许值得添加一个完全将内部状态排除在开发之外的库？ 还是例如用redux的选择替换内部状态？ 我从一年前开始写一篇，完成了90％，甚至发表了一份报告。 你说什么 需要那些吗？
我希望你喜欢这个笔记:)