前端微前端:大型应用的模块化解决方案

前端微前端:大型应用的模块化解决方案

毒舌时刻

前端微前端?这不是过度设计吗?

"我的应用不大,不需要微前端"——结果应用越来越大,维护困难,
"微前端太复杂了,不如一个大单体"——结果团队协作困难,部署冲突,
"我用iframe就够了"——结果性能差,用户体验差。

醒醒吧,微前端不是银弹,但对于大型应用来说,它是一个有效的解决方案!

为什么你需要这个?

  • 团队协作:不同团队可以独立开发和部署
  • 技术栈灵活:不同微前端可以使用不同的技术栈
  • 独立部署:单个微前端可以独立部署,不影响其他部分
  • 可扩展性:可以轻松添加新的微前端

反面教材

<!-- 反面教材:使用iframe实现微前端 --> <!DOCTYPE html> <html> <head> <title>主应用</title> </head> <body> <h1>主应用</h1> <!-- 使用iframe加载微前端 --> <iframe src="https://micro-app1.example.com"></iframe> <iframe src="https://micro-app2.example.com"></iframe> </body> </html> 

正确的做法

// 正确的做法:使用Module Federation // 主应用webpack配置 const { ModuleFederationPlugin } = require('webpack').container; module.exports = { plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { microApp1: 'microApp1@http://localhost:3001/remoteEntry.js', microApp2: 'microApp2@http://localhost:3002/remoteEntry.js' }, shared: { react: { singleton: true, requiredVersion: '^18.0.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.0.0' } } }) ] }; // 微应用1webpack配置 const { ModuleFederationPlugin } = require('webpack').container; module.exports = { plugins: [ new ModuleFederationPlugin({ name: 'microApp1', filename: 'remoteEntry.js', exposes: { './App': './src/App' }, shared: { react: { singleton: true, requiredVersion: '^18.0.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.0.0' } } }) ] }; // 主应用中使用微应用 import React, { lazy, Suspense } from 'react'; // 懒加载微应用 const MicroApp1 = lazy(() => import('microApp1/App')); const MicroApp2 = lazy(() => import('microApp2/App')); function App() { return ( <div> <h1>主应用</h1> <Suspense fallback={<div>加载中...</div>}> <MicroApp1 /> <MicroApp2 /> </Suspense> </div> ); } // 正确的做法:使用Single-SPA // 主应用配置 import { registerApplication, start } from 'single-spa'; // 注册微应用 registerApplication({ name: 'micro-app-1', app: () => import('@org/micro-app-1'), activeWhen: (location) => location.pathname.startsWith('/micro-app-1'), customProps: { authToken: 'token' } }); registerApplication({ name: 'micro-app-2', app: () => import('@org/micro-app-2'), activeWhen: (location) => location.pathname.startsWith('/micro-app-2') }); // 启动应用 start(); // 微应用配置 import { mountRootParcel } from 'single-spa'; // 导出生命周期函数 export const bootstrap = async () => { console.log('微应用1启动'); }; export const mount = async (props) => { console.log('微应用1挂载', props); // 挂载应用 const el = document.getElementById('micro-app-1'); // 渲染应用 return Promise.resolve(); }; export const unmount = async () => { console.log('微应用1卸载'); // 卸载应用 return Promise.resolve(); }; 

毒舌点评

看看,这才叫前端微前端!不是简单地使用iframe,而是使用Module Federation或Single-SPA等专业的微前端方案。

记住,微前端不是为了拆分而拆分,而是为了解决大型应用的维护和协作问题。它需要合理的架构设计和团队协作。

所以,别再觉得微前端复杂了,它是大型应用的必然选择!

总结

  • Module Federation:Webpack 5的内置功能,支持模块共享
  • Single-SPA:最早的微前端框架,支持多种技术栈
  • Qiankun:基于Single-SPA的微前端方案,提供了更多功能
  • 独立部署:每个微前端可以独立构建和部署
  • 技术栈灵活:不同微前端可以使用不同的技术栈
  • 模块共享:共享公共依赖,减少重复加载
  • 路由管理:统一的路由管理,实现微前端间的导航
  • 状态管理:跨微前端的状态管理方案

