架构哲学与图例
变化并不是万恶之源，问题的关键在于你是否有能力跟踪和掌控变化。
良好的架构可能起步很慢, 但一旦你将它变得健壮起来, 则将毋庸置疑的为业务提供长久而深远的重要价值. 作为项目的核心架构者, 你应该说服项目经理留给架构充分的时间,即使这种价值也许不会立竿见影.
Reaxes诞生的契机：
在构建某个区块链应用的前端侧时，我深入地思考了当下前端潮流中主流的React数据流方案，有的有意将简单的问题复杂化，生搬硬造出不适合前端域的概念和大量模板代码（主要代表有redux系）；有的使用了看似简单确在稍复杂业务场景中就会产生巨大心智负担且无必要刷新组件的技术（react hooks系）。但完全不使用hooks又无法解决对组件内部数据和逻辑抽离封装的问题。
于是reaxes诞生了，它借助了mobx简单的自动响应式方案，可实现不依赖于视图的前端逻辑（reaxel）。当你需要让某个视图组件渲染时只需要轻轻“勾”入它，完全不会对组件产生耦合。reaxel只是依据业务逻辑改变数据，然后自动地重新渲染那些用到了数据的“视图”。
拒绝过度设计, reaxes的每一处都奉行极致务实主义，为良好的业务架构服务，没有花里胡哨的噱头。
架构图
使用Reaxes的好处
最佳实践
reaxel应该是以合适粒度拆分的分布式业务逻辑
视图状态（state）应该是业务逻辑数据的一部分，或数据的衍生。它们由业务逻辑自然地产生并分发给视图层进行渲染，
视图层（view/view-model）不应承载业务逻辑，只应负责用户的输入与视图呈现，你的前端应用架构应当能够完全脱离真实的用户输入(比如替换为mock-input)而不需要改动应用逻辑依然可以正常运作。
前端应用的大部分基础服务逻辑（reaxel）应该具有即时部署特性：当应用在被访问的那一刻所有reaxel逻辑即立即被注册和(部分地)执行完毕。这样的约定带来的好处是显而易见的 — 一开始所有的reaxel就完成了彼此之间的联结，有哪些服务在用户访问到页面时已经执行完毕是显而易见的。
reaxes受到了RH的启发并借助了mobx来实现了响应式&分布式的SALL抽象 , 可以视为是对其思想的一种继承和改进.
它致力于解决跨组件通信与状态&逻辑共享问题，且一并解决了RH与CC逻辑无法复用的割裂问题。
Reaxes在未来将会支持不同的视图库, 而非仅仅是React —— Reaxel定位于Module层具有统一设计模式的分布式服务模块。所以无论是何种视图框架，只要与视图库相配套的驱动器搭配，就能跨视图库提供统一的SALL与开发体验。
Reaxes不使用React的MVVM架构，而是接管了其View-Module中的M ，这使得视图层几乎不承载公共的逻辑和状态。React-View转而提供View-Controller：将其它依赖于React组件的逻辑作为action来触发reaxel提供的API。
Reaxel
即时部署
基于reaxes的React工程需要遵守一个约定：即 静态且可被用户访问到的任何reaxel都在浏览器的第一次执行时部署完成了，而无论用户是否使用到了这个服务。
(举个例子:Form组件与Create-form-from-template页面)
用户可以通过模板页面来跳转至Form页面,并在跳转时将模板字段预填至Form组件内。
传统的开发方式无外乎两种方案: 1. 将此字段提升到公共状态里面再向下分发; 2. 通过某些方式(props或url)传递给Form。
而reaxes则带来了另一种可能: 由于reaxel-form在页面打开时已经被部署， 内部的store可以被reaxel-template访问 , 所以只需在跳转时修改reaxel-form的store,再进行跳转。
可以这么说：reaxes所维护的服务并不是必须服务于已存在的视图，那些可能被用到的视图的状态在渲染前就已暗流涌动。基于这样的架构设计 , 使用了极低廉的代价(初始化所有reaxel)而获得了极高的拓展性与便利性，将视图层与数据驱动层彻底隔离开。
去生命周期化
基于reaxes架构的SALL在绝大多数情况下不需要关心React组件的生命周期，那是因为组件能够精准地知道哪个store的哪个属性发生了变化，并派发更新。
但凡事总有例外：多数情况下Reaxes.depsDiffing()函数需要在某个组件卸载时清除对回调的依赖记忆，以在下一次使用相同deps调用时触发执行。
如果某些业务逻辑确实需要生命周期的参与，reaxel内也可以通过统一的API来勾入RH和CC通用的生命周期逻辑，它们在Reaxes这个静态类里。不推荐。
而不像某些使用了context或顶层store技术的状态管理库--即使该组件所需的任何state或props都没有发生变化，react组件仍然被运行了（尽管在渲染阶段被diff阻止了）。
而这也是为什么RH和CC需要提供API来让用户手动比对。
分布式
响应式
对比RH(React Hooks)
RH的特性(或许在复杂业务中可以称之为缺陷) :
使用RH抽象的SALL无法在class组件中使用, 造成了FC和CC的生态割裂.
RH具有传染性, 会导致callee RH 刷新 claller RH的作用域
RH被设计为在React调度层重复执行多次执行, 通过比对依赖数组来决定是否重新执行某些逻辑
Last updated