共计 3481 个字符，预计需要花费 9 分钟才能阅读完成。
讲一个悲伤的故事
原本这篇文章应该是上周写完的。
故事产生在一周前，我在 segmentfault 在线编辑文章，写了差不多两个小时，在贴了一张图片失败之后，而后 ctrl+ z 撤销了一步，后果整个文档被霎时清空了，编辑器还主动保留了清空态。
这一刻，有点心凉，好像忽然被浇了一桶冷水。
第一工夫，关上浏览器控制台，去翻缓存，后果 localStorage 外面空洞无物，过后就感觉心愿不大了，空想着他们服务端能保留某个时刻的记录。
微信分割了他们的客服小姐姐，晚饭后回复我：“技术人员上班了，今天帮忙查看，问我急不急?”。还能怎么？开发何必尴尬开发，过后就放过了她。
第二天，通过他们一番追踪，服务端没有任何记录 ……
终局就是当初这样，我再从新写一遍。
通过这个事件，也能够看出，segmentfault 的数据状态管理机制还是有缺点的，容错机制不太好，至多缓存机制不太行，共勉!
概述
有个头痛的问题，什么是恋情?
噢噢，状态错乱了，“状态凌乱”就这个头痛的问题。
随着前端利用的规模越来越宏大，业务复杂度直线拉升。状态治理也成为了重中之重，DDD 畛域驱动模型也逐步流行。
随着我的项目倒退，单元测试也变成了很重要的一个环节，随着业务逻辑复杂度的减少，问题关注点间接爆炸，人力心智累赘越来越高。
所以不论是 为了更好地开发模型 还是 更容易的单元测试，如何更好地治理数据状态都 成了一个 外围环节。
比方，畛域状态 要和 UI 状态拆散；按照 DDD 畛域驱动模型构建 数据 Store，而不是根据 UI 来构建。
状态数据构建 是 全局的还是 部分的，衍生数据 如何主动生成，副作用变更逻辑如何书写？
数据逻辑 如何 和 UI 视图 解耦，又如何不便注入 UI 应用，怎么进行不便的通信？
社区有那么多套 所谓成熟的解决方案，咱们到底改用那套？
我的项目问题
回归事实，聚焦到目前业务我的项目上。一个三年左右的我的项目了，技术栈是十分惯例的 React 框架搭建，初期是应用 Redux 做的的状态治理；起初 React 公布了 Hook 个性，看代码记录，大家果决摈弃了 Redux，拥抱 Hook，我的项目从某个节点开始，成了清一色的 Function 式。
好了，当初轻易找个我的项目开发者征询一下，我的项目存在什么技术问题，开发体验如何？霎时就能开启吐槽模式：
- 状态 凌乱，没有 畛域状态 UI 状态辨别
- 全局状态 和 部分状态 设计不合理
- 数据流逻辑解决 耦合 UI 视图 (CodeReview 难，bug 不好追踪，单元测试艰难)
- props drilling 而且传递过程 命名多变
- props 传递粒度 不够精密（渲染频率减少）
- hook 应用形式 近乎 demo 形式，极其不合理，无抽离，无封装
- Redux 样板代码较多；应用繁琐；
- 性能产生了问题，频繁渲染，无奈追踪什么操作 导致变更
- 开发方式 对人的要求较高，心智累赘较高
- 看起来做了一系列性能优化，还不如 vue 不优化
- …… 不一一列举了
那有解决方案吗？有，大家拉个会议一探讨，指定编码开发标准，严格 CodeReview，该优化的优化。
OK，问题解决了吗？没有，一段时间过后，代码格调对立了，可是这个真的不重要，问题还是那些问题，旧的代码能不动就不动，新代码就间接往上堆砌。
代码格调对立了，eslint 跑过了，可是相比零碎架构而言，这些流于形式的货色权重就很低了，重要性微不足道。
如果不做演变改良，熵增持续，零碎势必走向解体。
这个时候，咱们必须思考，呈现问题的实质起因到底是什么？
是历史遗留问题吗，是技术栈问题吗？
都不是，思前想后，还是人的问题，开发者本身的问题。
适度的自在必然导致凌乱。
React 设计理念 和 哲学思考都是很高的，自身是为了解决 UI 渲染问题；这就像一把神器，境界高的使用者如臂使指，用来所向无敌，事倍功半；境界不迭者，就会感觉深陷泥潭，拿不起来挥不动，终被反噬。
屠龙少年终成恶龙！
一个没什么开发教训，设计模式也不懂，框架立意也不清晰，读了几个 api 用来写我的项目的人，怎么能掌控好呢？
React 可能连开发多年的老鸟都不肯定能玩明确，上手难度高也不是空穴来风啊，大家可能只是习惯无脑的晓得大家这么说，哦，那就上手难度高。
可是为什么上手难度高，到底难点在哪里？照着 api 开发，难吗，一点也不对吧
Vue 技术栈为什么就没有这些问题？为什么很少呈现性能问题？
尤雨溪尤大 设计框架的时候，面向的应用群体是那些人？框架里帮咱们解决了什么问题？
所以，实质起因是什么，这里就很明确了，然而对于”人“，十分难以掌控。
咱们不可能招到的开发者都是十分完满合格的，另一方面，人提高是很艰难的，成长曲线都是漫长的 S 曲线。
那到底有么有一种计划能 升高人的因素，避免人 对系统架构造成侵蚀和毁坏呢？上面咱们剖析一下
各种解决方案
vue 全家桶
vue 的响应式设计模式，粒度十分精密，而且 依赖收集 和 依赖派发 逻辑全都有框架主动实现。开发者专一于业务逻辑即可，什么时候渲染，渲染频率管制 框架都帮咱们解决好了。
单文件模式，把 js，css，html 汇合在一起的组织形式，自身也是一种性能解耦.
vuex 专门为 vue 框架设计的状态治理库，无缝接入。
整体来说，开发体验还是十分好的，受众群体十分宏大，尤其对于初中级开发者来说，基本没有心智累赘。
既然框架为咱们思考了大部分性能，随着失去的就是 自定义的灵活性和扩展性，这可能是制约顶级大佬们施展自我的一个制约点，然而咱们不能随声附和，做拿来主义。对于绝大多数开发者来讲，还远远达不到触发这个制约点的高度。
对于 vue 技术栈相干的解说，这里就不开展阐明了，网上有一大堆剖析材料。
react (hook) + redux
React 自身只是一个 构建用户界面的 javascript 库，官网也是这么阐明的。它的外围两点是 虚构 dom 以及十分高效的 diff 算法，这才是它的底层竞争劣势。Vue 前期的迭代优化也有相干参考，比方引入了虚构 dom 机制。
初期全局状态治理，官网推出了 Redux，纯函数式编程，性能扩大通过中间件模式。
正如大家焦躁的一点，应用 redux，须要大量的模板代码，应用十分繁琐；还引入了其余各种概念，比方 connect 高阶组件，容器组件等概念；总之就是应用繁琐，样板代码宏大。
正是上述毛病，所以 Hook 推出之后，大家弹冠相庆，马上摈弃 redux 模式。而后 hook 仍然须要很高的了解老本，甚至比 Redux 要求更高。然而大家可能不假思索的照着 api 就开始开发了，导致清一色的 Function 产生，外部沉积了大量的 state，effect，函数体急剧收缩。hook 的状态设计分层 更是乌七八糟。props 传递凌乱。
讲道理，Redux 和 Hook 自身都是很好的，大家说起来可能感觉本人都懂，然而落到实处，生产进去的代码却远远不够水准。说到底，还是没懂相干技术的外围设计理念，以及想要解决的问题，思维高度有余导致滥用。
那有没有想应用 React 来构建 UI，又想领有 vue 的开发体验呢？答案是必定的，那就是 React + mobx
react + mobx
核心理念：回归初心，各自解决各自的问题，React 专一于构建用户界面 UI，mobx 专一于数据逻辑治理，尘归尘，土归土。
应用形式请参考
咋一看，react + mobx 不就是 繁琐版的 vue 吗？没故障，看起来的确是这样，但又不止于此。
咱们用 mobx 来设计 数据 Store 以及衍生数据和副作用 action 的变更，用 React 构建用户界面。最显著的一点就是 mobx 接管了 React 组件的渲染逻辑，把开发者从 渲染的问题上 解放了进去，升高了心智累赘。
数据逻辑内敛到 mobx 里，天然实现了 数据状态逻辑 和 UI 的解耦；也不便各自进行单元测试。
mobx 不同于 Redux，而是能够多 Store 实例存在，非常灵活，同时也解决了 数据 props 传递和 组件通信的问题。
在这种模式下开发，那怕一个没有教训的开发者轻易开发，也不会对系统的架构造成侵蚀和毁坏。
最佳实际
到了这里，差不多该有个论断了。
还是那句话，没有银弹，也没有屠龙刀，没有放之四海而皆准的解决方案。
如果你是个老手开发者，各种设计模式和框架理念了解不是很透彻，又想疾速构建利用，那么 vue 全家桶可能很适宜你上手。
如果你开发教训十分丰盛，做很多底层形象封装的工作，须要高度复用定制一些能力，须要业余，那么 React 技术栈可能比拟适宜你，因为你很强。
如果你喜爱应用 React，然而又想领有 Vue 的开发体验，那么 React + mobx 将非常适合你，你值得领有。
总结
这篇碎碎念写的比拟多，深度也欠缺，尤其前面很多技术细节，间接没有；不过无所谓了，这篇也不是解说技术应用的，就是吐吐槽，产生一些想法。
无关技术深度应用的话题，后续有工夫再聊！