微前端,让大型应用的开发和维护变得更加简单!

Read more

前端AI工具实践

前端AI工具实践

Claude Code前端使用 步骤一:安装 Claude Code npm install -g @anthropic-ai/claude-code 运行如下命令,查看安装结果,若显示版本号则表示安装成功 claude --version 步骤二:配置Claude Code+GLM智谱大模型(免费) Coding Tool Helper 是一个编码工具助手,安装并运行它,按照界面提示操作即可自动完成工具安装,套餐配置,MCP服务器管理等。 # 进入命令行界面,执行如下运行 Coding Tool Helper npx @z_ai/coding-helper 步骤三:开始使用 Claude Code VSCODE安装Claude Code 插件 Claude Code CLI(到指定项目目录打开CLI) Claude

为了结合后端而学习前端的学习日志(1)——纯CSS静态卡片案例

为了结合后端而学习前端的学习日志(1)——纯CSS静态卡片案例

前端设计专栏 使用纯CSS创建简洁名片卡片的学习实践 在这篇技术博客中,我将分享我的前端学习过程,如何使用纯HTML和CSS创建一个简洁美观的名片式卡片,就像我博客首页展示的那样。这种卡片设计非常适合作为个人简介、产品展示或团队成员介绍。 源码展示 <!DOCTYPEhtml><htmllang="zh-CN"><head><metacharset="UTF-8"><metaname="viewport"content="width=device-width, initial-scale=1.0"><title>纯CSS名片卡片</title><style&

Flutter 三方库 wasm_ffi 深入鸿蒙端侧硬核 WebAssembly 虚拟机沙盒穿透适配全景:通过异步极速 FFI 中继管道打通底层高算力异构服务-适配鸿蒙 HarmonyOS ohos

Flutter 三方库 wasm_ffi 深入鸿蒙端侧硬核 WebAssembly 虚拟机沙盒穿透适配全景:通过异步极速 FFI 中继管道打通底层高算力异构服务-适配鸿蒙 HarmonyOS ohos

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 wasm_ffi 深入鸿蒙端侧硬核 WebAssembly 虚拟机沙盒穿透适配全景:通过异步极速 FFI 中继管道打通底层高算力异构服务并全面实现无损语言壁垒交互 前言 在 OpenHarmony 应用向高性能计算领域扩展的过程中,如何优雅地接入已有的 C/C++ 算法库(如加密引擎、重型图像处理、数学模拟)而又不失跨平台的便捷性?传统的 NAPI 虽然稳健,但在 Flutter 生态中,直接利用 WebAssembly (WASM) 配合 FFI(External Function Interface)的语义可以在一定程度上实现代码的高度复用。wasm_ffi 库为 Flutter 开发者提供了一套在 Dart 环境下调用 WASM

WebView 并发初始化竞争风险分析

WebView 并发初始化竞争风险分析

1. 问题背景 本次验证聚焦以下场景: * 后台线程异步调用 WebSettings.getDefaultUserAgent() * 主线程在冷启动阶段首次调用 new WebView() * 两者并发进入 WebView provider / Chromium 初始化链 目标不是验证“预热是否一定提速”,而是确认: * 是否存在共享初始化链竞争 * 主线程是否会因此被拖慢或阶段性阻塞 * 是否具备演化为 ANR 的风险 2. 关键修正结论 结合当前所有日志,更准确的结论应为: getDefaultUserAgent() 与首次 new WebView() 并发时,二者并不是始终“卡死”在 WebViewFactory.getProvider() 这一行;更真实的表现是:它们会共享同一条 WebView provider / Chromium 初始化链,在不同阶段交错推进,并在部分关键节点出现阶段性等待、锁竞争或串行化,进而放大主线程耗时。 也就是说,问题本质更接近: * 交错执行