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来通报数据
1. 4 应战
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买通，在工程化时让人渺茫。
2.4 应战
Redux运用最大的应战更多来自设想层面，怎样设想action，设想state树形构造。我们只能经由历程异常少的线索（FP架构头脑）去做，这对没有FP履历的团队是一个大应战。
经由历程selector函数从stat树里取数据比较艰涩，而且这个selector里的代码以为是营业逻辑，零丁放在selector，营业上不内聚。
middleware层设想：action是一个企图(intent），发送给middleware，让其来完成此企图。但如许做，action比有两义性，一会儿是对象，一会儿是函数。同时FP编程侵入性太大。
没有与Route结合起来设想，让人很不宁神，也不知道怎样在差别路由下来做数据与组件的connect。
3. 总结
react + redux是一种典范的FP编程范式完成，而别的框架大多是OO范式。是不是选用react+redux开辟，须要看是不是对FP有控制或许有肯定的架构才能。但零丁用react则没有这类请求，当个view来用。
3.1 FP vs OO
FP优瑕玷
FP的长处是没有OO的庞杂典礼感，是沿着数据构造+算法的思绪举行笼统和构造化。假如顶层设想做好，代码复费用极高，代码量少。比方要天生一颗树我用迭归算法直接天生，而OO的人每每会用一个Composite形式去定义一个艰涩的类接口。
FP的瑕玷也是也是面向历程编程的瑕玷，算法与数据全局化、而且相互耦合，这每每会致使一个强耦合的系统。假如没有做好顶层设想，是难以演进的。
经由历程商定和全局的明白，能够削减FP的一些瑕玷。“商定大于设置”也是框架的重要发展方向。
OO优瑕玷
OO的长处是分而治之，增量演进。同时有自闭性，语义比较清楚。
瑕玷是在表达一些算法时，反而是很难题的。如command形式完成汗青回滚就挺贫苦。也这是四人帮的设想形式大多比较难以明白的缘由。别的，OO一向有一个对算法复用的题目，ruby言语处理比较好，用mixin很天然。而像C++就用多继续和泛型，个人感觉并非最好的。
3.2 发起
有FP履历的或许架构才能比较强，团队职员比较少、才能强，较强适合用react+redux。不然用react+angluar, 或直接用vue。
过分的OO，搞太多java典礼感确切没有必要。经由历程架构设想，FP在生产力有着肯定的上风。同时应付庞杂系统，能更好调测、定位题目。在新时代下，值得尝试。
转载自：http://www.jianshu.com/p/0e42…
个人建了前端进修群，旨在一同进修前端。纯洁、地道手艺议论，非前端职员勿扰！入群加我微信：iamaixiaoxiao。
