如何处理Flux& ;;中的非视图改变操作React.js [英] How to handle non-view-altering actions in Flux & React.js
问题描述
在Flux中，每个动作都应由调度员处理。
In Flux every action should be handled by the dispatcher.
如何不改变视图或标记的操作，例如将此元素滚动到视图中？处理这种情况的流量方式是什么？绕过调度员？或者在调度程序中处理它而不涉及商店或组件？
What about an action that doesn't alter the view or the markup, such as "scroll this element into view"? What is the "Flux-way" of handling such a scenario? To by-pass the dispatcher? Or to handle it in the dispatcher without involving the stores or the components?
推荐答案
Flux更多的是关于应用程序状态管理，以及完全没有关于在视图中呈现哪些组件的细节。那是React的领域。 Flux只是假设您有某种反应性视图层 - 通常是React。
Flux is really more about application state management, and is not at all about the details of what components are rendered in the view. That's the domain of React. Flux simply assumes you have some kind of reactive view layer -- usually that's React.
应用程序状态与组件状态不同。应用程序状态是需要在多个组件中知道的。对于组件状态，React的 this.state 是完全足够的。输入组件是可能需要它的一个很好的例子。
Application state is not the same as component state. Application state is something that needs to be known in multiple components. For component state, React's this.state is perfectly adequate. An input component is a good example of something that might need this.
所以在你的情况下，如果只有一个组件需要知道滚动位置，那么可能没有将该状态移至Flux Store的好例子。但是，只要需要在多个组件中知道 - 特别是树的不同分支中的组件 - 您可能希望在商店中管理该状态。
So in your case, if only one component needs to know the scroll position, there may not be a good case for moving that state to a Flux Store. But as soon as that needs to be known in multiple components -- especially components in different branches of the tree -- you probably want that state being managed in a Store.
您提出的另一个问题是Flux Actions的作用。 Flux应用程序始终使用Actions作为数据流的来源。这样做有很多很好的理由：稳定的应用程序状态，保持应用程序对新功能的弹性，使其易于推理，撤消历史记录，重新构建应用程序状态，无状态视图组件等。
The other issue your question raises is the role of Flux Actions. A Flux application always uses Actions as the origin of the data flow. There are a lot of good reasons for doing this: stable application state, keeping the app resilient to new features, keeping it easy to reason about, undo history, reconstitution of application state, stateless view components, etc.
有时人们希望编写尽可能少的代码，他们使用组件之间传递的回调来改变父组件中的 this.state 调度新动作以通过Flux数据流。我发现这是混合应用程序的视图和状态管理层，虽然权宜之计，但这可能会导致很多麻烦。从长远来看，它不是很灵活，因为现在状态与这几个组件耦合在一起。从长远来看，从一开始就建立一个Flux数据流要简单得多，而且对新功能更具弹性。也就是说，它还需要更多的代码投资。
Occasionally people want to write as little code as possible and they use a callback passed between components to change this.state in the parent component instead of dispatching a new action to go through the Flux data flow. I find this to be mixing the view and state management layers of an application, and while expedient, this can lead to a lot of headache. It isn't very flexible in the long run, because now the state is coupled to these few components. Building up a Flux data flow from the start is much simpler in the long run, and much more resilient to new features. That said, it also requires more investment in code up front.
这篇关于如何处理Flux& ;;中的非视图改变操作React.js的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
