为什么我从Angular转向React

JSX - 混合了 HTML 和 JavaScript

React 有一套称为 JSX 的语法，用来制作组件。JSX 混合了 HTML 和 JavaScript。此外人们经常会在元素中使用内联样式，即混入 CSS。一开始可能让人觉得混淆，但终归会适应。你可以使用 JavaScript 组合和操作 DOM，但是它嵌入在 HTML 中。你可以使用内置的 JavaScript 功能，比如 map 和 filter 来显示多个（过滤后的）DOM 节点。你还可以使用三元操作来按条件进行渲染。你可以在 HTML 中使用完整的 JavaScript 功能。

在 SPA 解决方案中，它是一个新奇的方法，通过混合 HTML 和 JavaScript 来定义组件。其实这种方法在很早的服务端渲染方案（比如 JSP）中就已经存在了。

与之相反，Angular 清楚地区分了逻辑和视图的概念。它可以在 HTML 中使用内置的表达式，像 ng-repeat（Angular 1.x）或 ngFor（Angular 2）。这在 JSX 中会使用原生 JavaScript 的 map() 来完成。

轻量级组件 => 最佳实践

React 中的组件有两个定义方式：ES6 类组件和函数形式的无状态组件。后者只是一些函数，接收参数输入并返回输出一个元素——这也是组件，但是它们不需要模板，只需要定义普通的 JavaScript 函数。我不能说 Angular 定义组件更容易。

function Button({ onClick, children }) {
    return (
        <button onClick={onClick} type="button">
            {children}
        </button>
    );
}

随处使用函数式的无状态组件是个非常好的实践，但只在不需要组件状态和生命周期方法的时候才能这样做。这个最佳实践使你可以定义轻量级的小组件，却不失重用性、组件化和功能性，并且不会带来副作用。这样的最佳实践已经体现在上面的样板代码中。

单向数据流

与 Angular 1.x 不同，React 没有双向数据绑定。Angular 组件中的状态管理最终变得混乱不堪。状态几乎不能预测，也没有比较好的做法来处理它。在 Angular 1.x 中消除循环更新是件困难的事情。

React 使用单向数据流规则。组件使用 setState() 来显式更新内部状态。它必须从组件的状态对象 (this.state) 中获取状态，然后组件按更新后的状态再次渲染。对于组件的输入 (props)，也会发生同样的事情，如果输入更新了，组件会通过其生命期方法 render 来更新。千万不要直接修改输入 (props) 或组件内部状态 (state)。应该遵循单向数据流规则，使 React 的状态管理更容易预测。

此外，你还可以完全控制原生 HTML 元素。例如，HTML 中的 input 有其自己的状态。你在 input 中输入的文本可以通过 value 属性获得。在 React 中如果想完全控制 input 的状态，以便在 input 的值发生改变时能通过 onChange() 回调，调用 setState() 来更新组件内部状态的值。之后可以在 input 中使用更新后的状态值。这样一来，组件内部状态就是单一来源，值得信任。而 input 不再自己管理状态。

<input
    value={this.state.value}
    onChange={(event) => this.setState({ value: event.target.value })}
    type="text"
 />

单向数据流使得 React 的状态管理可预测且易于维护。

Redux

Redux 并非 React 的必备组件。不过它们能完美适配，因为 Redux 只是一个构建块，而 React 生态接受构建场。

Redux 带来可预测的状态管理。自 2015 年 Dan Abramov 引入 Redux 以来，它就完全符合 flux 体系。Redux 是 flux 库中的佼佼者，广泛应用于各种场景。在 React 中使用 Redux 是很自然的事情。React 本身使用单向数据流，这与 Redux 相符。

再来说 Angular 开发的那些日子里，开发者们奋斗在包含状态管理的可伸缩的成熟应用中。在某些时候，你必须自己实现像 flux 那样的东西，因为 flux 还没成形。最后每个人都在羡慕 React 的开发者拥有无缝集成在生态系统中的 flux 模式。

