5

鉴于我有一个基于 AJAX 的搜索字段，它对用户输入做出反应，通过 AJAX 从后端请求搜索结果，在搜索字段下方的下拉列表中显示结果，允许通过光标键导航搜索结果并对按键做出esc反应智能方式。

由于当前基于 Backbone 的组件在很多方面都被破坏了，所以我想重新实现该搜索组件，使用React可能还有Flux架构。

在规划过程中，我的组件至少有 10 种不同的状态（甚至更多），它必须对actions用户输入actions触发以及异步服务器响应触发做出反应。

问题store1：我应该在 a而不是父组件中建模所有状态吗？这意味着，每个用户输入都会更改存储状态，例如:searchQuery，:searchResults而我的父视图组件会对该状态更改做出反应？

问题2 ：或者我应该对父组件本身的所有状态进行建模并完全省略 astore和？dispatcheractions

问题3 ：独立于处理状态store或父组件本身，事实证明，组件本身至少可以有10种不同的状态，并且应该只允许一定数量的转换。通常，我会在这里引入一个状态机实现，对所有模型:states进行建模，:transitions并在每次接收到一个动作store或在父组件中调用回调方法时执行转换。在组件中处理这些以及在这些之间的正确React way处理是什么？statestransitionsstates

问题4：哪个是最先进Flux的 Javascript 实现？到目前为止我已经看到了反流，但我不确定，那是我的毒药。

我对这里的各种建议持开放态度。

4

1 回答 1

1

我现在正在构建一个类似的组件，React并且flux我过去曾Backbone广泛使用过，所以希望我能给你一些见解。

我的猜测是，您的Backbone解决方案在您的搜索视图本地有一个模型，该模型:searchQuery是在更新字段时构建的。在 ajax 回调中，您很可能只是直接更新了:searchResults.

1-2：

最终会有更多的样板代码，但根据flux我的经验，如果我不开始建立商店，我总是会后悔。话虽如此，我会SearchStore为 the制作一个:searchResults并保持:searchQuery父组件的状态。

这样，当您准备好调用搜索时，您可以使用视图操作SearchViewActions.getSearchResults(:searchQuery)来进行 ajax 调用和回调调用SearchServerActions.receiveSearchResults(:searchQuery, :searchResults)并更新存储。然后，您的结果组件可以侦听Store更改并SearchStore.getResults()在看到更改时调用。这有助于模块化两个子组件，而选项2将紧密耦合这两个组件并使其更难用于外部组件重用。

3：

我喜欢您的状态机解决方案，您可以只询问是否允许您进行转换并返回一组要更新的属性或一个函数以setState({...})根据该信息执行调用。

4：

回流看起来很棒，因为它似乎大大减少了样板。然而，回流可能会或可能不会像股票一样好Flux。

让我知道进展如何，因为您的策略可能会帮助我改善我的结构。

于 2015-03-15T16:42:45.247 回答