鉴于我有一个基于AJAX的搜索字段对用户输入做出反应，通过AJAX从后端请求搜索结果，在搜索字段下方的下拉列表中显示结果，允许通过光标键浏览搜索结果并对{做出反应{1}}以智能方式按键。
由于当前基于Backbone的组件在很多方面被打破，我想使用esc和React架构来重新实现该搜索组件。
在计划过程中，我的组件至少有10个不同的状态（可能更多），它必须对用户输入触发的Flux作出反应，并且actions由异步服务器响应触发。
问题1 ：我应该在actions而不是父组件中建模所有状态吗？这意味着，每个用户输入都会更改存储状态，例如store，:searchQuery，我的父视图组件会对该状态更改做出反应吗？
问题2 ：或者我应该在父组件本身中建模所有状态并完全省略:searchResults，store和dispatcher？
问题3 ：事实证明，独立于处理actions或父组件本身的状态，组件本身至少可以有10种不同的状态，并且应该只有是允许的一定数量的过渡。通常，我在这里引入一个statemachine实现，建模所有store并允许:states并在每次:transitions收到操作时执行转换，或者调用回调方法父组件。在组件中store之间处理React way和states的正确transitions是什么？
问题4 ：对于Javascript来说，最先进的states实现是哪个？到目前为止，我已经看过reflux，但我不确定，这是我的毒药。
我愿意接受各种建议。
答案 0 :(得分：1)
我正在使用React在flux中构建一个类似的组件，过去我曾与Backbone广泛合作，所以我希望能给你一些见解。
我的猜测是，您的Backbone解决方案在您的搜索视图中有一个本地模型，该字段在更新字段时构建:searchQuery。在ajax回调中，您很可能只是直接更新了:searchResults。
<强> 1-2：
使用flux最终会有更多的样板代码，但根据我的经验，如果我不建立商店，我总是后悔。话虽如此，我会为SearchStore创建一个:searchResults，并将:searchQuery保持在父组件的状态中。
这样，当您准备好调用搜索时，您可以使用视图操作SearchViewActions.getSearchResults(:searchQuery)进行ajax调用，并在回调调用SearchServerActions.receiveSearchResults(:searchQuery, :searchResults)并更新商店。然后，您的结果组件可以监听Store更改，并在看到更改时调用SearchStore.getResults()。这有助于模块化两个子组件，其中选项 2 会紧密耦合这两个组件，并使外部组件重用变得更加困难。
第3：
我喜欢您的状态机解决方案，您可以询问是否允许进行转换并返回一组要更新的属性，或者根据该信息执行调用setState({...})的函数。
<强> 4
Reflux看起来很棒，因为它似乎减少了样板。然而，回流可能会或可能不会与库存Flux一样好。
让我知道它是怎么回事，因为你的策略可以帮助我改善我的结构。