从AngularJS到Flux - React方法

作为一个具有良好的实践性AngularJS经验的开发人员，我如何调整使用React在Flux中编写Web应用程序的心智模式？从AngularJS到Flux - React方法

我不是在寻找一个流量+阵营VS角答案（已经很多，网上的），但我会想知道什么是在两个“思维”的最大差异：事先，我被引入The Angular Way;相对而言，什么是The React Way？

在我离开的角度宇宙并过渡到流量，哪些关键的东西我需要开始关注？

差异首先，现在的相似之处：AngularJS非常有见地，并有一些非常大的禁忌，像 - 不要把UI/DOM代码放在控制器中。 React最大的禁忌和意见是什么？

最后但并非最不重要的，Facebook的指的是磁通，一个替代MVC，但我在看它 - REACT为视图引擎，商店集中在单域模型容器，以及调度员和行动组成一个控制器。那么这不是真的MVC有不同的名字吗？

2014-12-03 pilau

我没有Angular的经验，所以很难解释它们之间的差异和转换过程。然而，关于问题的第二部分：React仅仅是来自MVC的V，我会将它与Mustache/Marionette进行比较。 Flux有存储和调度器，并与React一起创建MVCish结构。你也可以很容易地用Backbone替换Flux。 – daniula 2014-12-03 07:30:50

在我看来，Flux是一种反模式。将所有商店连接到单个调度程序，无论其抽象级别和责任如何，都会导致大规模调度程序块发生管理噩梦。 – 2015-06-22 14:04:45

@DmitriZaitsev Flux不强制要求每页只有一个调度程序。您可以拥有尽可能多的调度程序，以便在同一页面上实际处理不同类型的操作。 – bluecollarcoder 2015-08-25 21:13:12

我会让别人和Angular做比较/对比，但这里有一些问题的答案。

那么这不是真正的MVC与不同的名称？

Flux中数据/逻辑层和视图层之间的关注分离的存在不会使其成为MVC。许多其他模式也有类似的分裂，最明显的是CQRS，可以说是Flux最亲密的表兄弟。在MVC中，Flux中没有控制器。操作和分派器不等于控制器。控制器视图非常接近，但其控制器方面实际上非常有限。一个关键的区别是MVC控制器包含应用程序逻辑并且在模型上执行。相比之下，Flux存储包含所有的应用程序逻辑并且没有设置器。

当我离开Angular宇宙并转换到Flux时，我需要开始关注哪些关键事项？通量的

键值：

简单了复杂性。

程序员的心智模式至少和代码本身一样重要。

应用程序的某些部分应该高度分离并尽可能少地了解其他部分。

控制反转：所有控制都应该存在于管理状态的商店中。店铺没有采取行动，而是采取行动通知。

应用程序在增长时应该保持弹性和灵活性，以便更快更轻松地开发新的意想不到的功能。
在流量

重要概念：

单向数据流：操作→调度→商店→查看

状态每变化和被派遣行动的所有新数据开始。

这个四步数据流是Flux程序员的核心心智模型。

甲调度引起的应用程序状态的应用程序范围内转换。

这是一时的，产生变化的快照。这很容易推理。

我们不能在调度时调度并保持这种简单性。因此，任何必然的改变都必须由原始行为驱动。

流量商店域模型，而不是ORM模型。它们包含所有逻辑并管理应用程序中特定逻辑域的所有状态。它们可能包含集合，单数值或两者的组合。

通量假定得出的数据 - 其中一个店面依赖于另一家商店的变化 - 在复杂应用中的模型或存储管理标准化的数据的可能性。为了解决这个问题，Flux Dispatcher应该公开一个机制来声明性地管理该商店内的这种依赖。在Facebook的调度程序中，这是通过waitFor()方法完成的。这允许一家商店等待另一家商店对行动做出回应，然后再进行自己的回应。

焊剂应用程序的主要组成部分：

操作：对象文本包含新数据和特定类型的，允许商店辨别是否是有关其结构域。

调度员：通过回调向注册人（商店）分配有效载荷（动作）的回调注册表。它没有自己的智慧。所有的情报都在商店里。

商店：与所述分派器寄存器本身，每当在其状态发生改变时发出“改变”事件域模型。

控制器视图：查看组件树根部附近的组件。他们倾听商店中的“变化”事件，并通过商店暴露的吸气方法检索新数据并将其传递给他们的孩子来回应此事件。控制器视图和视图之间的唯一区别是这种侦听功能。

浏览：控制器视点分量的无国籍儿童，接收和沿着数据传递，很像纯函数。视图和控制器视图通常用React实现，因为它提供了随意重新渲染而性能损失很小的能力。

Utils：可在不同模块之间轻松共享的纯函数库。

概述，深入：http://facebook.github.io/flux/docs/overview.html

教程：http://facebook.github.io/flux/docs/todo-list.html

例子：https://github.com/facebook/flux/tree/master/examples

操作和调度：http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

测试：http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html

更多在野外：http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html

来源

2014-12-03 08:41:59 fisherwebdev

谢谢。你能否扩展关键概念＃4？特别是关于这一点：“Flux认为，派生数据 - 其中一家商店依赖于另一家商店的变化 - 是模型或商店管理规范化数据的复杂应用程序中的一个可能性。” （机制部分很清楚）。谢谢。 – pilau 2014-12-03 09:05:45

当应用程序规范化数据时，即在两个地方没有重复数据（因为这样做很难维护）时，我们经常遇到需要在Store B中存储数据A的情况。例如，在构建贺卡的应用中的ImageStore vs. ThemeStore。每个主题可以包含不同的最大数量的图像。 ImageStore需要知道选择了哪个主题，因此它知道它可以标记为有效的数量。当调用THEME_SELECTED类型的动作时，ImageStore需要waitFor ThemeStore，然后获取所选主题的最大值。 – fisherwebdev 2014-12-03 09:23:11

处理衍生数据实际上是Flux在Facebook上开发的原始原因。然而，后来出现了许多好处。 – fisherwebdev 2014-12-03 09:25:00

从AngularJS到Flux - React方法

回答

相关问题