【译文】【前端架构鉴赏 01】:Angular 架构模式与最佳实践
我猜此时此刻你心里的疑问一定是:为什么是 Angular,不是 React,不是 Vue,不是 Flux,不是 Redux ? 因为你已经对它们太熟悉了。我个人作为开发者而言最希望是能够汲取到“圈外”的“营养”,这样才能给我的成长带来帮助。我想对各位也是一样。
A collection of 79 posts
我猜此时此刻你心里的疑问一定是:为什么是 Angular,不是 React,不是 Vue,不是 Flux,不是 Redux ? 因为你已经对它们太熟悉了。我个人作为开发者而言最希望是能够汲取到“圈外”的“营养”,这样才能给我的成长带来帮助。我想对各位也是一样。
如果你对整洁架构(Clean Architecture)有所了解的话,回想一下我们前几篇中描述的内容,你会发现整洁架构对前端,对 MVP 来说也是同样适用的。
在 Flux 架构中,有两个问题依然没有被提到,一个是表现层模型,另一个是测试
MVC 的不足
在上一篇中,我提出了一个应用中常见的问题:如何在多个视图中共享同一份数据,并且保证它的改动能够同步到不同的视图中去?
我把 MVC 框架作为我们理解架构的切入点。虽然它现在已经式弱了,但在我看来它非常重要并且起到了承上启下的作用:作为经典的解决方案第一次系统的把应用的从复杂的混沌中解救了出来。从这套方法论中我们能学习到很多至今能受用的思路,同时我们也能了解到它的不足。
在这个系列里面,我会谈到前端架构的进化;它们解决了什么样的问题以及又是如何面临新的无法解决的问题的;最后这些架构背后常见的组件和模式。
这原本不是一篇文章,是一封对内的邮件。在我们的项目里有一个传统:如果你发现了任何对他人有帮助的事情,不仅于技术上,可以通过邮件的形式告诉大家,邮件上需要加上 tag: #Aha moment#
互联网公司技术选型三定律 流行即正义 新鲜即正义 复杂即正义 —— 我
随着前端代码需要处理的业务越来越繁重,我们不得不面临的一个问题是前端的代码体积也变得越来越庞大。这造成无论是在调式还是在上线时都需要花长时间等待编译完成,并且用户也不得不花额外的时间和带宽下载更大体积的脚本文件。