摘要：本质上它登记了一堆回调，并且按注册回调的顺序执行。调用回调的过程由方法触发，该方法接受一个数据负载对象作为唯一参数。通过自身定义并注册的回调进入，而不是通过类似之类的方法调用。在某种情况下可能依赖，而在另一种情况下又依赖。
Flux: Actions and the Dispatcher
原文: Flux: Actions and the Dispatcher
Flux是Facebook用于构建javascript应用的架构。它基于单向数据流。利用Flux我们将所有东西都拆分成小的组件（widgets）然后组合成庞大的应用，而Flux成功应对了所有遇到的困难。我们认为这是一种非常好的组织代码的架构，因此非常高兴能够将他贡献给开源社区。Jing Chen在F8会议上展示了Flux(youtube视频，墙内慎点)，从那以后我们了解到很多人对它非常感兴趣。同时，我们公布了Flux概览与带有入门指南的TodoMVC示例。
Flux与其说是一整套的框架，不如说是一种模式，在React之上你只需要写很少的代码就可以开始使用它。直到最近我们都还没有公布Flux的一个重要部分：dispatcher。但随着Flux代码库和Flux主页的建立，现在我们已经将dispatcher开源并与生产环境版本保持同步
Dispatcher在Flux数据流中的作用dispatcher是单例的，在Flux应用中它被用作数据流的中央集线器。本质上它登记了一堆回调，并且按store注册回调的顺序执行。当有新的数据传入时，它向所有stores注册的回调传播此数据。调用回调的过程由dispatch方法触发，该方法接受一个数据负载对象(data payload object)作为唯一参数。
Actions 与 ActionCreators当有新数据进入系统时，无论是通过用户交互还是web api请求，该数据会被封装成一个action——一个包含了数据字段和特别声明的action类型的对象。通常我们会新建一类工具方法的集合叫做ActionCreators，用于创建action对象并传递给dispatcher。
不同的actions用类型区分。当所有stores接收到action时，通常他们通过识别类型来决定是否响应和如何响应。在Flux应用中，stores和views都是“自治”的，他们的行为不由外部决定。actions通过store自身定义并注册的回调进入store，而不是通过类似setter之类的方法调用。
stores的“自治”消除了许多MVC框架中常见的纠结现象。传统MVC框架model间的级联更新往往会导致不稳定的状态并且使得应用难以准确测试。而Flux应用则高度解耦，并且坚守了迪米特法则：系统中的不同对象之间相互了解得越少越好。这使得软件更加可维护，可扩展，和可测试，并且更利于新团队成员理解。
为什么需要Dispatcher随着应用规模的增长，Store之间的相互依赖变得无法避免。Store A可能会需要 Store B先执行update，然后才能正确地update自己。Dispatcher可以让我们先行调用并完成Store B所注册的回调，再继续执行Store A的业务。要显式地声明这种依赖，Store需要向dispatcher表明“我要等Store B处理完了才能继续处理当前的action”。而dispatcher的waitFor方法则提供了这种功能。
dispatch方法对回调的遍历是简单、同步式的。当在执行callback过程中遇到waifFor方法时，对当前callback的调用就会中断，wairFor方法会根据声明的依赖重新确定遍历顺序（注：原文字面意思如此，但从dispatcher的源代码看是检查依赖项是否已执行，若否，则立即去执行依赖项），当所有依赖都被执行后，原先中止的callback才会继续执行
更进一步地，waifFor方法可以在同一个store回调的不同action处理分支中使用。在某种情况下Store A可能依赖Store B，而在另一种情况下又依赖Store C。在action处理语句块中使用waitFor使我们能够更细粒度地控制依赖关系。
当然也会出现问题，比如循环依赖。A依赖B然后B又依赖A这样的情况，会导致无限循环。目前Flux实现的dispatcher在遇到这种情况时会抛出一个包含错误信息的Error来警告开发者，然后开发者可以选择新建一个Store来避免这种情况。
注：从源代码看其实不用新建store，只要通过register新注册一个回调id即可，环检测是基于回调id的，Flux的官方demo中每个store有一个dispatcherToken来保存该store的回调id，事实上一个store持有多个回调id也是可行的
Chat App示例我们和dispatcher同时公布的还有一个新的示例程序chat app ,稍微比TodoMVC的例子更复杂一点，以便于开发者能更好地理解Flux是如何解决Stores间的依赖关系以及如何调用web API的
注：这个flux-chat例子非常非常重要，store的waitFor和前置web api调用个人认为是flux理念的核心，也是store与传统MVC的Model层为何完全不同的核心
We"re hopeful that the new Flux repository will grow with time to include additional tools, boilerplate code and further examples. And we hope that Flux will prove as useful to you as it has to us. Enjoy!
注：客套话懒得翻了
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/85512.html
摘要：在方法中处理数据有三不同的角色派发器储存视图层我们的组件的主要思想是有一个单一源储存他们只能通过触发更新。这些操作负责调用派发器可以订阅更改并相应地更新自己的数据。与不同不使用派发器而是使用纯函数来定义数据变异函数。 本文转载自：众成翻译译者：iOSDevLog链接：http://www.zcfy.cc/article/3812原文：https://www.fullstackreact...
摘要：应用架构是用来构建客户端应用的一种应用架构体系。它是一种类似的架构，但是它更加简单清晰，是一种单向数据流的架构设计。将数据和动作类型传递给去分发数据流是一个包含所有动作类型的常量对象一个分发中心，它管理着应用的所有数据流向。 Flux 应用架构 Flux是Facebook用来构建客户端Web应用的一种应用架构体系。它是一种类似MVC的架构，但是它更加简单、清晰，是一种单向数据流的架构设...
摘要：自己英语一般，水平有限，献上原文地址，还有我翻译的中文地址，欢迎大家勘误下面是自己的一点感想先说一下，我们知道，前端优化有这么几步，第一步首先呢我们知道，一个应用要依赖好多条文件，而浏览器加载完一条，要执行完这条才加载下一条，所以呢，就很慢 自己英语一般，水平有限，献上原文地址，还有我翻译的中文地址，欢迎大家勘误 下面是自己的一点感想 先说一下webpack，我们知道，前端优化有这么几...
阅读 2188·2021-11-18 10:02
阅读 3291·2021-11-11 16:55
阅读 2696·2021-09-14 18:02
阅读 2427·2021-09-04 16:41
阅读 2059·2021-09-04 16:40
阅读 1169·2019-08-30 15:56
阅读 2214·2019-08-30 15:54
阅读 3161·2019-08-30 14:15
