什么时候修改反应类组件中的状态变量是可以接受的，什么时候调用一个动作来改变状态变量是合适的？
最佳实践是什么？更改反应类组件中的状态变量会违反 Flux 约定吗？
这个问题没有正确的答案，因为它是上下文相关的，并且通常在很大程度上取决于您的代码。但是，根据个人经验，我敦促您不要使用状态变量。在没有子组件的组件中可能是可以接受的，但仍然很容易在组件中产生许多逻辑，这些逻辑并不严格关注表示（阅读：渲染）。
我的观点：将你的状态和数据保存在存储中，让组件变得非常愚蠢，只处理渲染和执行动作。此方法使应用更易于测试并确保可读性。
我会考虑在相关数据本地化并与组件紧密耦合的情况下使用组件状态，这意味着它仅与组件本身相关，并且将来不太可能被应用程序的任何其他部分需要。当然，您不可能预测所有内容，因此当有疑问时，最好将其视为"应用程序状态"并将其放在应用商店中。
表单输入是可能适用的一种情况。例如，典型用户注册或登录表单的输入字段的瞬态不太可能与应用程序的其他部分相关。数据仅用于呈现组件本身和进行提交数据的 API 调用，因此很自然地将窗体的状态视为窗体的一部分，并使用组件状态来存储它。
一个反例是动态搜索的输入，该搜索在单独的组件中筛选列表，其中列表应在用户开始键入后立即开始响应。在这里，输入的瞬态应被视为应用程序状态，并保存在其他组件可以访问它的存储中。
您应该只使用操作来写入存储，因此，如果您的状态是存储中内容的直接表示形式，则只应使用操作来更新它。 有很多选择，但 https://github.com/HubSpot/general-store 附带了一个mixin，可让您将商店数据直接绑定到状态。
因此，在您的组件中，您可以执行以下操作：
mixins: [
GeneralStore.StoreDependencyMixin({
user: UserStore.get()
})
]
这会将该存储中的任何数据绑定到状态中，当存储更新时，您的组件也会更新状态。 在许多情况下，组件具有一些本地状态，例如：
getInitialState: ->
modalOpen: false
openModal: ->
@setState
modalOpen: true
遇到过一些情况，我想使存储中的数据不同步，以便我可以跟踪更改，并可能在用户保存之前进行重置并列出对模型的更改，而我这样做的方式是复制存储模型的状态并直接更改它， 然后在保存时使用操作命中保存终结点，然后将新保存的模型传递到存储中，这将更新本地（不同步）副本和存储本身的主要事实来源。