helo，大家好，我是peryl。今天给大家介绍一下个人自研的微前端框架：plain-micro-application；目前还处于一个demo的状态，还没想好文档该怎么写，怎么快速让开发者搭建一个微前端工程，可能还得弄一个脚手架来辅助实现。大家可以先了解一下功能特性；
- 强烈建议一边看视频一边了解具体的细节：www.bilibili.com/video/BV14q…
- 线上示例地址：martsforever-demo.gitee.io/template-pl…
- 账号密码：admin / 888888
- 一级菜单“子应用”下的所有二级菜单都是通过加载子应用实现的内嵌页面；
功能特性
目前该微前端框架与目前已知的微前端框架大不相同，比如 SingleSpa，qiankun.js等等。以下是主要的功能特性：
- 自带有多页签形式的约定式页面路由，能够自动管理实现页面实例缓存销毁；支持子应用使用传统的history路由或者hash路由；
- 多个微前端应用独立开发，独立部署。子应用"可以"通过加载主应用实现本地开发调试，在不安装任何依赖的情况下使用主应用的能力，比如登陆、主菜单页面等等；
- 零耦合；子应用可以将所有运行时所需要的依赖放在主应用中，子只需要有主应用的访问地址就可以实现使用基础的依赖（Vue，React，ReactDOM）以及基础的功能（登陆，首页，主菜单页面）；
- 易维护；主应用只需要配置子应用的地址，子应用只需要配置主应用的地址，而不需要过多的配置就可以实现互相加载调用；
- 支持目前流行的构建工具Webpack以及Vite；无论是Webpack还是Vite，无论是本地调试还是打包部署，都拥有完美的开发体验；基于JSP、Jquery等没有使用构建工具的老项目也可以实现通过iframe加载子应用，并且不会有iframe被销毁的问题；
- 支持任意技术栈；子应用可以是Vue、React、Angular或者其他任何前端技术栈；
- 快速编译以及打包；主应用只有登陆页面、主菜单首页以及子应用所需要的公共依赖，主应用会通过静态文件的方式管理这些公共依赖，所以主应用的编译调试以及打包事件不会很长，子应用取决于页面个数以及构建工具。
- 零成本接入新技术；子应用可以使用任意的新技术，不会影响整体系统的加载速度，编译时长，代码结构等等。
- 零成本接入老项目；基于Webpack以及Vite的现有项目只需要少数配置就可以接入微前端系统。对于比较老的工程可以通过iframe接入，而不需要做任何更改；
详细说明
一、多页签形式的约定式页面路由
- 在系统中，页面的路由信息会以一个二维数组的形式保存在localStorage中，所以重新打开页面以及刷新页面的时候，不论当前url是何值，都会打开上一次最后访问的页面；
- 约定式路由，页面的跳转路径以页面的文件路径为准；每个子应用都会有一个自己的页面路径前缀；
- 能够自动管理页面实例初始化以及销毁，当页面切换的时候，甚至是DOM节点也是不会销毁的，仅仅是使用
display:none隐藏；比如当从列表页面跳转到详情页面的时候，此时列表页面的滚动高度、筛选参数等登都会自动保留，无需额外的干预； - 在这种路由模式下，也支持子应用为history路由或者hash路由，关于这一点请看视频说明；
- 多页签形式下，history路由或者hash路由在实现页面返回的时候，也会有一些问题，请看视频说明；
二、独立开发 独立部署
- 子应用在本地调试的时候，可以通过加载远程主应用部署地址来使用主应用的功能（登陆，主菜单），不需要额外的依赖耦合；
- 主应用可以运行时添加、覆盖以及移除子应用；
- 即使远程应用没有设置跨域，本地调试的时候也可以通过代理的方式实现加载远程应用；
三、应用之间零耦合
- 子应用本身可以将所有的运行时依赖放在主应用中，比如基础的Vue、React、ReactDOM等等；本地调试的时候可以不安装这些依赖，如果是基于typescript开发，那么只需要安装对应的类型声明即可；再也不需要关注版本不同以及统一依赖升级的问题；
- 主应用只需要知道子应用的访问地址，子应用也是只需要知道主应用的访问地址。除此之外不需要额外的代码或者包依赖；
- 方便实现代码权限控制，比如负责商品模块的前端开发者只需要分配商品模块子应用工程权限即可，不需要分配其他子应用以及主应用工程权限；
- 多个子应用之间联调也是简单；
四、易维护
- 应用直接只需要知道对方的地址就可以实现互相访问，不需要通过npm包的方式管理；
- 主应用在部署的时候，设置了跨域的话，那么子应用可以零配置实现本地加载远程主应用启动调试；如果远程主应用不支持跨域，那么也可以通过设置本地代理的方式实现跨域；
五、支持任意构建工具以及无构建工具的项目
- 支持子应用为Webpack；
- 支持子应用为Vite，拥有完美开发体验，调试以及打包模式下无区别；
- 如果子应用为不使用构建工具的老项目，也可以通过iframe嵌入；并且不会有iframe频繁销毁的问题；
六、支持任意技术栈
- 这个没什么好说的；
七、快速编译以及打包
- 主应用通过静态文件的方式管理子应用公共依赖，而且主应用没有太多的页面，所以打包时间不会很长；
- 子应用取决于页面的个数，如果是基于vite的话，即使是上百来个页面，打包也是巨快无比；
八、零成本接入新技术
- 创建一个子应用的成本很低，少量配置即可实现；
- 子应用可以使用任意的技术栈，以及任何依赖包，不会影响主应用的加载以及编译构建性能；即使子应用依赖体积比较大的插件，那么也是访问到子应用的具体页面的时候才会有等待时长；
九、零成本接入老项目
对于Webpack、Vite类型的项目，只需要少量配置就可以实现接入微前端系统，如果是实在不想对老项目做任何改动，那么也可以通过iframe的方式加载；
问题
没有js沙箱以及css隔离
因为页面切换的时候不会销毁dom也不一定会销毁页面，为了确保页面运行正常，所以这里并没有做js沙箱以及css隔离；
在整合history或者hash类型的子应用的时候有一些问题
- 不支持浏览器的前进后退实现页面前进后退；
- 有时候页面切换比较快的时候有一些显示问题；
相关仓库地址
base应用(base+main)
- vuecli + react + plain-design-composition + plain-design
- gitee.com/martsforeve…
Vue 子应用
- vuecli + vue3 + tab router
- gitee.com/martsforeve…
React 子应用
- vuecli + react + tab router
- gitee.com/martsforeve…
Vue vite子应用
- vite + vue3 + tab router
- gitee.com/martsforeve…
React Vite子应用
- vite + react + tab router
- gitee.com/martsforeve…
Vue Router子应用
- vuecli + vue3 + vue-router
- gitee.com/martsforeve…
React Router子应用
- create-react-app + react + react-router
- gitee.com/martsforeve…
Umi子应用
- umi + react + react-router + iframe
- gitee.com/martsforeve…
目前umi应用只能通过iframe的方式接入，因为要改umi的入口还得写umi插件，目前暂时没有时间以及精力做这个事情；
Main主应用
模式
三种微前端模式：
应用类型：
- Base应用：存放公共的静态资源，登陆页面，页面加载、切换逻辑等等；
- Main主应用：定义有哪些子应用，定义登陆页面以及主菜单首页内容；
- 子应用：具体的页面实现；
模式：
- 第一种模式：适用于项目初期开发，这时候页面不多，技术栈唯一；这时候只需要一个工程就可以实现所有的功能；
- 第二种模式：就是文章中一直在讲解的模式，只有一个主应用（其实这个主应用包含了Base应用），在加载页面的时候，通过加载子应用来渲染具体页面逻辑；这种模式是却别与第三种模式来说的。
- 第三种模式：有多个主应用，比如目前项目产品有多个系统，比如示例图中有两个系统ERP以及CRM；这两个系统会用到一些公共的子应用（子应用2），其他还有一些自己独有的子应用；然后系统初始化的时候先加载Base应用，然后初始化登陆页面以及主菜单页面，最后渲染具体页面的时候通过加载子应用来实现；