react(其一)

 react、reactjs、react native、virtual dom、diff算法、redux....，按照我的理解，react是大哥，其他的都是小弟，顶多是小弟的组长。

react.jpeg

react

作为facebook开源出来的一门技术，以及现在的流行程度，其价值是不言而喻的。react我觉得它是思想，一种解决方案，他将传统的dom进行了抽象，然后通过操作抽象的实例来实现对dom的操作。从事了一段时间angularjs的开发后发现，组件化的重要性，无论是从维护层面，还是结构层面，组件化都是一个非常好的实现。你不用因为修改一点点的地方而去熟悉整个系统，整个功能，而react就是这样的。当然google团队后面有出了性能更加强大的angular，同样的也是将组件化的思想最大化的实现。

virtual dom

然后说一下这个东西，前面说到了react是以抽象dom的方式来操作dom的，virtual dom就是也就是这个抽象的具体定义。作为react实现的核心之一，抽象dom使得react的实现成为可能，同时呢也是react的特点之一。VTree模型非常简单，基本结构如下：

{
 // tag的名字
 tagName: 'p',
 // 节点包含属性
 properties: {
  style: {
   color: '#fff'
  }
 },
 // 子节点
 children: [],
 // 该节点的唯一表示，后面会讲有啥用
 key: 1
}

diff算法

差异算法，这里应该说简单差异算法，怎么说，标准的diff算法复杂度是(n^3)，而这里的dom diff算法复杂度是(n)。那么React是如何取巧的呢？
1、分层对比

domDiffLayer.jpg

如图，React仅仅对同一层的节点尝试匹配，因为实际上，Web中不太可能把一个Component在不同层中移动。
2、基于key来匹配

domDiffKey.jpg

还记得之前在VTree中的属性有一个叫key的东东么？这个是一个VNode的唯一识别，用于对两个不同的VTree中的VNode做匹配的。这也很好理解，因为我们经常会在Web遇到拥有唯一识别的Component（例如课程卡片、用户卡片等等）的不同排列问题。
3、基于自定义元素做优化

domDiffComponents.jpg

React提供自定义元素，所以匹配更加简单。
由于diff操作已经找出两个VTree不同的地方，只要根据计算出来的结果，我们就可以对DOM的进行差异渲染。

reactJs.jpeg

reactjs

前面说了这么多，reactjs也就很好理解了，实际上它就是react思想的一种实现，可以类比与jquery、angular之类的实现，具体的语法在这里就不做过多的阐述了。

reactNative.jpeg

react native

如果说reactjs面对的是web工程，那么react native则是面向原生应用。前几年兴起了android和ios，很多人投入到里面，android和ios也取得了前所未有的成功。但是，随着时间的推移，越来越多的问题显现出来，学习曲线陡峭，开发、维护成本高...。所以有人就希望用前端技术来代替，实现java所谓的“一次编写，到处运行”的宏大目标。可是因为局限性，java虚拟机拥有的性能是浏览器引擎所不能比拟的，再如多线程的问题也是前端技术的一个瓶颈，要想实现统一，那是何其难。
 这无非就是三个想法：
1、在原生里面嵌入js，即webview，而实际上这完全不能达到原生的效果；
2、移植React的原生版本，把React移植到原生也是一个好主意。实际上，在iOS平台上已经这么做了，这个项目叫做ComponentKit。不过这个方案也有几处不太重要的负面影响。首先，它是iOS独有的，所以如果我们想在Android上获得一样的好处，我们只能去创造一个独立的实现，然后教会工程师怎么去用它。并且，我们也没办法同时使用我们为web顶层构建的各种工具，譬如帮助我们解决了规模性的数据获取的许多痛点的Relay。最重要的是，我们没能改善开发速度中最大的问题——我们还得每次修改之后，重新编译和构建工程。
3、用脚本封装原生
 如果我们用JavaScript去调用原生API，我们应当能获得原生平台的所有强大之处，同时还能享受快速迭代和使用我们现有JavaScript上基础设施的好处。不仅如此，因为基于JavaScript构建，我们应当能使得这样技术栈跨平台。这听起来恰好是我们要的全部，而且毫不意外有成千上万的框架正在这么干，然而实际上问题并没有被直截了当的解决。
说了这么多题外话，言归正传，react native是什么？一句话：其实就是针对特定的平台用react的方式实现的一套框架。

redux

reduxFlow.jpg

redux不是必须的，是一个锦上添花的东西曾经有人说过这样一句话。

"如果你不知道是否需要 Redux，那就是不需要它。"

Redux 的创造者 Dan Abramov 又补充了一句。

"只有遇到 React 实在解决不了的问题，你才需要 Redux 。"

简单说，如果你的UI层非常简单，没有很多互动，Redux 就是不必要的，用了反而增加复杂性。

用户的使用方式非常简单
用户之间没有协作
不需要与服务器大量交互，也没有使用 WebSocket
视图层（View）只从单一来源获取数据

上面这些情况，都不需要使用 Redux。

用户的使用方式复杂
不同身份的用户有不同的使用方式（比如普通用户和管理员）
多个用户之间可以协作
与服务器大量交互，或者使用了WebSocket
View要从多个来源获取数据

上面这些情况才是 Redux 的适用场景：多交互、多数据源。
从组件角度看，如果你的应用有以下场景，可以考虑使用 Redux。

某个组件的状态，需要共享
某个状态需要在任何地方都可以拿到
一个组件需要改变全局状态
一个组件需要改变另一个组件的状态

发生上面情况时，如果不使用 Redux 或者其他状态管理工具，不按照一定规律处理状态的读写，代码很快就会变成一团乱麻。你需要一种机制，可以在同一个地方查询状态、改变状态、传播状态的变化。
总之，不要把 Redux 当作万灵丹，如果你的应用没那么复杂，就没必要用它。另一方面，Redux 只是 Web 架构的一种解决方案，也可以选择其他方案。