如何学习React
我的图书馆
如何学习React
如何学习React
如果你是一个 React (或者前端) 新手, 出于以下的原因, 你可能会对这个生态圈感到困惑:
React 的目标群体历来是喜欢尝试新事物的开发者和前端专家.
Facebook 只开源了他们在实际使用的, 因此他们没有关注那些比 Facebook 小的工程需求.
现有的 React 指引水平层次不齐.
在本文中, 我会假设你已有使用 HTML, CSS 和 JavaScript 开发网页的基础.
为什么要听我的?
关于 React, 现在已经有大量的相互冲突的建议了, 为什么要听我的?
因为我是在 Facebook 构建并开源 React 的最初成员之一. 现在我离开了 Facebook 并加入了一家初创公司, 所以我也不会站在 Facebook 的立场上来表态.
如何踏入 React 生态圈
所有的软件都是建立在某个技术栈之上的, 你需要对整个技术栈有足够深入的理解, 才能建造你的应用. 为什么 React 生态圈的工具似乎总让人感觉压力山大呢, 因为它总是以错误的顺序被解释:
你应该按照以下的顺序进行学习, 而不是跳着学或者同时学习:
你不需要把这些都学完才去使用 React. 只需要在你遇到问题需要解决的时候, 才进入下一步的学习.
另外, 在 React 社区中, 有一些前沿主题是经常被提及到的, 以下的这些主题很有意思, 但也很难弄懂, 所以它们远没有上面的主题流行, 大多数应用也不需要用到这些.
学习 React 本身
有一种常见的误解是: 你需要花费大量时间在配置工具上, 然后才开始学习 React. 在官方文档里, 你可以找到 . 只需要保存为 .html 文件, 你就可以马上开始学习了. 这个步骤不需要任何工具, 你也无需额外学习工具使用, 直到你能熟练掌握 React 基础.
我依然觉得, 学习 React 最简单的方法是通过官方教程 .
npm 是 Node.js 包管理工具, 也是前端工程师和设计师分享 JavaScript 代码最流行的方式. 它包含了名为 CommonJS 的模块系统, 让你可以安装 JavaScript 写的命令行工具. 作为背景知识, 可以阅读
了解 CommonJS 对于浏览器的重要性, 阅读
了解关于 CommonJS API 的更多内容
在 React 生态圈中, 大部分可重用的组件、库和工具遵循 CommonJS 模块规范, 可通过 npm 来安装.
学习 JavaScript 打包工具
出于若干技术原因, CommonJS 模块 (也就是 npm 里的所有内容) 不能直接用到浏览器. 你需要一个 JavaScript “打包工具(bundler)” 来把这些模块打包成 .js 文件, 使你可以在网页中通过 &script& 标签引入它们.
JavaScript 打包工具包括有 webpack 和 browserify. 它们都是好的选择, 但我个人更喜欢 webpack , 因为它有许多功能简化大型应用开发. 鉴于 webpack 文档可能令人感到困惑, 我也写了两篇文章:
和针对更复杂用例的 .
要记住的一点: CommonJS 使用了 require() 函数来引入模块, 因此许多人对此感到疑惑, 并认为需要导入 require.js 到工程里. 出于若干技术原因, 我建议你避免使用 require.js. 它在 React 生态圈并不流行.
在 JSX (你会在 React tutorial 中学习到) 以外, 你可能会注意到 React 例子中一些有趣的语法. 这被称为 ECMAScript6, 是 JavaScript 的最新版本. 由于 ES6 很新, 你可能还没学习到, 浏览器也可能尚未兼容, 但别担心, 通过合适的配置, 你的打包工具会为你自动转换成兼容代码.
如果你只想要使用 React 来把事情做完, 你可以跳过 ES6 的学习, 或者留到以后再学习.
你可能会看到一些讨论说更适合用 ES6 的 class 来创建 React 组件. 这并不是真的, 大多数人 (包括 Facebook) 用的还是 React.createClass().
学习路由 (routing)
“单页面应用” 是时下的技术热点. 当网页加载完成, 用户点击链接或者按钮的时候, JavaScript 会更新页面和改变地址栏, 但网页不会刷新. 地址栏的管理就是通过 路由(router) 来完成的.
目前 React 生态圈最受欢迎的路由解决方案是 . 如果你正在创建一个单页面应用, 有什么理由不去使用它呢?
如果你创建的并非单页面应用, 请不要使用路由. 无论如何, 大部分项目都是从大型应用中的小组件开始的.
学习内联样式
在 React 出现之前, 很多人通过像 SASS 这样的预处理器来重用复杂的 CSS 样式表. 鉴于 React 使开发可重用组件变得容易, 你的样式表可以变得没那么复杂了. 社区中许多人 (包括我) 正尝试完全抛弃样式表.
由于一些原因, 其实这是个相当疯狂的主意. 这让媒体查询 (media quries) 更加困难了, 而且这种技术可能有性能上的局限性. 当你开始用 React 的时候, 只要用你平常使用的方法去写就好了.
一旦你找到了用 React 开发的感觉, 你就可以关注那些可作为替代的技术了. 其中一种流行技术是 . 我建议你逐渐停用 CSS 预处理器, 因为 React 给了你一种更强大的方式去重用样式 (通过重用组件), 并且 JavaScript 打包工具可以为你生成更高效的样式表 (我曾经). 说了这么多, 总之 React 就像其他 JavaScript 库一样, 可以和 CSS 预处理器很好地配合工作.
学习服务器端渲染
服务器端渲染经常被称为 "universal" 或 "isomorphic" JS. 这意味着你可以用 React 组件在服务器端渲染出静态 HTML. 这样做可以提高初始化加载的性能, 因为用户不用等到 JS 下载完才看得见初始界面, 并且 React 可以重用服务器端渲染出的 HTML, 无需客户端重新生成.
如果你发现首屏渲染速度过慢, 或者想提高网站在搜索引擎的排行, 你就需要服务器端渲染了. 尽管 Google 现在也会索引客户端渲染的内容, 但截至 2016 年 1 月, 这样做被证实会对排行有负面影响, 这可能是由于客户端渲染的性能问题所造成的.
服务器端渲染还需要许多工具的辅助, 因为显然 React 组件不是在考虑服务器端渲染的情况下写出来的, 你应该先构建你的应用, 之后再关心服务器端渲染的问题. 你不用担心重写所有组件才能支持它.
你可能听过 Flux, 不过关于 Flux 有大量的错误资讯.
许多人一坐下来刚开始构建应用, 就认为需要用 Flux 来定义他们的数据模型. 这样采用 Flux 是不对的, Flux 应该在大量组件被建立完成以后才被引入.
React 组件之间存在层级关系. 在很多时候, 你的数据模型也跟随这种层级. 这种情况下, Flux 不会给你很大帮助. 但有些时候, 你的数据模型没有层次, 当你的 React 组件开始接受没有关联的 props 的时候, 或者当小部分组件开始变得复杂的时候, 你才可能需要看看 Flux.
你会知道什么时候需要用 Flux. 如果你不确定是否需要用它, 你就不需要它.
如果你决定使用 Flux, 现在最流行的、文档最全的 Flux 库是 . 当然也有许多其他选择, 你或者会有兴趣尝试使用它们, 但我的建议是只需要用最流行的那一个就足够了.
学习 Immutable.js
提供了一系列的数据结构, 以帮助解决构造 React 应用时的某些性能问题. 这是一个很棒的库, 你可能会在应用发展的过程里大量用到它, 但直到你在意识到性能问题以前, 它是完全不必要的.
学习 Relay, Falcor 等
这些技术可以帮你减少 AJAX 请求数, 它们仍然是非常前沿的, 所以如果你没有遇到过多 AJAX 请求的问题, 就不需要用到 Relay 或者 Falcor.
译者：达仔Zhangjd
文章源自：
喜欢该文的人也喜欢深入理解React、Redux - 简书
深入理解React、Redux
React+Redux非常精炼，良好运用将发挥出极强劲的生产力。但最大的挑战来自于函数式编程（FP）范式。在工程化过程中，架构（顶层）设计将是一个巨大的挑战。要不然做出来的东西可能是一团乱麻。说到底，传统框架与react+redux就是OO与FP编程范式的对决。
简单学习某项技术并不能让建立起一个全局理解，也很难工程化。所以，我们必须要看以下几方面：
了解其独特的东西。如React中组件是pure render函数。
置新技术于上下文中。将React放在flux、redux中。才能真正看到数据单向流动。
对比看到优势。比其它的解决方案(vue, angluar，adobe flex），看其优势。
挑战。软件领域里没有银弹，有好处一定有挑战。
1. 谈谈对React的理解
1.1 独特性
Virtual Dom：又一个虚拟层、中间层、cache层，大胆的跳出了web的DOM实现约束，实现更加理想的UI编程模型：树型控件组织、统一事件、统一数据传输通道(props)。可以把Dom render到web，navtive的GUI系统上，这非常美妙，Learn once, Use Everywhere。
轻Component：React的component强调pure render，把业务逻辑放到其它子系统中，如redux中的reducer。
组件状态（state）要最小化的，按，不是props传入的，随时间变化的，不能是通过其它的props和stat计算而来。
常用的设计模式：创建多个只负责渲染数据的无状态（stateless）组件，在它们的上，是有状态（stateful）组件。有状态组件封装了所有用户的交互逻辑，而这些无状态组件则负责声明式地渲染数据。
设计范式是数据驱动组件来render。对比OO范式，OO有时会把compoent搞成自闭的、复杂的类，里面藏了太多的状态，调测很难跟踪。
1.2 置React于上下文中
React的virtual DOM想要构建一个理想的前端模型，那理想的前端编程到底是如何呢？我个人总结的4点：
构建基本UI能力：不论是组件拖拉（VB），还是写树型XML描述文档，能快速做出和直觉一致的UI界面
数据绑定：与数据层（model）绑定数据，展示一个有数据的UI
用户交互：用户点击、触摸，程序完成业务逻辑，并反馈给用户，表明是一个活的UI
UI布局：组织管理合个UI，一个UI调起另一个UI，自己死掉或藏起来。
构建基本UI能力：React完成的非常不错，通过写JSX能完成一个基本UI的构建。JSX是一个非常好的工程化手段，你第一眼看到它，可难会不爽。但新事物总要给它五分钟！品味一下，你会发现这样做更内聚，更务实的把计算与显示内聚在一个地方，甚至你还可以把css样式以inline sytle的方式写在js文件里。最重要的是它可以把让XML化的组件与js完美混合计算！
在数据绑定：React通过父子组件的props数据通讯协议，可以漂亮的完成初始数据绑定。这个props做得简单而高效，大亮点！
用户交互：React组件被认为自己是一个有限状态机。与用户交互，改变自己的状态（state）。算法根据这些状态，render算法现计算出合适的数据集呈现给用户。这样做的好处是设计范式高度一致。
UI布局，可能需要用到react-router，或者自己写框架。这一块还未研究。
1.3 对比其它方案
React对比其它方案，突出优点是正交化、轻、约定性、务实：
正交：对比Vue, Angular更正交化，它没有template，大的component就是template。
轻：对比abobe flex或其它的UI系统是轻，没有复杂的UI OO体系，这也是说明React只是一个目标UI体系的粘合层。
约定性：约定大于Java仪式感，这也是自Rails之后在风潮。如pure render，最小化无状态state。
务实：通过JSX来组织表达控件的树形结构，用this.props来传递数据
React是数据驱动式的UI component体系，是一个开放的数据依赖式，非自闭OO对象。它会有以下挑战
render方法可能很大，component显示逻辑是一次性在render里实现的。这里往往有两部分逻辑实现，初次数据绑定，与用户交互之后的算法。
render出一个ReactElement树，但这个树中的一些组件、UI元素因为计算被前移了，这会导致这个树看起来不太完整，进而不太直观。
虽然可以分解成小的component，构建大的Component可能是个挑战，因为所有逻辑都依赖于外部数据，而外部数据相对不稳定，组件失去了自我边界的保护，非自闭。
当交互复杂，组件的state也会越来越大，render全局算法会越来越难写。
把子组件的行为传上来也是一件不显化的事，往往需要把父组件的一个函数作为回调传给子组件。
大组件往往有多个Page，这几个Page如何交换数据是个很大的挑战
2. 谈谈对Redux的理解
2. 1 独特性
一个数据层的framework，类似于Baobab。比其好的一点，引入middleware体系，有几个现成的插件redux-thunk, redux-promise，不用但心异步请求的事。虽然说灵活、独立很重要，但全局设计也是 让人放心去用，而不用担心功能缺失和其它风险。
应用了FP中数据不可变性（immutable），这让追踪数据改变过程有很大提升。也就是其宣扬的时间旅行。这对复杂问题定位是有好处的。
树形化数据存储，reducer的返回即是其新建，更新、删除过程，树形结构不需要预先定义。同时，reducer也是纯函数，与reactor的render是纯函数呼应。
强约束（约定），增加了内聚合性。Flux中的action, dispatcher, store比较散，在分层架构是需要的，但内聚性不佳，出现java的仪式感。而redux是数据层很清晰，一个store，更新则dispatch到action，前半段自己想怎么搞就怎么搞(middleware），后半段reducer。reducer约束是不要改oldState，返回newStatew，做到immutable。
不一样的action：Redux中的action会切得很细，一个传统的Action被切成了三个Action：Loading, GetSuccess, GetError。所以，从这个方面来看Action服务于UI，而非业务逻辑单元。
Redux大量应用FP，经常遇到FP中的curry, trund, promise这些概念，学习成本较高。在middleware层实现，对没有FP经验的人讲不友好。
2.2 置Redux于上下文中
Redux是一个比较薄的数据层。同时，把View同步刷新也做了（redux-react）。
在传统MVC中，还是有一个controller来做业务逻辑。但Redux硬生生的把一个controller切成二部分:action, reducer。
理论上，Redux还可以把React组件中的stat的存储也拿过来，比如用户搜索的名称。这样，就可以把过滤算法放到selector中去。但这样好处并不是很大。
2.3 与其它方案对比
与Baobab对比，两者都是数据管理框架，Baobab提供cursor来方便你对很深层的数据结构进行update。而redux是通过selector函数来做，这种方法会比较晦涩。但比Baobab好的地方，做数据fetch可以通过Redux的middleware来完成。
与Rails的controller, ActionRecord相比，Redux更多是一种约定，不提供路由级的controller，不提供数据访问cursor。
接口不超过10个，代码也非常少，但是与之前的MVC框架完全不同。可能最大的问题是没有和react-route打通，在工程化时让人迷茫。
Redux应用最大的挑战更多来自设计层面，如何设计action，设计state树形结构。我们只能通过非常少的线索（FP架构思想）去做，这对没有FP经验的团队是一个大挑战。
通过selector函数从stat树里取数据比较晦涩，并且这个selector里的代码认为是业务逻辑，单独放在selector，业务上不内聚。
middleware层设计：action是一个意图(intent），发送给middleware，让其来实现此意图。但这样做，action比有两义性，一会儿是对象，一会儿是函数。同时FP编程侵入性太大。
没有与Route结合起来设计，让人很不放心，也不知道如何在不同路由下来做数据与组件的connect。
react + redux是一种典型的FP编程范式实现，而其它框架大多是OO范式。是否选用react+redux开发，需要看是否对FP有掌握或者有一定的架构能力。但单独用react则没有这种要求，当个view来用。
3.1 FP vs OO
FP的好处是没有OO的复杂仪式感，是沿着数据结构+算法的思路进行抽象和结构化。如果顶层设计做好，代码复用度极高，代码量少。比如要生成一颗树我用迭归算法直接生成，而OO的人往往会用一个Composite模式去定义一个晦涩的类接口。
FP的缺点也是也是面向过程编程的缺点，算法与数据全局化、并且互相耦合，这往往会导致一个强耦合的系统。如果没有做好顶层设计，是难以演进的。
通过约定和全局的理解，可以减少FP的一些缺点。“约定大于配置”也是框架的主要发展方向。
OO的好处是分而治之，增量演进。同时有自闭性，语义比较清晰。
缺点是在表达一些算法时，反而是很困难的。如command模式实现历史回滚就挺麻烦。也这是四人帮的设计模式大多比较难以理解的原因。另外，OO一直有一个对算法复用的问题，ruby语言解决比较好，用mixin很自然。而像C++就用多继承和泛型，个人感觉并不是最好的。
有FP经验的或者架构能力比较强，团队人员比较少、能力强，较强适合用react+redux。不然用react+angluar, 或直接用vue。
过度的OO，搞太多java仪式感确实没有必要。通过架构设计，FP在生产力有着一定的优势。同时对付复杂系统，能更好调测、定位问题。在新时代下，值得尝试。
做最美、最易用的软件
做React需要会什么？ react的功能其实很单一，主要负责渲染的功能，现有的框架，比如angular是一个大而全的框架，用了angular几乎就不需要用其他工具辅助配合，但是react不一样，他只负责ui渲染，想要做好一个项目，往往需要其他库和工具的配合，比如用redu...
react+redux的一些思考 我们经常把react和redux放到一起.react大家都很熟悉,我们先简单的看下redux 什么是redux? redux我理解就是一个状态管理器，它提供了二个基本的接口函数createStore和applyMiddleware 我们来看...
前言 本文 有配套视频，可以酌情观看。 文中内容因各人理解不同，可能会有所偏差，欢迎朋友们联系我讨论。 文中所有内容仅供学习交流之用，不可用于商业用途，如因此引起的相关法律法规责任，与我无关，如文中内容对您造成不便，烦请联系
处理，谢谢。 ...
http://gaearon.github.io/redux/index.html ，文档在 http://rackt.github.io/redux/index.html 。本文不是官方文档的翻译。你可以在阅读官方文档之前和之后阅读本文，以加深其中的重点概念。 根据该项目...
本文主要介绍自己使用React + DVA + ANT
的开发过程，也是在开发中慢慢学习，前半部分大多数是理论知识，后半部分是实例。 React React是近期非常火热的一个前端开发框架，当然也有很多人认为它不是一个框架，因为它仅仅是作为MVC模式中的V层用来构建UI。...
5点半闹钟响起前，先从梦境中醒来，醒来时内心仍有许多的惊恐，醒来第一个念头问自己，这个梦境想告诉我什么呢？“和解！”是的，去到内在的深处，与潜意识里的冲突、恐惧、愤怒、......与内心受伤害的小孩和解，与内心的牢笼里伤恨的父母、伤害过你的人和解。 是的，只有和解，身心合一...
最近估计是看书看得太累了，时间紧任务重，终于，今天感觉到什么是身心俱疲。考研准备阶段都没有这种感觉。但是也要劳逸结合，最根本的，要做好规划。如果早些做准备，也就不会像现在这样了。 所以，我要早点休息了！明天加油！！
照片里的老南京（一）
照片摘自网络
（二十世纪二、三十年代）
在没有成熟搭建好的三支柱结构下，万万不可采用bp模式。不成熟下的实施bp，会让做bp的人很累，很辛苦，也无法有好的产出。还不如就小Hrd模式，快速决断，这样方有产出。
康妮嫁给了克里夫，两人都是社会的上层。克里夫打过仗，腰以下都瘫痪了，所以他们俩过的是无性婚姻。克里夫写作，还经常召集一群人来家里高谈阔论。康妮反感他们的论调，在这种生活中渐渐消瘦。然后她遇见了守园人密勒斯。母鸡孵小鸡让康妮感到自己作为一个女人的不完整。她和密勒斯在一起了。她...　　1. React，Flux简单介绍
　　学习React我们知道，React自带View和Controller库，因此，实现过程中不需要其他任何库，也可以独立开发应用。但是，随着应用程序规模的增大，其需要控制的state也会越来越多，为了统一控制，我们一般都会将所有的状态和控制逻辑都放在顶层组件中，这样就会导致，react顶层组件中体积庞大，并且数据和组件混合在一起，非常不方便管理。
　　在这种情况下Flux，就出现了，他提出了将应用程序，分为三部分：dispatcher， store，view。其中，dispatcher负责分发事件；store负责保存数据，同时响应事件并更新数据；view负责订阅store中的数据，根据数据渲染相应的页面，并提供用户交互。
　　实际上来说，从React到Flux，我们只是将我们React中定义的顶层组件中数据与逻辑拆分到不同的文件中：
　　1. 将state写在store中，在store 中存放数据，并向外提供一个getter接口，为state提供唯一数据接口；并创建change事件注册函数；
　　2. 将合成事件的回调函数，转化成action对象（js对象，具有一个type属性，用于表示action的类型，并通过payload属性传递数据），并使用Dispatcher对象中的dispatch方法将事件对象分发出去。
　　3. 利用dispatcher对象中提供的register方法，注册action，接收dispatch方法分发action对象，对store的数据进行相应操作，并触发change事件；
　　4. 我们在组件中监听自定义change事件，当监听到change事件，重新获取store中的数据 ，设置state，重新渲染页面。
　　实际上Flux并不是一个框架，而是前端应用架构，它提出了单向数据流，可以提供清晰的数据流。同时将数据和组件分离，使应用程序结构更清晰。但是flux依旧存在一些问题。
　　Redux，利用Flux提出的架构思想和少量的核心代码，方便了我们的开发。以上都是简单介绍，下面通过Redux核心代码，其中部分都是简化代码。
　　2. Redux核心代码介绍
　　1. createStore方法
　　下面代码是createStore的简单实现，其中保留了其中三个主要的方法getState，dispatch，subscribe实现，省略了参数处理部分，和一些其他方法实现。
// createStore方法简单实现const createStore = (reducer) =& {　　// 定义state，监听器数组
　　let listeners = [];
　　　　// 定义getter方法，唯一一个获取数据的接口
　　const getState = () =&
　　// 定义dispatch方法，用户分发action事件，接收一个action对象，生成新的state，并通知所有监听器
　　const dispatch = (action) =& {　　　　// 利用reducer生成新的state
　　　　state = reducer(state, action);　　　　// 通知所有监听器，调用回调函数
　　　　listeners.forEach(listener =& listener());
　　　　// 定义subscribe方法，注册监听器，并返回一个用于取消当前注册监听器的函数，用于取消监听　　　const subscribe = (listener) =& {　　　　// 添加到监听数组中
　　　　listeners.push(listener);　　　　// 返回取消监听函数
　　　　return () =& {
　　　　　　listeners = listeners.filter(l =& l !== listener);
　　// 调用dispatch，初始化state
　　dispatch({});
　　// 返回getState，dispatch，subscribe三个方法
　　return { getState, dispatch, subscribe };
　　我们从上面代码可以知道，createStore接收一个reducer函数参数，每次调用dispatch函数，利用reducer函数，以及之前的state，以及action，计算出最新的state，并通知所有的监听器，通过调用getState方法，调用最新的state。同时组件通过subscribe函数，注册一个监听器，从而每当数据更新时，通知监听组件。
　　以上就是Redux中最主要的createStore对象中主要方法介绍。
　　2. combineReducers函数
　　reducer函数，其实就是根据当前的state和action，计算出一个新的state，之所以叫reducer，是因为它的功能就是action对象数组调用reduce函数，产生最新的状态。
　　当我们的应用程序规模非常大时，我们需要将reducer进行拆分，我们可以直接自定义一个总的合并reducer，也可以使用conbineReducers函数来合并，最终效果等价。
// 合并多个reducer
// 返回一个合并的reducer函数，接收两个参数state和action
* combineReducers调用方法
* combineReducers({
a: a(state.a, action),
b: b(state.b, action),
c: c(state.c, action)
const combineReducers = reducers =& {
return (state = {}, action) =& {
// 获取所有自身可枚举属性，并进行reduce操作，
// 将合并在一起，初始值为空数组
return Object.keys(reduers).reduce(
(nextState, key) =& {
nextState[key] = reducers[key](state[key], action);
return nextS
　　3. applyMiddleware函数
　　该函数是在当createStore函数传入applyMiddleware参数时，在createStore中调用的。其实createStore函数的实际参数有三个reducer, preloadedState（state默认值）, enhancer， 并且在函数中一些了参数判断，主要就是，将enhancer（在这里是applyMiddleware函数） 参数进行匹配，如果createStore参数中具有enhancer， 则直接调用enhancer(createStore)(reducer, preloadedState)对store进行初始化。
　　其中applyMiddleware中有调用createStore函数，来初始化store，然后用middleware对初始化的store 中的dispatch函数进行包装，得到最终增强的applyMiddleware，最终返回具有增强的applyMiddleware的store。
// 将中间件和store.dispatch组合
// 返回具有整合后的dispatch方法的store
export default function applyMiddleware(...middlewares) {
return (createStore) =& (reducer, preloadedState, enhancer) =& {
// 根据上面分析，reducer，preloadedState即为createStore中的reducer，preloadedState
// enhancer为空
// 创建一个初始化的store，基本逻辑即为上面createStore函数分析
var store = createStore(reducer, preloadedState, enhancer);
// 获取此时dispatch函数副本
var dispatch = store.
// 用于存放中间件函数数组
var chain = [];
// 中间件的执行参数，中间件编写规定
var middlewareAPI = {
getState: store.getState,
dispatch: (action) =& dispatch(action)
// 对每一个中间件进行处理后存放
chain = middlewares.map(middleware =& middleware(middlewareAPI));
// 使用compose函数，将处理后的中间件，和dispatch进行合并，得到增强后的dispatch
// 如果chain为[f1, f2, f3]，那么dispatch经过compose处理后为 f1(f2(f3(dispatch)))
dispatch = compose(...chain)(store.dispatch);
// 将增强后的dispatch，赋值给store，并返回store
return {...store,
　　其中的compose函数，主要就是利用了reduceRight函数对参入的参数进行了处理，就不详细说明了。
　　我想大家如果了解了上面这些，就能容易理解Redux如何工作的了。
阅读(...) 评论()