Thinking in React 观后感

原文地址：Thinking in React

今天在翻阅 React 文档，看到一篇名为「Thinking in React」的文章以为写的很好。文章介绍了如何使用 React 构建一个应用，并非手把手教你如何构建 ，而是在教你应该如何思考 🤔。其中的一些点是我以前未曾考虑到的，所以在这里作一个总结：

01. UI layer 与 React 组件的对应

Step 1 讲的就是如何划分 UI 为 React 组件，其中谈到一个观点：

Their Photoshop layer names may end up being the names of your React components!

以 Photoshop 图层名称命名 React 组件，我作过 UI 设计的工做，我以为这种思路是很连贯的，在图层命名时，你率先须要思考的一个问题是“这是什么”，以把某个控件和其余控件区分开来。所以当使用 React 开发时，组件的颗粒度就已经有了一个大致的划分。

---

02. 用户界面拆解

我特别喜欢 React 的组件化思想，将一个页面拆分红不一样的组件，在将一个组件打散为不一样的小组件就像乐高同样很是有秩序感，但我一开始常常会面临的问题是，「决定组件颗粒度的大小」。一般状况下，问题出在我是否须要对某个组件进一步拆分？个人经验是思考「这个组件有 3 个以上的 DOM 元素组成，而且须要复用吗？」这个问题，若是是，则说明须要从父组件拆分出来，变为独立的组件；

---

03. 构建应用的顺序

文章建议构建 React 应用时，应该先将全部的数据都以 props 的方式传递，而后再去思考什么样的数据应该更改成 state。整个文档特别强调 state 的最小必要性原则，并给出了判断的指南：

1. 数据是由父级组件传递来的吗？若是是，不要设置为 state；
2. 数据是始终不变的吗？若是是，不要设置为 state；
3. 数据可以基于组件已有的 props 或 state 计算获得吗？若是能够，不要设置为 state；

我想应该不少人据说过这些判断条件，但彷佛不多人去讨论为何咱们要保障 React 应用内的 state 是最少限度的？这勾起了个人好奇。

通过一番探索，我得出的结论是，咱们之因此要让组件只保留必要的 state 数据，是由于「state 会破坏 React 单向数据流的机制」。

让咱们站在组件的角度思考，组件的 UI 应该是数据的反射，一个好的组件应该傻瓜的只根据接收的数据变化，不用操心其他的任何事情。可是一旦组件内部出现了 state 事情就不同了，组件变得不在单纯，而且拥有了本身改变数据，而后再按照数据变化的特性。而当这样的组件增多时，咱们想要找到「数据」和「UI」的映射关系就很是复杂了，这使得咱们不容易理解应用的更新逻辑，在发生错误时，没法第一时间定位到问题发生的地点。

所以，经过保障 state 只在必要时被定义，或者将 state 经过各类方式妥善的管理，就是打造强壮 React 应用的关键。能够说，正确地管理 state 就是开发完美 React 应用的关键。

---

参考资料：
Thinking in React
Common React.js mistakes: Unneeded state
You Probably Don't Need Derived State