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 的最小必要性原则，并给出了判断的指南：
- 数据是由父级组件传递来的吗？如果是，不要设置为
state； - 数据是始终不变的吗？如果是，不要设置为
state； - 数据能够基于组件已有的
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
