Redux 的困扰与如何技术选型

文章的名字我想了很久,备选项有“我再不推荐 Redux”,“Redux 为什么令我头疼”,“Redux 进化启示录”等等。通过这一系列名字我想你大概能猜到我接下来想聊的问题是什么,但这个问题放眼望去不是 Redux 独有,而是在做技术决策时经常会遇到的,即使对于非前端背景的开发者也同样成立。最后决定用一个带有开放式标题也许能够引起更多的共鸣。
A collection of 67 posts
文章的名字我想了很久,备选项有“我再不推荐 Redux”,“Redux 为什么令我头疼”,“Redux 进化启示录”等等。通过这一系列名字我想你大概能猜到我接下来想聊的问题是什么,但这个问题放眼望去不是 Redux 独有,而是在做技术决策时经常会遇到的,即使对于非前端背景的开发者也同样成立。最后决定用一个带有开放式标题也许能够引起更多的共鸣。
正在阅读这篇文章的你,或多或者接触过前端性能优化,这样的接触可能是来自你的阅读体验也可能是来自工作经验。那我们不妨从一个非常简单的思想实验开始,请你借助你对这个领域的理解,来回答下面的几个问题:
编程框架日新月异,工具平台推陈出新。但有意思的是,代码的坏味道不会因为你使用工具的时髦而自行消散,团队成员的编程水平也不会随着工具的进化而水涨船高。
随着应用程序的日趋庞大,它变得越来越难以维护。随着可复用模块的重要性逐渐递增应用的复杂性也随之增长。我们都意识到我们应该在它面临难以维护的风险之前做些什么
这篇文章或许看上去仅和 Angular2 开发者相关,但我相信它也适用于其它的框架。这只是一份关于编写具有可拓展性和可维护性单页面应用的指南。需要指出的非常重要的是,这并不是达成目标的唯一方式,但是对我个人而言它们在不少的场景中都行之有效
我猜此时此刻你心里的疑问一定是:为什么是 Angular,不是 React,不是 Vue,不是 Flux,不是 Redux ? 因为你已经对它们太熟悉了。我个人作为开发者而言最希望是能够汲取到“圈外”的“营养”,这样才能给我的成长带来帮助。我想对各位也是一样。
如果你对整洁架构(Clean Architecture)有所了解的话,回想一下我们前几篇中描述的内容,你会发现整洁架构对前端,对 MVP 来说也是同样适用的。
在 Flux 架构中,有两个问题依然没有被提到,一个是表现层模型,另一个是测试
MVC 的不足
在上一篇中,我提出了一个应用中常见的问题:如何在多个视图中共享同一份数据,并且保证它的改动能够同步到不同的视图中去?