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