微前端随笔

✨ single-spa：

1. js-entry
   通过es-module 或 umd 动态插入 js 脚本 ，在主应用中发送请求，来获取子应用的包，
   该子应用的包

   singleSpa.registerApplication({name: 'app1',app: () => import('http://localhost:8080/app1.js'),activeWhen: '/app1'
   });
   

   主应用直接执行 app: () => import('http://localhost:8080/app1.js')该脚本，拿到子应用包。该包中暴露了主应用规定的那几个生命周期函数，

🎨 qiankun：

1. html-entry

qiankun 库的核心插件

import-html-entry 是 qiankun 实现 ​HTML Entry 模式的关键工具，具体功能包括：

• ​请求并解析 HTML 文件
  从 HTML 中提取所有 <script> 和 <link> 标签的资源路径（包括外链和内联脚本）。
• 资源分类与处理
  将资源分为 ​JS、CSS 和 ​入口脚本，并处理资源路径（如相对路径转绝对路径）。
• 生成加载队列
  根据资源类型和依赖关系生成加载队列，确保资源按正确顺序加载。
• 执行入口脚本并获取生命周期
  import-html-entry 通过劫持全局变量或模块系统，获取子应用导出的生命周期方法。
• 执行环境隔离
  提供沙箱机制（如 Proxy），隔离子应用的 JS 执行环境。
  

---

2. js沙箱

防止js全局污染
当在主应用环境中，开始加载子应用的 JS 文件（或内联脚本）时
qiankun 会通过 es6 Proxy 为该子应用创建一个 代理的window，

	// 创建一个虚拟的全局对象const fakeWindow = {};// 保存子应用对全局变量的修改this.modifiedProps = new Map();// 代理 window 对象
