flux_Flux建筑模式简介

最新推荐文章于 2022-07-03 21:01:58 发布

cumi6497

最新推荐文章于 2022-07-03 21:01:58 发布

阅读量158

点赞数

文章标签： java python 设计模式大数据数据库

原文链接：https://www.freecodecamp.org/news/an-introduction-to-the-flux-architectural-pattern-674ea74775c9/

版权

flux

Discover Functional JavaScript was named one of the best new Functional Programming books by BookAuthority!

“发现功能JavaScript”被BookAuthority评为最佳新功能编程书籍之一 ！

Flux is an architectural pattern proposed by Facebook for building SPAs. It suggests to split the application into the following parts:

Flux是Facebook提出的用于构建SPA的建筑模式。建议将应用程序分为以下几部分：

Stores
专卖店
Dispatcher
调度员
Views
观看次数
Action / Action Creators
动作/动作创作者

商店 (Store)

Store manages the state. It can store both domain state and user interface state.

商店管理状态。它可以存储域状态和用户界面状态。

Store and state are different concepts. State is the data value. Store is a behavior object that manages state through methods. In the case of managing books: the book list is the state and BookStore manages that list.

存储和状态是不同的概念。状态是数据值。 Store是一个通过方法管理状态的行为对象。在管理书籍的情况下：书籍清单是状态，而BookStore管理该清单。

A store manages multiple objects. It is the single source of truth in regards to those specific objects. In an application there can be many stores. For example: BookStore, AuthorStore, UserStore.

商店管理多个对象。对于那些特定的对象，这是真理的唯一来源。在一个应用程序中可以有许多商店。例如：BookStore，AuthorStore，UserStore。

There are no setter methods on the store. You can only request state change by passing an action to the dispatcher.

商店中没有设置方法。您只能通过将操作传递给调度程序来请求状态更改。

A store listens for all actions and decides on which of them to act. This usually means a switch statement. Once the store has made the state changes, it will emit a change event. The store is an event emitter.

商店会监听所有动作并决定要采取哪种行动。这通常意味着使用switch语句。商店更改状态后，将发出更改事件。该商店是一个事件发射器。

Stores don’t take other stores as dependencies.

商店不将其他商店作为依赖项。

调度员 (Dispatcher)

Dispatcher is a single object that broadcasts actions/events to all registered stores. Stores need to register for events when the application starts.

调度程序是一个单一对象，可将动作/事件广播到所有已注册的商店。应用程序启动时，商店需要注册事件。

When an action comes in, it will pass that action to all registered stores.

当一个动作进入时，它将把该动作传递给所有注册的商店。

视图 (View)

View is the user interface component. It is responsible for rendering the user interface and for handling the user interaction. Views are in a tree structure.

视图是用户界面组件。它负责呈现用户界面并处理用户交互。视图以树结构表示。

Views listen for store changes and re-render.

视图侦听商店更改并重新呈现。

Views can be further split in Presentation and Container Views.

可以在“演示”视图和“容器”视图中进一步拆分视图。

Presentation views don’t connect to dispatcher or stores. They communicate only through their own properties.

演示视图不会连接到调度程序或商店。它们仅通过自己的属性进行通信。

Container views are connected to stores and dispatcher. They listen for events from stores and provide the data for presentation components. They get the new data using the stores’ public getter methods and then pass that data down the views tree.

容器视图已连接到商店和调度程序。他们侦听来自商店的事件，并为演示组件提供数据。他们使用商店的公共getter方法获取新数据，然后将这些数据向下传递到视图树中。

Container views dispatch actions in response to user iteration.

容器视图调度响应用户迭代的操作。

动作 (Actions)

An action is a plain object that contains all information necessary to do that action.

动作是一个普通对象，包含执行该动作所需的所有信息。

Actions have a type property identifying the action type.

动作具有用于标识动作类型的type属性。

As action objects move around the application, I suggest to make them immutable.

当动作对象在应用程序中移动时，我建议使它们不可变。

Actions may come from different places. They may come from views as a result of user interaction. They may come from other places like the initialization code, where data may be taken from a Web API and actions are fired to update the views. Action may come from a timer that requires screen updates.

动作可能来自不同的地方。由于用户交互，它们可能来自视图。它们可能来自其他地方，例如初始化代码，那里的数据可能来自Web API，并且会触发操作来更新视图。动作可能来自需要屏幕更新的计时器。

动作创作者 (Action Creators)

The practice is to encapsulate the code, creating actions in functions. These functions that create and dispatch actions are called action creators.

实践是封装代码，在函数中创建动作。这些创建和分配动作的函数称为动作创建者。

Web API调用 (Web API Calls)

When doing Web API calls to update the user interface, the Web API call will be followed by an action to update the store. When the store is updated it will emit a change event and as result the view that listens for that event will re-render.

进行Web API调用以更新用户界面时，将在Web API调用之后执行更新商店的操作。更新商店后，它将发出一个change事件，结果将重新渲染侦听该事件的视图。

Web API calls are made in action creators. We can extract out the code that does the API call in Web API Utils functions.

Web API调用是由动作创建者进行的。我们可以提取在Web API Utils函数中执行API调用的代码。

单向数据流 (Unidirectional data flow)

Updating views flow in a single direction:

更新视图的方向是单一的：

Views do not modify the data they received. They listen for changes of this data, create actions with new values, but do not update the data.

视图不会修改接收到的数据。他们侦听此数据的更改，使用新值创建操作，但不更新数据。

Stores, views and any other action can’t change the state in (other) stores directly. They must send an action through the dispatcher

商店，视图和任何其他操作都不能直接更改(其他)商店中的状态。他们必须通过调度程序发送操作

The data flow is shorter in store reads than in writes.The data flow in store writes differs between asynchronous and synchronous actions.

存储读操作中的数据流比写操作中的短。异步操作和同步操作之间的存储写操作中的数据流有所不同。

Store Reads

商店阅读

Store Writes in synchronous actions

以同步操作存储写入

Store Writes in asynchronous actions

以异步操作存储写操作

优点 (Pros)

Flux architecture is better in an application where views don’t map directly to domain stores. To put in a different way, when views can create actions that will update many stores and stores can trigger changes that will update many views.

在视图不直接映射到域存储的应用程序中，Flux体系结构更好。换句话说，当视图可以创建将更新许多商店的动作时，商店可以触发将更新许多视图的更改。

Actions can be persisted and then replayed.

动作可以持久保存然后重播。

缺点 (Cons)

Flux can add unnecessary complexity to an application where each view maps to one store. In this kind of application a separation between view and store is enough.

Flux会给每个视图映射到一个商店的应用程序增加不必要的复杂性。在这种应用程序中，视图和存储之间的分隔就足够了。

Take a look for example at How to create a three layer application with React.

以如何使用React创建三层应用程序为例。