本文目录导航：
2021年,react形态治理mobx和usereducer+usecontext怎样选?
2021年选用React形态治理时，面临mobx和usereducer+usecontext的抉择。
但是，咱们首先须要意识到React Concurrent的开发难题，重要源于tearing疑问，即外部形态不受React异步伐度控制，造成形态杂乱。
tearing深刻解释为外部形态不受控，特意是与Redux、Mobx等形态治理库相关。
这些库中的外部形态治理，甚至包含Recoil，均或者惹起疑问。
关于可变的外部形态，如Mobx，疑问尤为显著。
因此，选用React形态治理时，外部的state和context是首选。
外部形态治理工具如Redux、Mobx等，由于存在tearing疑问，或者惹起形态杂乱。
这些疑问在这些形态治理工具被淘汰后，React的稳固性也将获取改善。
Recoil - Facebook出品的全新React形态治理库
出于兼容性和便捷性的思考，咱们介绍经常使用React内置的形态治理配置，而非外部的全局形态。
但是，React存在必定的局限性：咱们希冀在坚持API和语义与React尽或者凑近的同时，处置这些疑问。
Recoil定义了一个有向图，它与React树正交，但同时也外在附着在React树上。
形态变动从图的根部（atom）经过纯函数（selector）流向组件。
其原理如下：经常使用Recoil可以创立一个数据流的图，它从Atom（共享形态）经过Selector（纯函数）流到你的React组件。
Atom是组件可以订阅的形态单位。
Selector可以同步或异步转换这个形态。
Atom是形态的单位。
它们是可降级和可订阅的：当一个Atom被降级时，每个被订阅的组件都会用新的值来从新渲染。
它们也可以在运转时创立。
Atom可以用来替代React本地组件形态。
假设从多个组件中经常使用同一个Atom，一切这些组件都会共享它们的形态。
Atom是经常使用atom函数创立的：Atom须要一个惟一的key，这个key用于调试、耐久化，以及某些初级的API，让你看到一切Atom的图。
两个Atom有相反的key是一个失误，所以要确保它们是全局惟一的。
和React组件形态一样，它们也有一个自动值。
要从组件中读取和写入Atom，咱们经常使用一个名为useRecoilState的钩子。
它就像React的useState一样，但如今组件之间可以共享形态：点击该按钮会把按钮的字体大小参与一个字号。
但如今一些其余组件也可以经常使用雷同的字体大小。
Selectors是一个纯函数，它接受Atom或其余Selectors作为输入。
当这些抢先的Atom或Selectors被降级时，Selectors函数将被从新评价。
组件可以像Atom一样订阅Selectors，当Selectors出现变动时，组件就会被从新渲染。
Selectors用于计算基于形态的派生数据。
这让咱们可以防止冗余形态，理论不须要reducers来坚持形态的同步和有效。
相反，一个最小的形态集被存储在Atom中，而其余的一切都作为该最小形态的函数有效计算。
由于Selectors可以跟踪哪些组件须要它们，以及它们依赖哪些形态，因此它们使这种配置方法愈加高效。
从组件的角度来看，Selectors和Atom具备相反的接口，因此可以相互替代。
Selectors是用selector函数来定义的：get属性是要计算的函数。
它可以经常使用传递给它的get参数访问Atom和其余Selectors的值。
每当它访问另一个Atom或Selectors时，就会创立一个依赖相关，这样降级另一个Atom或Selectors就会造成这个Atom或Selectors被从新计算。
在这个fontSizeLabelState示例中，Selectors有一个依赖相关：fontSizeStateAtom。
从概念上讲，fontSizeLabelStateSelectors的行为就像一个纯函数，它以fontSizeState作为输入，并前往一个格局化的字体大小标签作为输入。
Selectors可以经常使用useRecoilValue()来读取，它取一个Atom或Selectors作为参数并前往相应的值。
咱们不经常使用useRecoilState()，由于fontSizeLabelStateSelectors是无法写的（关于可写Selectors的更多消息，请参阅SelectorsAPI参考）：如今点击该按钮会触发两件事：它可以参与按钮的字体大小，同时还可以降级字体大小标签以反映以后的字体大小。
以上就是Recoil官网文档的局部简介。
想了解更多消息请查阅官网网站/
React 形态治理库: Mobx
React，作为视图层的外围库，专一于保养视图与形态的逐一对应，让开发者专一于形态治理。
但是，随着运行复杂性的优化，形态治理疑问逐渐凸显，这时须要引入像Mobx这样的形态治理库。
本文重要聚焦于Mobx，讨论其外围概念——observable、observer和action，以及与Redux的对比。
Mobx的外围思念在于便捷易用。
经过observable接口，开发者可以定义可观察的数据，这些数据理论代表组件形态，读写操作会被智能阻拦并触发视图降级。
组件经过observer变为照应式，仅当依赖的可观察数据变动时才会智能降级，防止了不用要的组件渲染。
而action则规则了修正形态的方式，确保了形态的治理和可预测性。
相比之下，Redux强调无法变数据，每次形态变动都会生成新的形态对象，确保了数据的可预测性和历史可追溯性。
但是， Mobx 的可变数据和便捷操作方式在处置前端的反作用和极速迭代需求上更具长处。
关于形态治理，团体偏差于 Mobx，尤其是在小型至中型名目中，其繁复性与业务场景的符合度更高。
展望未来，Mobx与无法变数据的融合，如MST（Mobx State Tree），提供了形态的可变和无法变方式一致的处置打算。
MST准许开发者定义复杂的树状形态结构，并经过onSnapshot和action成功形态的高效转化，为形态治理提供了新的或者。
虽然MST尚处于早期阶段，但其后劲值得开发者关注和尝试。
