React+Redux，从MVC到Flux

接触React技术栈也很久了，React方面的代码也写了不少，现在回想当初第一次接触Flux架构的时候，强行入门Redux的痛苦，真的是=。=太惨了。。。。一个之前一直在写MVC/MVVM架构的，突然要转到Flux架构，这个思考问题的方式实在难以转变过来…

这几天在用React技术栈重构我当初实习时用JAVA写的一个项目，突然发现自己的思维已经完全转换为’Thinking in React’….

比如说，想导入百度地图API的时候，发现考虑更多的是怎么把地图区域封装成一个组件……
然后百度地图官方给出的API，也很不适合React开发…

话归正题，还是想说说怎么转变过来的…

---

首先推荐一本书，涉及React全家桶的书，也是我入门React的书……
是陈屹老师的《深入React技术栈》，这本书的内容来源于陈屹老师在知乎专栏pure render上的内容…
以及我后面具体分析的代码，也多数来源于这书的示例代码…

---

首先，为什么要学React?

我想说，学React的原因多数可能都是听说React很火，是现在前端开发的非常非常流行的，觉得不学就落伍了
确实，React技术栈包含的知识几乎是现代前端开发者必须学习的

为什么说是React技术栈？

可能用过Angular的就会比较奇怪，因为Angular提供的东西很全面，需要的东西都有，最多就是找找UI库什么的
好吧，Angular确实是这样，它本身就是一个全家桶，它是一个大而全的框架

但是React不一样，一开始出现的时候，它仅仅被定位成一个View库，在我还没系统学习React的时候，我一度以为它是MVC框架里面的一个V库……

Navie…
现在看来，React已经远远不是一个VIEW库了，它带来的各种新概念，新的开发方式，新的思维方式都是值得我们去学习的！（再一次后悔自己学习React太迟）

一般使用React开发的话，就得采用和它配套的各种开发框架，工具去配合开发，用其他的也不是不可以，只是就不能达到最大的效果，如果这样，那也失去了使用React的意义，所以这些配合使用下来，就形成一个完整的技术栈

最根本的开发语言，当然是JavaScript，不过现在都是在用ES6在开发了，使用了ES6那就需要用babel转码器（现在浏览器对ES6的支持并没有达到），然后，你如果之前没有接触过ES6的话，那就需要学习了

使用React去开发组件，React的自己的知识自然是需要学习的，然后如果要用UI库，你会发现UI库似乎也需要那种专门为React开发的UI库

当你的应用逻辑足够复杂的时候，你就会发现，你需要Redux这个东西

当你的应用是一个单页应用的时候，你需要React-router这个东西，然后如果使用了Redux来管理状态的话，又需要react-redux-router这个东西

当你需要运行应用的时候，你需要webpack这种打包器，了解打包器的时候，你又会了解到CommonJs，AMD,CMD等知识

测试，又需要学习React的测试框架

…………
等等，太多了，需要学习的太多了

引用阮一峰老师的话来说就是：
面对技术的高速发展和百花齐放，我有时也感到疲倦烦躁。但是，每当看到它们带来的生产力的飞跃，让你一个人快速搞定前后端的全部开发时，就觉得这终究还是一条正确的道路。

这句话是阮一峰老师在他的React技术栈博客的最后写的，附上地址：react技术栈系列教程

---

先放一张react的运行过程图

最先接触的是React语法，一开始学习的地方是在阮一峰老师的个人博客上学习的，地址：点击这里

在这个教程里面，阮老师也简单的介绍了一下React的起源，现在的发展等等…
语法基本上都涉及到了，但也都只是简单的提了一下，但是对真正的初学者来说是最好的，深入浅出，先简单的体会，感受一下React是一种怎样的存在

最先接触到的就是jsx这个概念，熟悉之后也没什么
还有就是虚拟dom的概念，为什么react如此高效？他的diff算法又是怎么样的？生命周期是怎样的一个过程？

然后一开始是用的createClass这种方式去封装组件，后来就改用ES6 class语法糖来封装组件了

熟悉React的语法之后，开始尝试着用React的方式去写一个静态的网页

比如说，有这样1个简单的界面，左边是一个列表，右边是一个textarea区域，来展示列表中被选中项的内容

如果是传统的网页开发的思维角度来考虑，这个网页该怎么去写？

