如何解决Systemjs模块化问题

这篇文章主要介绍“如何解决Systemjs模块化问题”，在日常操作中，相信很多人在如何解决Systemjs模块化问题问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何解决Systemjs模块化问题”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

创新互联是一家专业提供洪山企业网站建设,专注与成都做网站、网站制作、H5页面制作、小程序制作等业务。10年已为洪山众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。

如何实现多个应用之间的资源共享?

之前比较多的处理方式是 npm 包形式抽离和引用，比如多个应用项目之间，可能有某业务逻辑模块或者其他是可复用的，便抽离出来以 npm  包的形式进行管理和使用。但这样却带来了以下几个问题：

• 发布效率低下。如果需要迭代npm包内的逻辑业务，需要先发布npm包之后，在每个使用了该 npm 包的应用都更新一次 npm  包版本，再各自构建发布一次，过程繁琐。如果涉及到的应用更多的话，花费的人力和精力就更多了。

• 多团队协作容易不规范。包含通用模块的 npm  包作为共享资产，“每个人”拥有它，但在实践中，这通常意味着没有人拥有它。它很快就会充满杂乱且风格不一致的代码，没有明确的约定或技术愿景。

这些问题让我们意识到，扩展前端开发规模以便于多个团队可以同时开发一个大型且复杂的产品是一个重要但又棘手的难题。

因此，早在2016年，微前端概念诞生了。

什么是微前端?

微前端的概念

Micro Frontends: https://micro-frontends.org/ 官网定义了微前端概念：

Techniques, strategies andrecipes for building a modern web app with multiple  teams that can shipfeatures independently.

从 Micro Frontends  官网可以了解到，微前端概念是从微服务概念扩展而来的，摒弃大型单体方式，将前端整体分解为小而简单的块，这些块可以独立开发、测试和部署。同时仍然聚合为一个产品出现在客户面前。可以理解微前端是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。

值得留意的几个点：

• 微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、辅助插件和规范约束这种生态圈形式展示出来，是一种宏观上的架构。这种架构目前有多种方案，都有利弊之处，但只要适用当前业务场景的就是好方案。

• 微前端并没有技术栈的约束。每一套微前端方案的设计，都是基于实际需求出发。如果是多团队统一使用了 react  技术栈，可能对微前端方案的跨技术栈使用并没有要求;如果是多团队同时使用了 react 和 vue 技术栈，可能就对微前端的跨技术栈要求比较高。

微前端的使用场景

1. 拆分巨型应用，使应用变得更加可维护。

2. 兼容历史应用，实现增量开发。

微前端的优势

同步更新

对比了 npm  包方式抽离，让我们意识到更新流程和效率的重要性。微前端由于是多个子应用的聚合，如果多个业务应用依赖同一个服务应用的功能模块，只需要更新服务应用，其他业务应用就可以立马更新，从而缩短了更新流程和节约了更新成本。

增量升级

迁移是一项非常耗时且艰难的任务。比如有一个管理系统使用 AngularJS  开发维护已经有三年时间，但是随时间的推移和团队成员的变更，无论从开发成本还是用人需求上，AngularJS  已经不能满足要求，于是团队想要更新技术栈，想在其他框架中实现新的需求，但是现有项目怎么办?直接迁移是不可能的，在新的框架中完全重写也不太现实。

使用微前端架构就可以解决问题，在保留原有项目的同时，可以完全使用新的框架开发新的需求，然后再使用微前端架构将旧的项目和新的项目进行整合。这样既可以使产品得到更好的用户体验，也可以使团队成员在技术上得到进步，产品开发成本也降到的最低。

独立部署与发布

在目前的单页应用架构中，使用组件构建用户界面，应用中的每个组件或功能开发完成或者 bug  修复完成后，每次都需要对整个产品重新进行构建和发布，任务耗时操作上也比较繁琐。

在使用了微前端架构后，可以将不能的功能模块拆分成独立的应用，此时功能模块就可以单独构建单独发布了，构建时间也会变得非常快，应用发布后不需要更改其他内容应用就会自动更新，这意味着你可以进行频繁地构建发布操作了。

独立团队决策

因为微前端构架与框架无关，当一个应用由多个团队进行开发时，每个团队都可以使用自己擅长的技术栈进行开发，也就是它允许适当的让团队决策使用哪种技术，从而使团队协作变得不再僵硬。

微前端落地方案

自组织模式：通过约定进行互调，但会遇到处理第三方依赖等问题。

基座模式：通过搭建基座、配置中心来管理子应用。如基于 SIngle Spa 的偏通用的乾坤方案，也有基于本身团队业务量身定制的方案。

去中心模式：脱离基座模式，每个应用之间都可以彼此分享资源。如基于 Webpack 5 Module Federation 实现的 EMP  微前端方案，可以实现多个应用彼此共享资源分享。

其中，目前值得关注是去中心模式中的 EMP  微前端方案，既可以实现跨技术栈调用，又可以在相同技术栈的应用间深度定制共享资源。如果刚开始调研微前端的话，可以先尝试了解一下EMP微前端方案，或许会给你带来不错的使用体验。

Systemjs 模块化解决方案

Systemjs：https://github.com/systemjs/systemjs

在微前端架构中，微应用被打包为模块，但浏览器不支持模块化，需要使用 systemjs 实现浏览器中的模块化。

systemjs 是一个用于实现模块化的 JavaScript 库，有属于自己的模块化规范。

在开发阶段我们可以使用 ES 模块规范，然后使用 webpack 将其转换为 systemjs 支持的模块。

案例：通过 webpack 将 react 应用打包为 systemjs 模块，在通过 systemjs 在浏览器中加载模块。

npm install webpack@5.17.0webpack-cli@4.4.0 webpack-dev-server@3.11.2  html-webpack-plugin@4.5.1@babel/core@7.12.10 @babel/cli@7.12.10  @babel/preset-env@7.12.11@babel/preset-react@7.12.10 babel-loader@8.2.2

src/index.html

src/index.js

src/App.js

package.json

webpack.config.js

到此，关于“如何解决Systemjs模块化问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！