简论微前端的意义与发展

简论微前端的意义与发展
PS:以下言论部分整理于网友

先说一下为什么需要微前端

我抛出两个场景,大家思考一下:

1.新入职一家公司,老板给你一个5年,甚至于10年的老项目,需要你在这个项目上加入其他功能

2.你们起了一个新项目,老板只给了一个要求,要这个项目的架构在3年甚至于5年后依旧保持活力,不论为遗产项目

第一个场景我们初步一想,可以啊,我只需要把新功能用 react/vue 开发,反正他们都只是 ui library,给我一个dom 节点我想怎么渲染怎么渲染。但是你有没有考虑过这只是浮在表层的视图实现,沉在底下的工程设施呢?我要怎么把这个用 react 写的组件打出一个包,并且集成到原来的用 es5 写的代码里面?或者我怎么让 webpack 跟 之前的 grunt 能和谐共存一起友好的产出一个符合预期的 bundle?

第二个场景就不用想了,react15和react16都不兼容,你怎么保证一个项目几年之后还能充满着活力?

这两个例子,很典型,另外值得一说的是,目前为为前端发声的公司,都是像银行这种需要一直维护单个项目的公司,他们的业务越到后期越复杂,越到后期越需要兼顾,系统改版一次是很痛苦的,像一些中小型企业,这样的改版是致命的,这里就抛出了一个问题,如何确保我的遗产代码能平滑的迁移,以及如何确保我在若干年后还能用上时下热门的技术栈?

引入微前端

为了解决上面所提到的问题,我们引入了一个新的概念,微前端,至于什么是微前端,下面我会详细介绍

**首先我们需要在主系统构造一个足够轻量的基座,然后让各部分子系统按照一定的协议和规则去运行,去执行,当然了还有一点就是系统和系统 之间还需要通信
**

**我们提出的这些问题基本iframe都能解决,从宏观来讲的话,它确实是一个完美的方案
**

iframe 最大的特性就是提供了浏览器原生的硬隔离方案,不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破,导致应用间上下文无法被共享,随之带来的开发体验、产品体验的问题。

  1. url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
  2. UI 不同步,DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框,同时我们要求这个弹框要浏览器居中显示,还要浏览器 resize 时自动居中..
  3. 全局上下文完全隔离,内存变量不共享。iframe 内外系统的通信、数据同步等需求,主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
  4. 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

其中有的问题比较好解决(问题1),有的问题我们可以睁一只眼闭一只眼(问题4),但有的问题我们则很难解决(问题3)甚至无法解决(问题2),而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题, 最终导致我们舍弃了 iframe 方案。(以上出自乾坤文档Why not Iframe

接下来我们知道了,我们要做一个不是iframe的iframe出来

与技术栈无关才是微前端的初衷

微前端首先解决的是如何解决一个巨石应用,从而解决巨石应用随着技术更迭、产品升级、人员流动带来的工程上的问题。解构之后还需要再重组,重组的过程中我们就会碰到各种 隔离性、依赖去重、通信、应用编排 等问题。
那么微前端的基本概念就可以推演出来

  • 技术无关
  • 隔离团队代码
  • 建立各团队的前缀
  • 本地浏览器特性优先于自定义 API
  • 构建自适应网站

微前端方案正确的架构姿势

既然技术栈无关是微前端的核心,那么任何违背这一原则的做法都应该被摒弃。

比如我们不能要求子应用或者主应用必须要使用某一框架,某种方式,或者是某一版本

web-component

在不少关于微前端的帖子下都能看到网友对web-component的呼声很高

我个人认为这确实比较好的微前端方案,但它也有缺点:

  1. 兼容问题,倒不是 ie 的兼容,而是国产浏览器很多都阉割掉了 shadow dom
  2. 隔离太硬,穿透是世纪难题

上面两点,其实都不是很要紧的问题,兼容问题可以降级(polyfill),而且现在穿透隔离的方式也越来越多

与此而来的是 web component 很多优势,最主要的是它提供了一层 runtime,自带生命周期和双向绑定,可以更方便地做各种操作

最后总结一下:

做到代码的时代和次元隔离并且拥有良好的用户体验,是微前端的核心:随着时间的推移,团队人员的流动,会慢慢发现一些事情:比如原维护团队以react 16.9的视角看 react15.6的世界,就像在看原始人用原始的姿势拉着原始的屎,又或者新人进来以vue看react,鸡同鸭讲理念不同。 微前端的理想状态也许就是用最爽的姿势写最新的业务模块吧