这是我参与「掘金日新计划 · 8 月更文挑战」的第21天，点击查看活动详情
在 UI 层开发中，数据状态管理非常重要，一个复杂的前端应用一定会有一套完善的状态管理机制。一个最简单的状态管理系统就是 const store = {} ，有一个地方放置共享数据信息，这就是状态管理的最基础需求。但是只有这样还不够，如何以正确的方式读取写入，如何将状态信息和 UI 层逻辑更好的结合，如何构建可维护性更好的状态机制，这就是后续要考虑的问题了。这一节来深入了解一下前端的状态管理。
一个状态管理系统分为两部分，一部分是读取，一部分是修改。前面的最简单使用一个对象构建的 store 功能非常基础，读取就是直接 store.xxx，修改就是 stroe.xxx = xxx，没有任何限制。一个系统没有限制就大概率会有问题，这个 store 一个最明显的问题就是谁都可以修改，对 store 修改不做任何限制就可能存在一些非预期的操作，为了解决这个问题，进化版本的 store 引入了 action 的概念。
引入 action 的概念后，整个 store 分为两部分，一部分是 state，是实际在 store 中存储的数据内容，另一部分是 action，封装了 store 的更新方法。这样就有了一个稳定可控的更新逻辑，相比于最初的版本，store 已经开始具备一定的规范，在此基础上发展出了著名的 Flux。
Flux 是一种架构设计思想，它把一个应用分为四部分：view、action、dispatcher、store，view 是视图层。action 是动作，描述了数据如何改变，包含 type 和 payload 两部分，store 只能通过 action 改变。dispatcher 是事件派发器，它接收 action，把 action 分发给 store。store 存储了状态和更新方法，一旦发生更新，通知 view 更新视图。这种模式的核心是单向数据流，视图发起 action，由 dispatcher 发给 store，store 更新数据并通知视图。这里 action 只是一个描述更新行为的对象，具体的数据处理在 store 中，这里的 store 可以有多个。
现在流行的状态管理工具无非是 Redux、Vuex、Mobx 等，它们或多或少的都借鉴了 Flux 的思想，但是具体的实现上又和 Flux 有一定差异。这里主要来看 redux，相比于原始的 flux，redux 最大的特点就是 store 只能有一个，redux 中的 store 承担了两部分工作，一个是存储 store 中的 state 数据，另一个就是承担了 dispatcher 的任务，上面的 dispatch 方法可以派发 action。action 和 flux 中一样，也是由视图层发出来的，通过 dispatcher 派发出去，最终的处理者不是 store 本身，而是 reducer。reducer 是一个纯函数，它可以根据 action 的 type 对 state 进行处理，最后返回一个新 state 来代替原有 state。redux 一定程度上实现了 flux 思想，又不完全相同，它保留了单向数据流的优势，又增加了单数据源和纯函数的限制。
除了 redux 其他的状态管理工具也有自己的特点，但是核心思想又大同小异，很多人也都会去实现自己的状态管理工具，因为说到底这个东西没什么复杂的。因为 redux 本身实现的很精简，直接使用会写很多样板代码，大家也会选择在其基础上封装或是直接重写自己的状态管理工具。
使用 solid 开发也需要使用状态管理工具，solid 本身也不限制使用哪些状态管理工具，不过 solid 本身内置了一个 store，我们是可以选择使用 solid 自带的 store 来作为状态管理工具的。solid 中的 store 的实现也和上面介绍的状态管理工具差不多，因为说到底这个东西也没什么太过复杂的地方，下一篇文章我们来看一下 store 的内部实现。
