如何处理 React / Flux 组件中的状态转换

How to handle state transitions in a React / Flux component

本文关键字：组件 Flux 转换状态 React 何处理处理更新时间：2023-09-26

鉴于我有一个基于 AJAX 的搜索字段，该字段对用户输入做出反应，通过

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，也可能不如库存。

让我知道它是怎么回事，因为您的策略可能会帮助我改善我的结构。