为什么我们需要 Flux 和 React？答案

【问题标题】：Why do we need Flux with React?为什么我们需要 Flux 和 React？
【发布时间】：2016-06-25 17:49:51
【问题描述】：

我不明白为什么我们需要 Flux 和 React，因为 React 本身让我们维护应用程序的状态。每个组件都有一个初始状态，并且可以通过用户操作或任何其他异步 JavaScript 更改状态。

当 React 可以让我们定义应用程序的状态并在状态更改时更新视图时，为什么只将 React 称为视图库。这不是视图所做的......它是完整的 MVC 所做的对吗？

例如：here 是仅使用 React 构建的 Todo 应用，here 是使用 Flux 和 React 构建的 Todo 应用。

如果我们只能使用 React 构建 Todo 应用程序，那我们为什么需要 Flux？

【问题讨论】：

【解决方案1】：

理论上你不需要助焊剂。在小型应用中，您肯定不需要助焊剂。但是，如果您的应用程序包含数百个组件怎么办？你的组成部分之一是形式。用户填充此表单，您将其内容发送到服务器。并从服务器获得新数据的响应。并假设此响应数据和表单数据对其他组件是必需的。

我更喜欢redux（只有一个商店和一个真相来源）

编辑：

即使 React 可以处理应用程序状态，为什么还要将其称为视图库？

MVC 是一种软件架构模式。它将给定的软件应用程序划分为三个相互关联的部分（模型、视图、控制器）。如果我们考虑 react 和 MVC，它适合作为 View。但这并没有错。这并不意味着您只能将其用于视图。它允许您创建普通的应用程序。

但另一方面，您可以将其用作其他框架的视图（例如，您可以将其与 angular 一起使用）。

换句话说，它是一个非常灵活的库，可用于多种用途。

【讨论】：

即使 React 可以处理应用程序状态，为什么它被称为视图库？
在我看来，在 React 组件中处理应用程序状态是一种有用的副作用。如果您正在编写视图，则需要保留一些状态信息，例如元素的可见性、单选按钮和复选框的状态等。所以一个好的视图库应该提供一些方法来做到这一点。但是一旦该功能可用，没有人会阻止您以相同的方式存储整个应用程序状态。这可能很尴尬，但肯定有可能。
@MadWombat 我喜欢你的解释。即使在 React 页面中，也有这样的“React 通过将用户界面分解为组件来以不同的方式构建用户界面。这意味着 React 使用了一种真正的、功能齐全的编程语言来渲染视图”。他们使它非常灵活，甚至可能不打算将其用作全功能框架。
一般来说，我喜欢库和框架，它们可以让你用它们来编写你的应用程序。我不喜欢巨石

【解决方案2】：

你不需要需要 Flux，你不需要需要 MVC。它们都是架构，您当然可以不使用其中任何一个来构建一些东西。

您会在 2016 年构建非 MVC 应用程序吗？可能不会，这并不意味着人们过去没有这样做。

Flux 太棒了！但由于科技行业中的大多数事情并不总是正确的决定，因此项目要求会有所不同。

可能 Flux 的最大卖点是它试图强制数据流向一个方向，这意味着您可以确定数据的来源。在非 Flux 应用程序中，组件的数据可以是自己的属性、沿组件树向下传递的属性、局部状态变量、调用 API 的状态变量结果。

使用 Flux：“数据从何而来？”。答：从专卖店。 Redux 更进一步，只使用一个 store。

Flux 受到批评，因为您需要大量样板代码，但又是一个权衡问题。

最后始终由您来电，具体取决于您的项目需求。

【讨论】：

即使 React 可以处理应用程序状态，为什么它被称为视图库？
因为它被设想为只显示数据。数据会随着时间而变化，而 facebook 需要一种方法来有效地呈现变化的数据，因此state 的目的是跟踪这些变化。不是让您拥有像结构这样的整个数据库
除了它不强制你如何管理你的数据（主干集合、本地存储、本地状态等）之外，react 组件本身对呈现你的数据感兴趣，而不是数据如何在那里结束。
同意。这里的另一点是维护。虽然一开始我也有同感。但随着我的项目数量越来越多，我意识到通量的重要性。您将操作和存储分开保存的位置，这在调试时也很有用。