深入理解 React

这是一篇源自[官方博客](http://reactjs.cn/react/blog) 的[文章](http://reactjs.cn/react/blog/2013/11/05/thinking-in-react.html)。 在我看来， React 是较早使用 JavaScript 构建大型、快速的 Web 应用程序的技术方案。它已经被我们广泛应用于 Facebook 和 Instagram 。 React 众多优秀特征中的其中一部分就是，教会你去重新思考如何构建应用程序。 本文中，我将跟你一起使用 React 构建一个具备搜索功能的产品列表。 > **注意：** > > 如果你无法看到本页内嵌的代码片段，请确认你不是用 `https` 协议加载本页的。 [TOC] ## 从原型（ mock ）开始 假设我们已经拥有了一个 JSON API 和设计师设计的原型。我们的设计师显然不够好，因为原型看起来如下：  JSON接口返回数据如下： ~~~ [ {category: "Sporting Goods", price: "$49.99", stocked: true, name: "Football"}, {category: "Sporting Goods", price: "$9.99", stocked: true, name: "Baseball"}, {category: "Sporting Goods", price: "$29.99", stocked: false, name: "Basketball"}, {category: "Electronics", price: "$99.99", stocked: true, name: "iPod Touch"}, {category: "Electronics", price: "$399.99", stocked: false, name: "iPhone 5"}, {category: "Electronics", price: "$199.99", stocked: true, name: "Nexus 7"} ]; ~~~ ## 第一步：拆分用户界面为一个组件树 你要做的第一件事是，为所有组件（及子组件）命名并画上线框图。假如你和设计师一起工作，也许他们已经完成了这项工作，所以赶紧去跟他们沟通！他们的 Photoshop 图层名也许最终可以直接用于你的 React 组件名。 然而你如何知道哪些才能成为组件？想象一下，当你创建一些函数或对象时，用到一些类似的技术。其中一项技术就是[单一功能原则](http://en.wikipedia.org/wiki/Single_responsibility_principle)，指的是，理想状态下一个组件应该只做一件事，假如它功能逐渐变大就需要被拆分成更小的子组件。 由于你经常需要将一个JSON数据模型展示给用户，因此你需要检查这个模型结构是否正确以便你的 UI （在这里指组件结构）是否能够正确的映射到这个模型上。这是因为用户界面和数据模型在 _信息构造_ 方面都要一致，这意味着将你可以省下很多将 UI 分割成组件的麻烦事。你需要做的仅仅只是将数据模型分隔成一小块一小块的组件，以便它们都能够表示成组件。  由此可见，我们的 app 中包含五个组件。下面我已经用斜体标示出每个组件对应的数据。 1. **`FilterableProductTable` （橘色）：** 包含整个例子的容器 2. **`SearchBar` （蓝色）：** 接受所有 _用户输入（ user input ）_ 3. **`ProductTable` （绿色）：** 根据 _用户输入（ user input ）_ 过滤和展示 _数据集合（ data collection ）_ 4. **`ProductCategoryRow` （青色）：** 为每个 _分类（ category ）_ 展示一列表头 5. **`ProductRow` （红色）：** 为每个 _产品（ product ）_ 展示一列 如果你仔细观察 `ProductTable` ，你会发现表头（包含“ Name ”和“ Price ”标签）并不是单独的组件。这只是一种个人偏好，也有一定的争论。在这个例子当中，我把表头当做`ProductTable` 的一部分，因为它是渲染“数据集合”的一份子，这也是 `ProductTable` 的职责。但是，当这个表头变得复杂起来的时候（例如，添加排序功能），就应该单独地写一个`ProductTableHeader` 组件。 既然我们在原型当中定义了这个组件，让我们把这些元素组成一棵树形结构。这很简单。被包含在其它组件中的组件在属性机构中应该是子级： * `FilterableProductTable` * `SearchBar` * `ProductTable` * `ProductCategoryRow` * `ProductRow` ## 第二步： 利用 React ，创建应用的一个静态版本 既然已经拥有了组件树，是时候开始实现应用了。最简单的方式就是创建一个应用，这个应用将数据模型渲染到 UI 上，但是没有交互功能。拆分这两个过程是最简单的，因为构建一个静态的版本仅需要大量的输入，而不需要思考；但是添加交互功能却需要大量的思考和少量的输入。我们将会知道这是为什么。 为了创建一个渲染数据模型的应用的静态版本，你将会构造一些组件，这些组件重用其它组件，并且通过 _props_ 传递数据。 _props_ 是一种从父级向子级传递数据的方式。如果你对 _state_概念熟悉，那么*_不要使用 state *_来构建这个静态版本。 state 仅用于实现交互功能，也就是说，数据随着时间变化。因为这是一个静态的应用版本，所以你并不需要 state 。 你可以从上至下或者从下至上来构建应用。也就是说，你可以从属性结构的顶部开始构建这些组件（例如，从 `FilterableProductTable` 开始），或者从底部开始（ `ProductRow` ）。在简单的应用中，通常情况下从上至下的方式更加简单；在大型的项目中，从下至上的方式更加简单，这样也可以在构建的同时写测试代码。 在这步结束的时候，将会有一个可重用的组件库来渲染数据模型。这些组件将会仅有`render()` 方法，因为这是应用的一个静态版本。位于树形结构顶部的组件（`FilterableProductTable` ）将会使用数据模型作为 prop 。如果你改变底层数据模型，然后再次调用 `React.render()` ， UI 将会更新。查看 UI 如何被更新和什么地方改变都是很容易的，因为 React 的**单向数据流**（也被称作“单向绑定”）保持了一切东西模块化，很容易查错，并且速度很快，没有什么复杂的。 如果你在这步中需要帮助，请查看[ React 文档](http://facebook.github.io/react/docs/)。 ### 穿插一小段内容： props 与 state 比较 在 React 中有两种类型的数据“模型”： props 和 state 。理解两者的区别是很重要的；如果你不太确定两者有什么区别，请大致浏览一下[官方的 React 文档](http://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html)。 ## 第三步：识别出最小的（但是完整的）代表 UI 的 state 为了使 UI 可交互，需要能够触发底层数据模型的变化。 React 通过 **state** 使这变得简单。 为了正确构建应用，首先需要考虑应用需要的最小的可变 state 数据模型集合。此处关键点在于精简：_不要存储重复的数据_。构造出绝对最小的满足应用需要的最小 state 是有必要的，并且计算出其它强烈需要的东西。例如，如果构建一个 TODO 列表，仅保存一个 TODO 列表项的数组，而不要保存另外一个指代数组长度的 state 变量。当想要渲染 TODO 列表项总数的时候，简单地取出 TODO 列表项数组的长度就可以了。 思考示例应用中的所有数据片段，有： * 最初的 products 列表 * 用户输入的搜索文本 * 复选框的值 * 过滤后的 products 列表 让我们分析每一项，指出哪一个是 state 。简单地对每一项数据提出三个问题： 1. 是否是从父级通过 props 传入的？如果是，可能不是 state 。 2. 是否会随着时间改变？如果不是，可能不是 state 。 3. 能根据组件中其它 state 数据或者 props 计算出来吗？如果是，就不是 state 。 初始的 products 列表通过 props 传入，所以不是 state 。搜索文本和复选框看起来像是 state ，因为它们随着时间改变，也不能根据其它数据计算出来。最后，过滤的 products 列表不是 state ，因为可以通过搜索文本和复选框的值从初始的 products 列表计算出来。 所以最终， state 是： * 用户输入的搜索文本 * 复选框的值 ## 第四步：确认 state 的生命周期 OK，我们辨别出了应用的 state 数据模型的最小集合。接下来，需要指出哪个组件会改变或者说_拥有_这个 state 数据模型。 记住： React 中数据是沿着组件树从上到下单向流动的。可能不会立刻明白哪个组件应该拥有哪些 state 数据模型。**这对新手通常是最难理解和最具挑战的，**因此跟随以下步骤来弄清楚这点： 对于应用中的每一个 state 数据： * 找出每一个基于那个 state 渲染界面的组件。 * 找出共同的祖先组件（某个单个的组件，在组件树中位于需要这个 state 的所有组件的上面）。 * 要么是共同的祖先组件，要么是另外一个在组件树中位于更高层级的组件应该拥有这个 state 。 * 如果找不出拥有这个 state 数据模型的合适的组件，创建一个新的组件来维护这个 state ，然后添加到组件树中，层级位于所有共同拥有者组件的上面。 让我们在应用中应用这个策略： * `ProductTable` 需要基于 state 过滤产品列表，`SearchBar` 需要显示搜索文本和复选框状态。 * 共同拥有者组件是 `FilterableProductTable` 。 * 理论上，过滤文本和复选框值位于 `FilterableProductTable` 中是合适的。 太酷了，我们决定了 state 数据模型位于 `FilterableProductTable` 之中。首先，给`FilterableProductTable` 添加 `getInitialState()` 方法，该方法返回 `{filterText: '', inStockOnly: false}` 来反映应用的初始化状态。然后传递 `filterText` 和 `inStockOnly`给 `ProductTable` 和 `SearchBar` 作为 prop 。最后，使用这些 props 来过滤 `ProductTable`中的行，设置在 `SearchBar` 中表单字段的值。 你可以开始观察应用将会如何运行：设置 `filterText` 为 `"ball"` ，然后刷新应用。将会看到数据表格被正确更新了。 ## 第五步：添加反向数据流 到目前为止，已经构建了渲染正确的基于 props 和 state 的沿着组件树从上至下单向数据流动的应用。现在，是时候支持另外一种数据流动方式了：组件树中层级很深的表单组件需要更新 `FilterableProductTable` 中的 state 。 React 让这种数据流动非常明确，从而很容易理解应用是如何工作的，但是相对于传统的双向数据绑定，确实需要输入更多的东西。 React 提供了一个叫做 `ReactLink` 的插件来使其和双向数据绑定一样方便，但是考虑到这篇文章的目的，我们将会保持所有东西都直截了当。 如果你尝试在示例的当前版本中输入或者选中复选框，将会发现 React 会忽略你的输入。这是有意的，因为已经设置了 `input` 的 `value` 属性，使其总是与从`FilterableProductTable` 传递过来的 `state` 一致。 让我们思考下我们希望发生什么。我们想确保无论何时用户改变了表单，都要更新 state 来反映用户的输入。由于组件只能更新自己的 state ， `FilterableProductTable` 将会传递一个回调函数给 `SearchBar` ，此函数将会在 state 应该被改变的时候触发。我们可以使用 input 的 `onChange` 事件来监听用户输入，从而确定何时触发回调函数。`FilterableProductTable` 传递的回调函数将会调用 `setState()` ，然后应用将会被更新。 虽然这听起来有很多内容，但是实际上仅仅需要几行代码。并且关于数据在应用中如何流动真的非常清晰明确。 ## 就这么简单 希望以上内容让你明白了如何思考用 React 去构造组件和应用。虽然可能比你之前要输入更多的代码，记住，读代码的时间远比写代码的时间多，并且阅读这种模块化的清晰的代码是相当容易的。当你开始构建大型的组件库的时候，你将会非常感激这种清晰性和模块化，并且随着代码的复用，整个项目代码量就开始变少了 :)。