如果该示例可以帮助我理解以下问题的答案，我将非常高兴： 您是否应该将Flux / Redux商店用于在整个应用程序生命周期中不太可能发生变化的数据？如果您的应用程序中的大多数数据都是这样的，您是否应该费心使用flux / redux商店？
我在标题中提出这个问题，因为绝大多数应用程序似乎与我的类似（如果它更复杂），如下所述。我以某种方式将Redux视为一个专为内部数据变异的应用而设计的框架（因此Redux教程中的大量反例）。
在我的情况下，我的应用程序的第一个屏幕将提示用户从列表中选择一个酒店。一旦选定，将显示特定于所选酒店的菜单结构（通过响应非常容易），从对服务器的api响应创建。一旦选择了酒店，它就不太可能被改变，但可能，在这种情况下，将加载一组全新的菜单。应用程序的其余部分只是通过表单提交将数据推送到服务器。以及来自服务器的用户收据确认。
答案 0 :(得分：3)
假设您有一个看起来像这样的组件树。 Component A是根。 Component G中有一个按钮。
Component A - ＆gt; Component B - ＆gt; Component C - ＆gt; Component D - ＆gt; Component E - ＆gt; Component F - ＆gt; Component G
现在，让我们假设您有另一个组件Component K，它嵌套如下：
Component A - ＆gt; Component H - ＆gt; Component I - ＆gt; Component J - ＆gt; Component K
Component K是一个简单的视图，它接受一个prop并使用该prop的值呈现span标记。 Component G包含一个按钮，单击该按钮可更改Component K呈现的道具的值。
现在，React-without-Flux的方法是让Component A拥有状态并将其作为支柱传递给Component K。 Component A也会有一个修改该状态的方法，并将对该函数的引用作为道具一直传递到Component G。
如果你只做一次这听起来不是那么糟糕，但如果你有几十个状态变量怎么办？如果您的组件变得更嵌套怎么办？您的控制器视图变得非常难以管理，并且您将把几十个道具传递给甚至不会使用这些道具的中间组件（仅将它们传递给他们的孩子）。
Flux允许您降低控制器视图的复杂性。您的控制器功能可以放在单独的模块中，这些模块可以导入到需要使用它们的组件中。需要访问状态的组件可以订阅包含该状态的商店。
就我而言，这是使用Flux模式的主要原因。