在我们学习微前端前,是要做一定的知识储备的,概念 和 代码 结合在一起,才能保证我们完全去理解到一种思想或者一种技术的真正意义。
这一章节最主要是要告诉大家在基于single-spa 学习微前端的时候,需要掌握哪些基础知识,通过了解到这些知识后,我们学起来single-spa 也会快一些,single-spa 学的快了,我们了解微前端的概念也就会要快很多
# js相关
这个就不多说了,前端必备知识基础
# webpack 基础
webpack 其实也是必备的知识点了,如果你使用了官方提供的create-single-spa的包,则不需要手动配置,如果你是基于现有的项目基础上去做的重构,则还是自己手动配置一下会更加安全一些:
- 将
single-spa输出的目标设置为system
// webpack.config.js
{
output: {
libraryTarget: 'system'
}
}
设置该属性的目的,是由于single-spa的部分功能是基于 systemjs (opens new window) 实现的,所以要保证输出的正确使用
- 动态导入模块,不要使用
Optimization
{
entry: {
index: './src/index.js'
}
}
设置单一的入口,通过import()语法动态导入每一个子应用,single-spa 官方的理念就是 “一个子应用是一个动态导入的模块”:
// before
import $ from 'jquery'
function myComponent() {
$('#app').append('<div></div>')
}
// after
function myComponent() {
import('jquery').then(({default: $}) => {
$('#app').append('<div></div>')
})
}
这个就不做太多详解了,webpack官方有详细的解释,就是告诉大家要这么做,理解了即可;
- 针对
webpack的systemjs配置
其中一项配置在上面已经说到了,就是设置libraryTarget,另一项就是下方这段代码,目的是如果System在webpack中是通过 global构建的代码,那么就需要通过下面的配置来避免重写
{
module: {
rules: [
{ parser: { system: false } }
]
}
}
- 使用 systemjs-webpack-interop (opens new window) 来创建、验证、你的
webpack配置;还可以用来设置public path,single-spa的微应用入口:
import { setPublicPath } from "systemjs-webpack-interop";
/* This dynamically sets the webpack public path so that code splits work properly. See related:
* https://github.com/joeldenning/systemjs-webpack-interop#what-is-this
* https://webpack.js.org/guides/public-path/#on-the-fly
* https://single-spa.js.org/docs/faq/#code-splits
*/
setPublicPath("@spa/react");
类似于这样,然后通过在importmap中注册,root config 中调用@spa/react即可,稍后的实例当中会做详解
- 不要设置
output.library
systemjs 不需要一个导出的变量,事实上在没有更多配置的情况下也不支持具名模块
- 设置
webpack-dev-server不检查hosts
{
devServer: {
disableHostCheck: true
}
}
- 允许跨域
{
devServer: {
headers: {
'Access-Control-Allow-Origin': '*'
}
}
}
- 设置
externals是正确并共享的运行时模块
{
externals: [ 'single-spa', /^@spa\// ]
}
大概比较核心的配置项就是这么多,剩下的一些配置项也不是特别重要了,剩下一些不重要的配置大家可以在single-spa官网查看
# systemjs
systemjs (opens new window) 是一个标准的模块加载器,single-spa 项目中可以通过 systemjs 在浏览器中下载并执行子应用
# 微前端四大特性
single-spa官方把微前端分为三种类型:
受路由控制渲染的子应用(applications)不受路由控制的组件(parcels)非渲染组件,应用间通信逻辑(utility modules)
在我看来,其实应该还有一个类型,就是 root config
root config在我看来,作为子应用通信的路由配置,也是一个非常重要的环节,所有子应用的特殊处理情况都是需要在root config做处理的,所以我认为它应该是其中一个比较重要的特性
这一章节大概的内容就是告诉大家需要掌握或者配置哪些信息就可以通过single-spa来学习微前端了