前端微前端架构：大型项目的优势与风险

问题：

• 所有代码都在一个代码库中，随着功能增加，代码量会变得非常庞大
• 团队协作困难，容易出现代码冲突
• 部署风险高，任何一个小改动都需要整个应用一起发布
• 技术栈单一，无法根据不同模块的需求选择最合适的技术

正确的做法

使用 Single-SPA 实现微前端

// 主应用配置
import { registerApplication, start } from 'single-spa';

// 注册微前端应用
registerApplication({
  name: 'header',
  app: () => import('@org/header'),
  activeWhen: (location) => true,
});

registerApplication({
  name: 'dashboard',
  app: () => import('@org/dashboard'),
  activeWhen: (location) => location.pathname === '/dashboard',
});

registerApplication({
  name: 'settings',
  app: () => import('@org/settings'),
  activeWhen: (location) => location.pathname === '/settings',
});

registerApplication({
  name: 'user-profile',
  app: () => import('@org/user-profile'),
  activeWhen: (location) => location.pathname === '/user-profile',
});

// 启动应用
start();

微前端应用示例

// dashboard 微前端
import React from 'react';
import ReactDOM from 'react-dom';
import singleSpaReact from 'single-spa-react';

function Dashboard() {
  return (
    <div className="dashboard">
      <h1>Dashboard</h1>
      <p>Welcome to your dashboard!</p>
    </div>
  );
}

const reactLifecycles = singleSpaReact({
  React,
  ReactDOM,
  rootComponent: Dashboard,
  errorBoundary(err, info, props) {
    return <div>An error occurred: {err.message}</div>;
  },
});

export const bootstrap = reactLifecycles.bootstrap;
export const mount = reactLifecycles.mount;
export const unmount = reactLifecycles.unmount;

样式隔离

/* 使用 CSS Modules 或 Shadow DOM 进行样式隔离 */
.dashboard {
  /* 样式只会应用到当前微前端 */
  background-color: #f5f5f5;
  padding: 20px;
}

通信机制

// 使用自定义事件进行微前端间通信
// 发送消息
function sendMessage(message) {
  window.dispatchEvent(new CustomEvent('micro-frontend-message', { detail: message }));
}

// 接收消息
window.addEventListener('micro-frontend-message', (event) => {
  const message = event.detail;
  console.log('Received message:', message);
});

毒舌点评

微前端确实能解决大型应用的一些问题，但它并不是银弹。如果你只是为了赶时髦而使用微前端，那你很快就会发现，它带来的麻烦比解决的问题还多。

想象一下，当你需要在多个微前端之间共享状态时，你会发现自己陷入了新的困境。你可能需要引入复杂的状态管理方案，或者使用 localStorage 这种不太可靠的方式。

还有部署问题，你需要确保所有微前端的版本兼容，否则就会出现各种奇怪的 bug。更糟糕的是，当一个微前端崩溃时，可能会影响整个应用的运行。

所以，在决定使用微前端之前，先问问自己：我的应用真的大到需要微前端吗？我的团队真的需要技术栈的灵活性吗？如果答案是否定的，那还是老老实实用单体应用吧，至少调试起来方便。

当然，如果你真的需要微前端，那请务必做好规划，选择合适的框架，制定好通信机制和样式隔离方案。否则，你会发现自己掉进了一个新的坑里，而且这个坑可能比原来的还要深。