React 笔记 | React 的出现和构建思维

写在开始
谢谢即友 Ⓙ透明T 帮我建的 RSS 主题。
这里会出现一些前端方向或其他开发基础的技术学习笔记，可读性会比较差一些。现在算是启动阶段，在记录的 React 笔记系列，是听分享的过程里的随手记，有结构但是内容会显得只言片语一些。
未来会在填充过程中慢慢开垦和进化。

React 出现的原因以及解决的问题

传统 DOM API 关注了太多细节。可以参照之前 jQuery 的各种细节的方法。—— React 始终整体刷新页面，从而不需要关心细节。例如更新列表这件事情，React 只关心前后状态发生了变化，但是并不关心具体是怎么变的（只关心状态和最终 UI 是什么样），但以往的实现方法就是需要知道列表增加了几项，增加的位置是什么。

React 为什么简单：

1. 引入组件的概念
2. 只有四个必须的 API
3. 单向数据流
4. 有完善的错误提示

React 解决了 UI 问题，那 data motel 如何解决？

传统 MVC 很复杂。React 提出了 Flux 架构来解决这个问题，建立在 React 以状态来建立 UI 的这个基础上。

单向逻辑：
Action Creators --Actions--> Dispatcher --Callback--> Store（UI的唯一基础）-> View --User Interactions--> Action Creators

Flux 衍生出了 Redux Mobx。

如何以组件的方式构建 UI

props + state -> View
外部传进来的属性和内部维护的状态，决定了这个组件最终长什么样子。

1. 像一个状态机，不提供方法，状态是什么直接决定了结果
2. 可以理解为一个纯函数
3. 单向数据流，外面只通过 props 来传递数据进来，外面知道内部状态变化，一定是内部暴露了一个事件

创建组件的例子

1. 创建静态 UI
2. 考虑状态是内部维护还是外部传入
3. 交互方式：内部用户进行的操作如何暴露出去给人使用

受控组件和非受控组件：

• 受控：由外部控制 state
• 非受控：自己内部维护 state

其实这两者的区别就在于在哪里维护 state 值，在外部处理时，需要将状态和内部同步，而在内部处理时，则需要内部把状态暴露给外部。

创建组件采用单一职责原则：

• 一个组件只做一件事情
• 组件变复杂的时候，应该拆分成小组件

数据状态管理的 DRY 原则：

1. 能通过其他状态而计算到的状态，就在使用的时候计算，而无需单独储存，从而避免重复的状态保存
2. 组件尽量无状态（即不是自己内部维护 state），尽量使用 props 传递进去