icestark
icestark copied to clipboard
ice-lab
:tiger: Micro Frontends solution for large application（面向大型应用的微前端解决方案），站点国内镜像：https://icestark.gitee.io
我们的应用是由十几个子应用构成的，在子应用之间难免会存在一些公共的业务模块，目前只是在每个子应用中都有一套相同的业务模块的代码，会造成以下问题，1代码冗余，重复加载浪费资源；2维护修改的时候需要多个地方多次修改。 所以基于以上情况，是否可以在ice子应用之间或者主应用与子应用之间共享组件。
## 业务背景 希望通过获取到模块的渲染完成的时机，计算模块的高度，优化下次加载时的体验。 ## 方案 [ReactDOM.render](https://reactjs.org/docs/react-dom.html#render) 第三个参数可获取模块渲染。由于容器无法主动获取到该状态（生命周期由模块指定），建议通过 `props.mountCallback` 来消费 callback 参数
## 背景 Core 中冗余与 React 框架有关的组件，`` 、``、`` 等。导致其他框架的用户需要从 lib 下引入： ```js import start from '@ice/stark/lib/start'; // ... ``` ## 方案 拆分相关逻辑进不同的 NPM 包： + @ice/stark - 框架无关 api + @ice/stark-react...
## 问题 子应用如果需要权限控制，一般会对 AppRoute 渲染进行劫持： ```js const AuthAppRoute = () => { ... if (hasPermission && !fetchingAuth) { return ; } else { return ; } } ``` 由于每个路由切换都需要请求权限，在请求过程中或者没有权限时，显示无权限。 上述处理在路由切换的时候将会卸载子应用，导致每次应用重新挂载从而重复加载资源，希望官方需要提供类似场景的指引或者相关实现
目前 [icestark 支持的入口规范](https://micro-frontends.ice.work/docs/guide/concept/child) 有四种，其中 url 是作为默认推荐给用户，目前看来存在以下问题： + 对开启 splitChunk 的用户不友好 开启此项能力，配置上需要多增加一些资源参数（并保证执行顺序），比如： ```js url: ['xxx/chunk.js', 'xxx/index.js', 'xxx/chucnk.css', 'xxx/index.css'] ``` 相比 entry 方式，配置难度加大。 + 对目前启用 Vite 模式的用户不友好 当前 vite 模式下，dev 和 prod...
目前，icestark 支持三种不同规范构建的微应用，分别是： + IIFE （指的是 webpack 直接 libraryTarget 配置为 var 的这种类型） + UMD + ES modules 目前，除官方脚手架会升级成 ES modules 加载方式，官网默认推荐 UMD 的包构建方式。是否考虑将 ES modules 作为 icestark 默认的子应用的包构建方式。 可预见的问题主要有： + 因为浏览器兼容性问题，直接使用...
# 背景 当开始 proxy 沙箱能力时，会造成 Memory Leaking（具体原因尚不清楚，但是其他 proxy 沙箱实现都由类似的问题）。但由于 icestark 的机制，会导致同一个应用多次加载存在多份实例，这是可以优化的点。 相关 issue #246 