在Html中写好静态内容，引入一个JS文件，在js中对列表绑定事件，然后编写事件内容，大概就是这样

从React的角度来考虑，这个界面，就是2个组件，只要封装好这2个组件，再做好2个组件的通信交互，就能完成这个界面

---

刚才说到自己写组件，初学者一开始觉得最头疼的是，代码写在哪里？

这就涉及到了脚手架的问题，什么是脚手架..以我的理解，就是直接给你搭好架子，开始你的表演（写你自己的代码）

最推荐的当然是creat-react-app 这个Facebook官方推出的脚手架，帮助快速建立一个react应用demo

npm install -g create-react-app安装这个脚手架
create-react-app my-app
cd my-app

建立应用，期间下载时间可能会比较长，因为文件比较多，而且是从github下载下来的，速度……
这是应用创建完成之后的目录结构

在控制台输入:npm run start就能启动应用了

然后打开浏览器输入:localhost:3000就能看到界面了~

具体的，请看这里： 使用 create-react-app 构建 react应用程序

当对这个demo足够熟悉的时候，就可以自己尝试一下，从0开始自己配置一个react应用demo，包括webpack，babel,es6这些相关的配置~

---

当React学习到一定程度的时候，必然会接触到Redux这个东西…

Redux流程图

em….Redux这个东西，用得不好，反而会伤害自己，会增加自己的工作量

我到现在都还记得，我在网上看到的一个关于Redux的评论，他说：“所有关于Redux的都不好用”

我从这句话里面感受到了深深的怨念哈哈哈

笑过之后，仔细想想为什么会出现这样的问题呢

正如我一开始说的那样，Flux是一种全新的架构方式，Redux是继承了flux的核心思想并进行优化的存在

flux的核心思想是什么呢……其实就是四个字：单向流动

用过Angular1的，可能会记得Angular1的最大特点是什么，那就是数据，指定绑定，而且是双向绑定

这就是最大的不同，双向绑定意味着，任何一方的改变，都可以使得数据和逻辑向另外一方流动，数据的流动是双向的，当绑定的model多了起来之后，嗯，这个复杂交叉的数据逻辑网，头疼吗…

所以Angular2开始，也取消了双向绑定这个东西……

这个是flux架构的流程图

可以看见，它的核心就是Dispatcher这个东西，它是一个分发器，负责分发action，action顾名思义，就是一个动作，store就是存储数据和状态的集合，只有通过Dispatcher分发action才能去修改Store，Store的改变促使了view层react组件的渲染，使得界面发生变化，界面再发生什么交互动作，action creator监听到，就触发action，让dispatcher分发action，周而复始，数据的流动始终保持着一个单向的流动循环

但是flux本身也存在不足，其中最大的弊端就是冗余代码太多，特别是，如果你的逻辑并不是那么复杂的时候，用这个东西反而会适得其反，把简单的事情复杂化，增加了工作量

后来Redux出现了

它参考了Flux 的设计，但是对Flux 许多冗余的部分（如dispatcher）做了简化，同时将Elm 语言中函数式编程的思想融合其中

嗯，函数式编程，这又是一个现代前端需要学习的一个东西，尤其对React技术栈来说，React本身就是一种声明式编程，即函数式编程，具体关于函数式编程的学习，请点这里：JS函数式编程思想

Redux继承了flux的核心，算是flux架构的一个具体实现的npm库，提供了很多API给开发者使用，去编写flux架构的应用

Redux的特点之一，也是单向流动，这是肯定的

其二，状态都是只读的，即store都是只读的，前面说过，dispatcher通过分发action来修改store，redux禁止了这样的行为，redux通过因为reducer,传入原来的store和action，然后返回新的store，没有原来的store进行修改

其三，状态的得到都是由纯函数来完成的，纯函数是什么，简单的来说，就是你给它的输入参数是一定的，是确定的，它就能返回一定的值，而且不管什么时候，只要输入确定，输出一定确定，没有副作用，这就是纯函数，在现代前端开发中，对纯函数的执念达到了一种可怕的程度……

你看陈屹老师的专栏名字叫pure render…

还有更多内容，如路由的React-router,react-redux-router,以及用中间件解决异步交互问题的thunk等等就不一一说了，亲手写一个React技术栈的项目，这些都会接触到的

具体的请看：点击这里
一位大神在github上对一个React+Redux项目的完整介绍