> For the complete documentation index, see [llms.txt](https://zg-zhang.gitbook.io/note/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zg-zhang.gitbook.io/note/react/offical-website/main-concepts/thinking-in-react.md).

# React 哲学

Thinking in React

## 第一步：将设计好的 UI 划分为组件层级

* 用方框圈出每一个组件 包括它们的子组件，并且以合适的名称命名
* 可以将组件当作一种函数或者是对象来考虑，根据 **单一功能原则** 来判定组件的范围 
  * 一个组件原则上只能负责一个功能
  * 如果需要负责更多的功能，这时候就应该考虑将它拆分成更小的组件
* 确定了设计稿中应该包含的组件，接下来我们将把它们描述为更加清晰的层级

## 第二步：用 React 创建一个静态版本

* 先用已有的数据模型渲染一个不包含交互功能的 UI
* 最好将渲染 UI 和 添加交互 这两个过程分开
  * 编写一个应用的静态版本时，往往需要编写太多代码，而不需要考虑太多交互细节
  * 添加交互功能时则要考虑大量细节，为不需要大量代码
* **完全不应该使用 state** 构建静态版本
  * state 代表了随时间会产生变化的数据，应当仅在实现交互时使用
* 可以采用 自上而下 或者 自下而上 构建应用
* React 单向数据流 也叫单向绑定的思想使得组件模块化，易于快速开发

## 第三步：确定 UI state 的最小且最完整的表示

* 为了正确的构建应用，你首先需要找出应用所需的 state 的最小表示，并根据需要计算出其他所有数据
  * 只保留应用所需的可变 state 的最小集合，其他数据均由它们计算产生
* 通过问自己以下三个问题，你可以逐个检查相应数据是否属于 state
  * 该数据是否是由父组件通过 props 传递而来的？如果是，那它应该不是 state
  * 该数据是否随时间的推移而保持不变？如果是，那它应该也不是 state
  * 你能否根据其他 state 或 props 计算出该数据的值？如果是，那它也不是 state

## 第四步：确定 state 放置的位置

* 对于应用中的每一个 state：
  * 找到根据这个 state 进行渲染的所有组件
  * 找到他们的共同所有者 common owner 组件 在组件层级上高于所有需要该 state 的组件
  * 该共同所有者组件或者比它层级更高的组件应该拥有该 state
  * 如果找不到一个合适的位置来存放该 state，就可以直接创建一个新的组件来存放该 state，并将这一新组件位置高于共同所有者组件层级的位置

## 第五步：添加反向数据流

* 处于较低层级的组件更新较高层级中的 state
* React 使用一种比传统双向绑定略微繁琐的方法来实现反向数据传递，但这种需要显式声明的方法更有助于人们理解程序的运作方法