背景
- 新业务试点，需要快速搭建一个新应用，应用的页面是来源于应用A和应用B进行组合，其中应用A和应用B都是正常线上运行的应用，需要复用应用A和应用B中其中的一些页面，其中应用A、B分别来源于不同的团队维护；
挑战
针对新业务模式，方案上考虑采用比较成熟的微前端方案（qiankun），开发一个新portal，对应用进行整合，由于需要处理的应用分别来自于不同的团队维护，整个开发过程中也存在一些挑战：
- 登录态如何校验
- 页面访问权限校验
- 页面如何个性化修改
- 样式隔离问题
- 应用之间如何通信
问题解决
登录态如何校验
- 各子应用由自己的SOA进行校验，前端统一拦截接口调用，根据业务Code判断登录态是否有效；
- 如果登录态失效，调用主portal下发的logout函数，由主portal统一控制登录跳转的问题；
页面访问权限校验
当前应用是基于现有应用的组合，新应用只用到其中一部分的页面，当用户输入的url不在新应用的页面范围内，需要进行访问权限校验，解决方案如下：
- 页面权限统一收敛到应用菜单，菜单上配置路径path，前端获取路由里面的path去匹配菜单，规则是：全等或者路由path包含菜单path，视为正常访问，否则进入无权限页；
- 对于某些特殊页面，没有菜单的情况，也可以通过配置白名单的形式，让用户可以访问；
页面个性化修改
由于当前是一个新业务应用，基于线上应用进行组合，难免有一些个性化需求，同时又不能影响原来的线上业务；基于此，我们考虑从portal下发业务标识给子应用，子应用根据业务标识去区分新业务或原有业务；
- 主程序下发业务标识
- 子应用接收业务标识
样式隔离
样式隔离是一个比较大的挑战，这块主要集中在UI组件库上。主portal用的经过二次封装的elementUI，子应用虽然也是用的elementUI，但是版本差异很大，在同一个应用里面运行冲突比较大，这块考虑修改各个应用中elementUI的前缀来解决
- 安装两个依赖：change-prefix-loader、postcss-change-css-prefix
- vue.config.js配置loader
- 配置postcss.config.js
应用通信
- 主应用与子应用通信
portal将子应用需要的数据，通过props下发下去，子应用在入口文件main.ts中进行获取，这中方式具有一定的局限性，子应用只会在刚启动的时候获取到，后续props数据更新，子应用是获取不到的
- 子应用与主应用通信：这块主要是回调props下发的函数进行回调处理，如上图中的logout、routerPathChange、locationHrefChange函数，子应用回调这些函数，主程序统一做业务处理；
- 子应用与子应用通信：这块本次业务暂时未涉及到，可以利用qiankun的Actions通信，qiankun 内部提供了 initGlobalState 方法用于注册 MicroAppStateActions 实例用于通信，该实例有三个方法，分别是：
- setGlobalState：设置 globalState。设置新的值时，内部将执行浅检查，如果检查到 globalState 发生改变则触发通知，通知到所有的观察者函数。
- onGlobalStateChange：注册观察者函数。响应 globalState 变化，在 globalState 发生改变时触发该观察者函数。
- offGlobalStateChange：取消观察者函数。该实例不再响应 globalState 变化。
最后
整个开发过程，遇到不少问题，好在也都一一得到了解决，也有一些问题是需要长期进行的，比如页面风格的问题，毕竟来自多个的团队，风格的统一，需要长期进行解决。
