也许这就是你想要的微前端解决方案

前言微前端是当下的前端热词，稍微大一点的团队会做技术探索，作为一个不甘落后的团队，我们也在做。可能你见过Single-Spa、qiankun等业界成熟的解决方案，非常强大：JS沙箱隔离、多栈支持、子应用并行、子应用嵌套，但仔细想想，是不是真的适合你吗？对我来说，它太沉重，概念太多，难以理解。先说说背景吧。我们之所以要对我们的小贷管理后台进行微前端改造，主要是基于以下需求：系统从接手时的30多页，到后来发展到150多页一年多。页面，并且还在增长；项目体积变大，带来开发体验差，打包构建速度很慢（初始构建，1分钟多）；小贷系统的开发占整个web组50%的人力，每个Iterations都有两三个需求在这个系统上开发，代码合并冲突，上线时间穿越。带来的是开发过程管理的复杂性；业务人员被分类，没有人会使用所有的功能，每个业务人员只有30%甚至更少的功能。但是你必须加载所有的业务代码才能看到你想要的页面；所以，不像市面上很多前端团队为了引入微前端，我们是在拆，更多的团队在联合。所以这个方案适合和我一样目的的前端团队。将自身维护的巨婴系统打散，再通过微前端“框架”进行聚合，降低项目管理难度，提升开发体验和业务体验。聚影系统技术栈：Dva+Antd方案参考了美团的一篇文章：微前端在美团外卖中的实践。在做这个项目的按需预加载设计时，深入到webpack构建的项目代码运行逻辑。还有更多收获：webpack打包后的代码如何在浏览器中运行？，不懂的可以看方案设计。基于业务角色，我们将巨婴系统拆分为一个基础系统和四个子系统（子系统可根据需要扩展），如下图所示：除了提供基础功能外，即系统登录、权限采集、子系统加载、公共组件共享、公共库共享，还提供了一个基本所有业务人员都会用到的业务功能：用户授权（guan）信（li）。子系统以静态资源的形式提供注册函数，函数的返回值是一个Switch-wrapped组件和子系统的所有模型。布线设计子系统以组件的形式加载到基础系统中，因此布线是整个设计的入口和第一步。为了区分基础系统页面和子系统页面，在路由上约定如下形式：//子系统路由匹配，伪代码functionLayout(layoutProps){useEffect(()=>{constapps=getIncludeSubAppMap();//加载按需分项；apps.forEach(subKey=>startAsyncSubapp(subKey));},[]);return({/*企业用户管理*/>{/*...省略一百行*/>}即只要以subPage路径开头，默认路由对应的组件是子项目，所以子项目组件是通过AsyncComponent组件异步获取的。异步加载组件设计路由设计完成，接下来异步加载组件是本方案的灵魂，流程如下：通过路由，匹配要访问的子项；通过子项id，获取对应的manifest.json文件；通过获取manifest.json，识别对应的静态资源（js、css），加载静态资源。加载完成后，子工程执行注册，动态加载模型。更新子项目组件，直接上传代码。简单明了，后面是资源加载的逻辑，具体需要注意model和component的加载顺序：exportdefaultfunctionAsyncComponent({location}){//子项目资源是否加载const[ayncLoading,setAyncLoaded]=useState(true);//加载和访问子项目组件const[ayncComponent,setAyncComponent]=useState(null);const{pathname}=location;//获取路径中标识子项目前缀的部分，如'/subPage/xxx/home'其中xxx为子系统路由标识constid=pathname.split('/')[2];useEffect(()=>{if(!subAppMapInfo[id]){//这个子系统不存在，直接跳转到首页goBackToIndex();}conststatus=subAppRegisterStatus[id];if(status!=='finish'){//加载子项loadAsyncSubapp(id).then(({routes,models})=>{loadModule(id,models);setAyncComponent(routes);setAyncLoaded(false);//已经loaded,makeamarksubAppRegisterStatus[id]='finish';}).catch((error={})=>{//如果加载失败，显示错误信息setAyncLoaded(false);setAyncComponent({error.message||'加载失败'}