微前端不知道什么时候开始变得非常火,结合后台的微服务,可以把一个系统切分为一个个子模块。比如用户模块、权限模块、订单模块等,每一个模块可以单独开发、测试、部署,每个模块还可以使用不同的技术,最后通过主应用加载这些模块。
其实这样看起来,微前端有点类似ifram,或者直接一个超链接跳转就可以实现。确实,微前端类似这样的场景。但是一些场景下用户体验很差,比如每个应用的路由无法记录,应用之间的通信也不方便。
微前端每个模块都是一个子应用,主应用和子应用完全解耦,一个庞大的项目只是修改某一个很小的bug的时候,就不需要整改项目重新打包部署,只需要把项目拆分一个个子应用,然后修改打包部署子应用,主应用运行时动态加载,中间通过协议接入,子应用打包的时候通过导出方法供主应用调用去通信、加载。
早期的微前端解决方案是Single-SPA,核心是实现了路由劫持和应用加载,但是内部的样式和js没有做到隔离,出现冲突。而基于Single-SPA的qiankun,应该是目前落地微前端的主要选择,解决了Single-SPA的痛点。类似的还有Piral、Luigi等。Qiankun开箱即用,非常简单的实现了微前端。
如果使用Single-SPA,比如vue可以使用single-spa-vue,react可以使用single-spa-react。内部已经帮我们实现服务注册、事件监听、子父组件通信等功能,最后打包出一个个lib子应用类库供主应用加载。如果使用qiankun,直接自己暴露三个方法就可以。
目前已经越来越多企业开始使用微前端,但是使用微前端也是要结合项目衡量。当以前遗留下的项目技术栈不同、项目庞大,希望每个模块可以独立开发独立部署、有一些老项目很稳定了,不希望进行重构等,反正是要根据实际情况去分析是否利大于弊,才去选择落地微前端。