Closed yinguangyao closed 4 years ago
react作为现今最火热的前端框架，很多项目都采用了react构建界面，但是react自身也有许多不足，比如状态管理和组件通信等等，随着项目越来越大，只靠react很难满足需求，所以很多状态管理库由此诞生。
如果是比较小的个人项目，完全可以不使用任何状态库，可以在容器（顶层）组件里面使用一个类似redux store的大state，将这个state通过props和context传给子组件，可以将setState方法从容器组件传下去，或者将子组件的修改state方法放到容器组件中，这样就可以轻松实现状态管理，但是会造成容器组件过于臃肿。
redux是我们公司老项目中最常用的状态库，redux遵守dispatch -> action -> reducer -> store -> view的一套操作流程，好处是具有时间回溯，这在错误调试的时候非常适用。数据流动清晰，组件之间通信也更加方便，缺点就是需要在多个文件里面写很多action和reducer，在小项目中就会得不偿失，但是在大型项目中有利于以后维护。
relite是我们部门的工业聚大神写的一个类redux库，总体思想和redux一致，区别只是在于写法上的不同，relite中剔除了reducer的概念，将action和reducer合一，以原来的action.type来命名reducer函数，每个函数最终都会返回整个store，这样无需写一串长长的switch case语句，但也带来了一系列问题，比如由于返回整个store，很难配合PureComponent做性能优化。
mobx和redux走了完全不同的一条路，mobx更偏向vue等响应式库，通过getter、setter（Proxy）来实现对数据的监听，而mobx-react会提供observer方法来对组件依赖的响应式数据进行收集，这样带来的好处就是可以做到更细粒度的控制组件渲染，可以带来更高效的性能，能够做到只渲染子组件而不渲染父组件，甚至可以用组件内部可观察的数据来代替state，避免由于state的‘异步’特性导致的问题，这些在react和redux里面是无法做到的。
由于redux写法过于繁琐，所以出现了很多对redux重新思考后而设计的库，其中rematch是比较优秀的一个。 我们都知道redux的写法很繁琐，比如createStore的时候，为什么要写成createStore(reducers, initialStore, applyMiddleware(thunk, logger))这种形式，写成可配置的不好吗？const store = {middleware: [thunk, logger], initialStore: {}, reducers: {count}}这种不是更好？为什么reducer里面还要用switch这么繁琐的条件语句？表驱动不是更好？ 基于这种考虑，rematch应然而生。rematch将reducer和action合并到一个对象中，提供了effects来承载异步操作（请求接口等），这样的好处就是用户触发的action实际上就是reducer，这和relite的思想基本一致。
如果是小型项目，也许你不需要使用状态管理库，如果实在操作不好，那么可以考虑一下relite，如果是中大型项目，可以考虑使用mobx，如果是业务很复杂的项目，那么建议使用redux和rematch。
react作为现今最火热的前端框架，很多项目都采用了react构建界面，但是react自身也有许多不足，比如状态管理和组件通信等等，随着项目越来越大，只靠react很难满足需求，所以很多状态管理库由此诞生。
全局state
如果是比较小的个人项目，完全可以不使用任何状态库，可以在容器（顶层）组件里面使用一个类似redux store的大state，将这个state通过props和context传给子组件，可以将setState方法从容器组件传下去，或者将子组件的修改state方法放到容器组件中，这样就可以轻松实现状态管理，但是会造成容器组件过于臃肿。
redux
redux是我们公司老项目中最常用的状态库，redux遵守dispatch -> action -> reducer -> store -> view的一套操作流程，好处是具有时间回溯，这在错误调试的时候非常适用。数据流动清晰，组件之间通信也更加方便，缺点就是需要在多个文件里面写很多action和reducer，在小项目中就会得不偿失，但是在大型项目中有利于以后维护。
relite
relite是我们部门的工业聚大神写的一个类redux库，总体思想和redux一致，区别只是在于写法上的不同，relite中剔除了reducer的概念，将action和reducer合一，以原来的action.type来命名reducer函数，每个函数最终都会返回整个store，这样无需写一串长长的switch case语句，但也带来了一系列问题，比如由于返回整个store，很难配合PureComponent做性能优化。
mobx
mobx和redux走了完全不同的一条路，mobx更偏向vue等响应式库，通过getter、setter（Proxy）来实现对数据的监听，而mobx-react会提供observer方法来对组件依赖的响应式数据进行收集，这样带来的好处就是可以做到更细粒度的控制组件渲染，可以带来更高效的性能，能够做到只渲染子组件而不渲染父组件，甚至可以用组件内部可观察的数据来代替state，避免由于state的‘异步’特性导致的问题，这些在react和redux里面是无法做到的。
rematch
由于redux写法过于繁琐，所以出现了很多对redux重新思考后而设计的库，其中rematch是比较优秀的一个。 我们都知道redux的写法很繁琐，比如createStore的时候，为什么要写成createStore(reducers, initialStore, applyMiddleware(thunk, logger))这种形式，写成可配置的不好吗？const store = {middleware: [thunk, logger], initialStore: {}, reducers: {count}}这种不是更好？为什么reducer里面还要用switch这么繁琐的条件语句？表驱动不是更好？ 基于这种考虑，rematch应然而生。rematch将reducer和action合并到一个对象中，提供了effects来承载异步操作（请求接口等），这样的好处就是用户触发的action实际上就是reducer，这和relite的思想基本一致。
如果是小型项目，也许你不需要使用状态管理库，如果实在操作不好，那么可以考虑一下relite，如果是中大型项目，可以考虑使用mobx，如果是业务很复杂的项目，那么建议使用redux和rematch。