this.proxy = new Proxy(fakeWindow, {get: (target, prop) => {// 优先从子应用的修改中读取，否则从真实的 window 读取return this.modifiedProps.has(prop) ? this.modifiedProps.get(prop): window[prop];},set: (target, prop, value) => {// 所有对 window 的修改记录到 modifiedProps，不影响真实 windowthis.modifiedProps.set(prop, value);return true;},

• ​读操作：子应用读取 window.xxx 时，优先从 modifiedProps 中获取子应用自己修改的值；若未修改，则从真实 window 读取。
• ​写操作：子应用修改 window.xxx 时，值被记录到 modifiedProps，不会影响真实 window。

---

3. 样式隔离

1. ​ 严格样式隔离（Shadow DOM）：==​创建一个封闭的 DOM 树，外部样式无法影响内部，内部样式也不会泄漏到外部。
   • 配置方式：

   start({sandbox: {strictStyleIsolation: true, // 启用 Shadow DOM},
   })
   

   什么是Shadow DOM？是 Web Components 技术中的一部分
   传统 DOM 是全局可见的，而 Shadow DOM 允许在组件内部创建一个私有的 DOM 子树，独立于主文档树。外部样式和脚本无法直接访问 Shadow DOM 内部的内容。

通过 element.attachShadow({ mode }) 方法创建：

const host = document.createElement('div');// mode 可选 'open' 或 'closed'
// 是否允许外部通过 host.shadowRoot 访问 Shadow DOM。
const shadow = host.attachShadow({ mode: 'open' }); 
shadow.innerHTML = `<style>button { background: black; }</style><button>Shadow DOM 按钮</button>
`;
// 添加到页面后，按钮的样式不会受外部 CSS 影响

• 优点：完全隔离，最严格的样式保护。
• ​缺点：
  兼容性问题（部分旧浏览器不支持）。
  子应用需适配 Shadow DOM 环境（如事件冒泡路径变化）

2. 动态样式隔离（Scoped CSS）
   为子应用的 CSS 选择器添加唯一前缀，限制其作用域。

   • 配置方式：

   start({sandbox: {experimentalStyleIsolation: true, // 启用动态作用域},
   })
   

   原理：
   子应用的根容器会被自动添加唯一属性（如 data-qiankun=“childApp”）：

   <div data-qiankun="childApp"><!-- 子应用 DOM --><button class="button">Submit</button>
   </div>
   

   子应用的所有 CSS选择器（如 .button）添加上具有唯一属性：

   .button { background: red; }/* 重写后 */
   [data-qiankun="childApp"] .button { background: red; }
   

• 优点：无需破坏子应用原有逻辑，兼容性好。
• ​缺点：
  无法处理全局样式（如 body 或 html 的样式）。
  CSS-in-JS 或动态生成的样式可能需要额外处理。

如果子应用使用了 CSS-in-JS、内联样式或第三方 UI 库，可以结合以下方式彻底避免冲突：

1. 子应用使用 CSS Modules 自动生成唯一的类名：

// 子应用组件
import styles from './App.module.css';function App() {return <div className={styles.title}>Child App</div>;
}

2. ​CSS-in-JS
   通过 Styled-components 或 Emotion 生成作用域样式：

const Title = styled.div`color: red;
`;
// 生成唯一的 class 名称（如 .css-1x2y3）

3. ​UI 库前缀
   修改第三方 UI 库的类名前缀（如 Ant Design）：

   // 子应用中修改 less 变量
   @ant-prefix: 'custom-prefix';
   

---

4. 路由（基于single-spa）

single-spa 对原生浏览器路由 做了以下事情；

1. 监听的路由事件： hashchange 和 popstate

   hashchange 和 popstate 是唯一原生支持无刷新路由的事件​​。
   单页应用（SPA）和微前端架构中的路由切换 依靠这两个api

   具体来说，监听这两个事件有以下几个关键目的：

   • 拦截路由变化 ：
     当用户在浏览器中导航（如点击前进/后退按钮、修改 URL hash、或通过 History API 进行导航）时，single-spa 需要知道这些变化，以便决定哪些微前端应用需要被加载、挂载或卸载。
   • 控制事件触发顺序 ：
     通过捕获这些事件的监听器，single-spa 可以确保在完成应用的挂载/卸载操作后，才将这些事件传递给各个微前端应用，避免应用在不适当的时机接收到路由事件。
   • 协调多个应用 ：
     当路由变化时，可能需要卸载一些应用并挂载其他应用。通过监听这些事件，single-spa 可以协调这个过程，确保应用之间的平滑切换。
   • 统一的路由处理机制 ：
     无论是 hash 路由还是 history 路由，single-spa 都能通过监听这两个事件来处理，为不同类型的路由提供统一的处理机制。

2. 修补 History API
   具体来说，修补 History API 有以下几个关键目的：

   • 修补 pushState 或 replaceState 方法
     这两个方法修改了URL，默认不触发 popstate，通过修补这些方法，single-spa 可以在它们被调用后手动触发一个人工的 popstate 事件，确保所有应用都能感知到路由变化。

总的来说

• 完善原生 URL的路由响应机制
• 协调 子应用在不同URL间的挂载卸载

---

5. publicPath

静态文件在浏览器中​​被请求时的基础 URL 路径​​。
eg：

module.exports = {output: {filename: 'bundle.js',path: path.resolve(__dirname, 'dist'), // 与服务器无关，仅决定本地输出位置。publicPath: '/assets/', // 浏览器访问路径 需在前面加上 /assets},
};

若部署在服务器根目录，访问资源时会请求：http://xxx.com/assets/bundle.js。

---

在微应用中：
当子应用被主应用加载时，其资源路径可能相对于主应用的 URL，而非子应用的真实部署路径。

• 示例​​：子应用部署在 http://child.com/sub-app/，但主应用在 http://main.com/ 加载子应用，此时子应用的 JS/CSS 可能错误地从 http://main.com/js/app.js 加载（404 错误）。

通过配置 publicPath，子应用可以区分当前是独立运行还是被主应用加载，动态修正资源路径。

---

⚠️ 且需要与子应用路由配置的协同：

问题场景​​：
如果子应用不配置路由的 basename（基础路径），当主应用通过 /sub-app 加载子应用时,
子应用的路由会直接拼接在 请求地址的根路径（/）下，导致路径匹配丢失。例如：

• 主应用匹配子应用路径：http://main.com/sub-app
• 子应用内部路由：/user/list
• 访问子应用实际路径​​：http://main.com/user/list（错误，跳出了主应用的上下文）
• ​​预期路径​​：http://main.com/sub-app/user/list（正确）

总结：为什么必须协同？​​
​​静态资源路径​​（publicPath）和 ​​路由路径​​（basename）共同决定了子应用的完整上下文：

• publicPath 解决​​资源从哪里加载​​。
• basename 解决​​路由在哪里生效​​。

两者缺一不可，否则会导致：

• 资源加载成功，但页面渲染错位。
• 路由跳转正确，但资源加载失败。