Redux 本身就是一个完整的生态系统。它是一个有着创新的构建块，像 React 一样。特别是在异步领域，它支持不同的方式。比如，你可以选择 JavaScript Promise、generator 或者可观察对象。它是一块试验田，你可以在这里找到自己做事的方法和创意。

接近 JavaScript

我必须说，从 Angular 转向 React 的过程中我学习了不少 JavaScript 语言的概念。现在再回到 Angular，我很难回想起它的语法、用于 HTML 的表达式，或者申明。因为我没有保留代码片段，所以回去使用 Angular 会花不少时间。我不知道事实是怎么样的，但是从 Angular 转回 React 的时候，我认为那是不同的开发方式。React 非常接近 JavaScript，它只有一个构建块。你一旦学会，就不是那么容易忘记。

React 非常接近 JavaScript。不仅 React，它的生态系统也与 JavaScript 类似。比如，Redux 的 action 和 reducer 本身就是 JavaScript。另外，整个 Redux 生态系统完全使用原生存在或即将实现的 JavaScript 功能，比如 generator 和可观测对象。从库的角度来看，它涵盖的内容中没有不是原生 JavaScript 的工具函数。

另一个方面是 JavaScript ES6。也许 React 包含 ES6 只是一个巧合，因为 ES6 出现在同一时间。不过 React 一直在前进并吸收 ES6 的优点。采用 ES6 是件好事。还记得之前定义的无状态的功能性按钮组件吗？如果使用 ES6 的箭头函数，它看起来会有点不一样：

const Button = ({ onClick, children }) =>
    <button onClick={onClick} type="button">
        {children}
    </button>

在 React 及其生态系统中，你可以使用 ES6 简洁优雅地进行表达，而且它还简单并极具可读性。使用它是自然而然的事情。

函数式编程

函数式编程自然地溶入了 React 及其生态系统。也许这是因为它与 JavaScript 极为接近。作为一个 React 开发者，应该尽量定义没有副作用的函数 —— 纯函数。这些函数能以可预测的方式组进行组合。首先，因为它们是纯函数，相同的输入一定会得到相同的输出（可预测）。其次，你可以使用高阶函数来组合它们（可组合）。

可预见性和可组合性带来的优势同样赋予了 React 的功能性组件，这就是为什么 React 的组件是可预测和可组件（高阶）的。

编程方式正在发生变化。函数式编程并不是新事物，但它是首次在 JavaScript 中采用。对于 JavaScript 生态环境中的函数式编程来说，React 是这个思想的引领者之一。人的伟大之处就在于能向伟人学习，了解他们的优点和缺点并借他们的手来提高自己。React 和它的生态系统为你学习和使用函数式编程提供了可能性。

社区

如果说下述大部分原因不适用于其它库、框架和生态系统，那我是在撒谎。但我仍然认为值得提一下，React 环境背后的社区非常伟大。

生态系统背后的人每天都在反复不断的尝试。这可以追溯到 React 发明出来的时候，这关系到它的构建块。新的解决方案有机会在社区中茁壮成长。构建块会从开发者那获益并不断变化。

React 背后的人们相互鼓励。人们向社区贡献创新、扩展库或写文章，怎么都行。大家都会点赞激励你继续。当我开始写关于 React 的文章时也受到了大家的鼓励。

人们不会在生态系统中驻足。如果出现问题，就一定会有解决办法。有人会用库来解决问题，或者在文章中解释某个问题的最佳实践。人们协助奋进。因为社区持续创新，所以总会有不少解决问题的新颖方案。

正如我所说，我关于社区的想法是普遍的想法。我认为充斥着不同解决方案的社区都做的很好，它们相互鼓励共同进步。这样的环境下它怎么会不变得伟大。

总之，我说的这些是希望能帮助你更好的了解 React 生态系统。这也许会帮助你决定是否要在 2017 年跳上 React 这趟列车。对我个人来说，它帮助我进行了反思以决定开始学习 React。去年年中我们公司也在这个方面有一些小小的进步。