摘要：正式入坑我将按顺序解释概念，并且一个一个地构建它们。视图的和调度员本质上是一个加入了额外规则的事件系统。它来广播事件并注册回调。这描述了我们的，我们称之为。然后，会响应已分派的操作这是处理调度回调的传统方式。
原文地址：https://blog.andrewray.me/flu... ，作者：Andrew Ray
TL;DR 当我在努力学习Flux时，我希望有人告诉我：它并不简单，也没有好的文档可以查，并且有许多变化的部分。
我需要使用Flux吗？如果你的应用程序需要处理动态数据（dynamic data）的话，那么答案就是yes，你可能需要使用Flux。
如果你的应用程序仅仅是无需共享状态静态视图（static view），并且你从不保存也不更新数据，那么你不需要使用Flux，Flux不会给你带来任何好处。
为什么是Flux?皮一下，因为Flux是个适度复杂的主意，为啥要增加复杂度呢？
90％的iOS应用程序是表格视图中的数据。iOS工具包具有良好定义的视图和数据模型可以让应用开发变得简单。
但是在前端（Font End：HTML,JS,CSS），我们甚至都没有。相反，我们遇到一个很大的问题：没有人知道应该如何去构建一个前端应用。我从事这个行业多年，从来没人教给我“最佳实践”，相反，他们教了我好多“库（libraries）”，诸如jQuery，Angular，Backbone等等。但是真正的问题、数据流，仍然避开了我们。
什么是Flux？Flux是一个用来描述具有非常特定事件和监听的“单向”数据流的词。没有官方的Flux库，但是你需要Flux Dispatcher和任何的JavaScript event library。
官方文档写的就像某人的意识流一样，从这里开始学习是不太好的。但是一旦你掌握了Flux，它可以帮助你填补空白。
不要试图把Flux同MVC架构进行比较，它们的相似之处只会令人困惑。
正式入坑！我将按顺序解释概念，并且一个一个地构建它们。
1.视图的“Dispatch”和“Actions”Dispatcher（调度员）本质上是一个加入了额外规则的事件系统。它来广播事件并注册回调。全局的dispatcher只有唯一的一个，你应该使用Facebook Dispatcher Library。实例化非常容易：
var AppDispatcher = new Dispatcher();
假设你的应用程序有一个“新建”按钮来向列表添加项目。
点击会发生什么？你的视图会调度一个非常具体的“操作”，其中包含操作名称和新项目数据：
createNewItem: function( evt ) {
AppDispatcher.dispatch({
actionName: "new-item",
newItem: { name: "Marco" } // example data
});
}
“action”是Facebook创造的另一个词。它是一个JavaScript对象，用以描述我们想要做什么事情，以及做这件事我们需要的数据。正如你所见到的，我们要做的事情就是添加一个new-item，我们需要的数据就是项目name。
2."Store"响应调度的操作像Flux一样，“Store”这个词也是Facebook创造的.对于我们的应用程序，我们需要列表的特定逻辑和数据集合。这描述了我们的Store，我们称之为ListStore。
Store是一个单体对象，意味着你可能不能通过“new”关键字来声明它，应用程序中每个Store里只有一个实例。
// Single object representing list data and logic
var ListStore = {
// Actual collection of model data
items: []
};
然后，Store会响应已分派的操作：
var ListStore = …
// Tell the dispatcher we want to listen for *any*
// dispatched events
AppDispatcher.register( function( payload ) {
switch( payload.actionName ) {
// Do we know how to handle this action?
case "new-item":
// We get to mutate data!
ListStore.items.push( payload.newItem );
break;
}
});
这是Flux处理调度回调的传统方式。每个payload包含一个action的名称（actionName）和数据（newItem），switch语句确定Store是否应该响应action，并且知道根据action的类型处理数据变化。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/108805.html
摘要：我的教程可能也会帮你一把其他的二分法展示型组件和容器型组件这种分类并非十分严格，这是按照它们的目的进行分类。在我看来，展示型组件往往是无状态的纯函数组件，容器型组件往往是有状态的纯类组件。不要把展示型组件和容器型组件的划分当成教条。 本文译自Presentational and Container Components，文章的作者是Dan Abramov，他同时也是Redux和Crea...
摘要：本系列教程翻译自，系列共有九篇，本文译自第八篇。是将会用来取代命令的工具。准备示例系统是，配置文件在。修改完毕后，重启。列出所有容器创建新容器检查容器用于获取容器底层信息。进程列表获取容器内运行进程的列表。下篇文章介绍的是用于镜像操作的。 本系列教程翻译自 Flux7 Docker Tutorial Series，系列共有九篇，本文译自第八篇 Part 8: Docker Rem...
摘要：本系列教程翻译自，系列共有九篇，本文译自第八篇。是将会用来取代命令的工具。准备示例系统是，配置文件在。修改完毕后，重启。列出所有容器创建新容器检查容器用于获取容器底层信息。进程列表获取容器内运行进程的列表。下篇文章介绍的是用于镜像操作的。 本系列教程翻译自 Flux7 Docker Tutorial Series，系列共有九篇，本文译自第八篇 Part 8: Docker Rem...
摘要：结构和数据流一个单向数据流是模式的核心，上面示图应该是程序员心中主要的模型图。 前言 这篇文章不会用具体的代码去阐述redux、flux或者vuex，因为我觉得它们所带来的更是一种编程思想。 前端进化和框架演变 在很久以前，前端没有MVVM的概念，MVVM是对MVC细化的说法（个人觉得两者区别不大），MVC的模式一直在后台使用，效果和优点都很明显。 后来前端工程师仿照MVC模式开发了很...
摘要：它的设计使得即使是大型团队也能以高度隔离的方式应对功能变更。获取数据数据变更性能，都是让人头痛的问题。通过维护组件与数据间的依赖在依赖的数据就绪前组件不会被渲染为开发者提供更加可预测的开发环境。这杜绝了隐式的数据依赖导致的潜在。 关于Relay与GraphQL的介绍 原文：Introducing Relay and GraphQL 视频地址（强烈建议观看）：https://www.y...
阅读 3169·2021-11-23 09:51
阅读 680·2021-10-14 09:43
阅读 3204·2021-09-06 15:00
阅读 2406·2019-08-30 15:54
阅读 2560·2019-08-30 13:58
阅读 1841·2019-08-29 13:18
阅读 1374·2019-08-27 10:58
阅读 506·2019-08-27 10:53
