序言

长久以来，在前端各领域的开发者们总是简单地认为：“前端就是视图层”。

这样的认知对于现今承担起越来越多责任的前端域架构无疑是一种谬误。React的出现无疑将以往的前端开发方式降维打击 ， 在web开发提出了“视图是数据状态的衍生结果，即view = react(state)”这样先进而兼具前瞻性的伟大理论和实现。

然而随着react和其他视图库的发展与完善，事情似乎走向了偏离关于软件工程“理想”的架构。有着相当一部分不关心（不擅长）架构的工程师将视图库奉为圭臬，或将所有业务逻辑不加思考地耦合进组件、或认为hooks是银弹并将状态和生命周期一股脑地封装为react-hooks还自觉优秀。

事实上我并非否定react hooks，而是说几乎没有人以“合理”的方式使用它。hooks无疑解决了函数组件无法复用状态与生命周期逻辑，函数组件无法存留过往数据等问题。那么官方是否提供了架构良好的哲学理念来指导工程师们使用呢？我想答案是否定的，我所见的是react团队在hooks上越走越“黑”。

举一个例子也许你就能感同身受：某一天你学会了一个很好用的物理公式，你拿着它做出了许多题型，你觉得这就是最完美的公式。随着你做了越来越多的题目，这个公式已经不适用于大部分的题目了，但若固执使用依然能够通过复杂推导得出答案。很少人会去站在下一个维度去思考问题：题目到底想考什么？曾经合适的东西在更加复杂的需求面前还合适吗？

在我所见之处很少有人从架构的角度去思考一个新技术的诞生到底解决了什么核心问题？代价是什么？这些代价值得吗？可接受吗？

我构建每一个前端系统时、接触每一个技术时，都会反复斟酌这些问题，也许市面上流行的方案能够解决问题，却不是适合解决当前问题的最佳实践。