讲一个悲伤的故事这篇文章应该是上周写的。故事发生在一周前。我在线编辑了关于segmentfault的文章。我写了将近两个小时。发图片失败后，我ctrl+z撤消了一步。结果整个文档瞬间清空，编辑器也自动保存为清空状态。此刻，我觉得有些冷，仿佛突然被浇了一桶冷水。第一次，我打开浏览器控制台并检查缓存。结果，localStorage为空。那时候觉得希望渺茫。我想象他们的服务器可以在某个时间保存记录。微信联系了他们的客服小姐姐，吃完饭回复我：“技术员下班了，我明天帮忙看看，问我赶不赶时间？”。还有什么？为什么要难开发，我当时就让她去了。第二天，经过他们的一番追踪，服务器端没有任何记录……结局是这样的，我再写一遍。通过这件事也可以看出segmentfault的数据状态管理机制还是有缺陷的，容错机制不是很好，至少缓存机制做的不好，大家共勉！总览让人头疼，什么是爱情？哦，状态紊乱是的，“状态混乱”很头疼。随着前端应用的规模越来越大，业务复杂度线性增加。状态管理也成为重中之重，DDD领域驱动模型逐渐流行起来。随着项目的发展，单元测试也成为了一个非常重要的环节。随着业务逻辑复杂度的增加，问题的焦点直接爆发，人力和脑力的负担越来越高。所以无论是为了更好的模型开发还是更简单的单元测试，如何更好地管理数据状态成为了一个核心环节。例如，域状态应该与UI状态分离；数据存储应该根据DDD领域驱动模型构建，而不是根据UI。状态数据的构建是全局的还是局部的，如何自动生成派生数据，如何编写副作用变化逻辑？如何将数据逻辑与UI视图解耦，如何方便的注入到UI中，如何方便的进行通信？社区中所谓的成熟方案那么多，到底该换哪一个呢？项目问题回归现实，专注于当前的业务项目。这个项目已经进行了大约三年。技术栈是用非常传统的React框架构建的。一开始，它使用Redux进行状态管理。后来，React发布了Hook特性。翻看代码记录，大家果断抛弃Redux，拥抱Hook。该项目从某个节点开始，成为一个一体化的功能公式。好了，现在随便找个项目开发人员咨询一下，项目存在哪些技术问题，开发体验如何？瞬间可以开启吐槽模式：状态凌乱，没有域状态，UI状态区分全局状态和局部状态，设计不合理，数据流逻辑处理与UI视图耦合（CodeReview难，bug不易追踪，单元测试难）props钻取传递过程命名可变props传递粒度不够细（渲染频率增加）hook使用方式几乎是demo，极不合理、不分离、不打包的Redux样板代码较多；使用起来很麻烦；性能问题，频繁渲染，无法跟踪有什么操作，导致改变开发方式对人的要求更高，精神负担更高。似乎做了一系列的性能优化。最好不要优化Vue。。。不一一列举有解决办法吗？是的，大家开会讨论，明确编码开发规范，严格CodeReview，优化优化。好的，问题解决了吗？不是，过段时间代码风格就统一了，但这真的不重要，问题还是那些问题，旧代码能搬就搬，新代码直接堆起来。代码风格统一了，eslint过了，但是和系统架构比??起来，这些形式化的东西权重很低，重要性可以忽略不计。如果没有进化改进，熵会不断增加，系统必然会崩溃。这时候我们就要思考问题的本质原因是什么？是历史遗留问题，还是技术栈问题？不，想了想，还是人的问题，是开发者自己的问题。过度的自由必然导致混乱。React的设计理念和哲学思想很高，就是为了解决UI渲染的问题。深陷泥潭，无法捡起，挥之不去，终究会被反噬。屠龙少年终成龙！一个没有开发经验，不懂设计模式，框架概念不明确，看过几个API写项目的人，怎么驾驭得好？React可能连开发多年的老手都看不懂。但为什么上手这么难，难在哪里呢？按照api开发难吗？根本不对吧？为什么Vue技术栈没有这些问题呢？为什么性能问题这么少？优玉玺优达在设计框架的时候，目标用户是谁？框架帮我们解决了哪些问题？所以，本质原因是什么，这里很清楚，但对于“人”来说，却很难驾驭。我们不可能招聘到完全合格的开发人员。另一方面，人是很难进步的，成长曲线是一条很长的S曲线。那么有没有一种方案可以减少人为因素，防止人为侵蚀和破坏系统架构呢？我们来分析一下Vue全家桶的响应式设计模式针对各种解决方案。粒度非常细，依赖收集和依赖分发的逻辑全部由框架自动完成。开发者只需要关注业务逻辑，什么时候渲染，渲染频率控制框架会为我们处理。单文件模式，将js、css、html结合在一起，本身就是一种功能解耦。vuex是专门为vue框架设计的状态管理库，无缝对接。总体来说，开发体验还是很不错的，受众面非常广，尤其是对于初中级开发者来说，完全没有精神负担。由于框架为我们考虑了大部分功能，我们失去的是定制化的灵活性和扩展性。这或许是制约一把手出力的一个制约点。对于绝大多数开发者来说，还远远没有达到触发这个限制点的高度。关于vue技术栈相关的解释，这里就不做解释了。网上有很多分析资料。react(hook)+reduxReact本身只是一个构建用户界面的javascript库，官方是这么说的。它的核心两点是虚拟dom和非常高效的diff算法，这是它潜在的竞争优势。Vue后期迭代优化也有相关参考，比如virtualdom机制的介绍。全局状态管理早期正式推出Redux，纯函数式编程，通过中间件方式进行功能扩展。就在大家恼火的时候，使用redux需要大量的模板代码，使用起来非常繁琐；它还介绍了其他各种概念，例如连接高层组件、容器组件等概念；简而言之，使用起来很麻烦，样板代码也很大。也正是上面的缺点，所以在Hook推出后，大家庆祝一下，立马放弃了redux模式。那么hook还是需要很高的理解成本，甚至比Redux还要高。但是大家可能不假思索就开始按照API开发，导致所有函数的生成，里面积累了大量的状态和效果，函数体迅速膨胀。hook的状态设计分层就更乱了。道具传递令人困惑。平心而论，Redux和Hook本身都非常优秀。说出来你可能觉得你什么都懂了，但是实际操作起来，做出来的代码远远达不到标准。毕竟自己还是不懂相关技术的核心设计理念和自己要解决的问题，缺乏思考导致被虐。那么你是不是既想用React搭建UI，又想拥有Vue的开发经验呢？答案是肯定的，那就是React+mobxreact+mobx的核心理念：回归初衷，各自解决自己的问题，React专注于构建用户界面UI，mobx专注于数据逻辑管理，尘归尘，尘埃落定变成尘土。请参考使用方法，一看react+mobx不就是vue的繁琐版吗？还好，看起来是，但又不止于此。我们使用mobx设计数据存储和派生数据的变化和副作用操作，并使用React构建用户界面。最明显的一点是，mobx接管了React组件的渲染逻辑，将开发者从渲染问题中解脱出来，减轻了精神负担。数据逻辑内向到mobx中，自然实现了数据状态逻辑和UI的解耦；也方便单元测试。Mobx不同于Redux，但是可以有多个Store实例，非常灵活，也解决了数据props传递和组件通信的问题。采用这种模式开发，即使是没有经验的开发者随便开发，也不会对系统架构造成侵蚀和破坏。最佳实践到此为止，差不多该得出结论了。同样，没有灵丹妙药，没有神龙剑，没有放之四海而皆准的解决方案。如果你是一名开发新手，对各种设计模式和框架概念还没有深入了解，又想快速构建应用，那么Vue全家桶可能非常适合你入门。如果你有丰富的开发经验，做了大量的底层抽象封装工作，需要高度复用和定制一些能力，需要专业性，那么React技术栈可能更适合你，因为你很强。如果你喜欢使用React，但又想拥有Vue开发经验，那么React+mobx将非常适合你，你值得拥有。总结一下，这篇文章阅读量大，写的多，缺乏深度，尤其是后面很多技术细节，直接缺席；不过没关系，这篇文章不是讲解技术的使用，只是发牢骚，产生一些想法。关于深入使用技术的话题，以后有空再说吧！
