這篇文章主要介紹“如何解決Systemjs模塊化問題”，在日常操作中，相信很多人在如何解決Systemjs模塊化問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解決Systemjs模塊化問題”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！
創(chuàng)新互聯(lián)是一家專業(yè)提供洪山企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、網(wǎng)站制作、H5頁面制作、小程序制作等業(yè)務(wù)。10年已為洪山眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進行中。
如何實現(xiàn)多個應(yīng)用之間的資源共享?
之前比較多的處理方式是 npm 包形式抽離和引用，比如多個應(yīng)用項目之間，可能有某業(yè)務(wù)邏輯模塊或者其他是可復(fù)用的，便抽離出來以 npm 包的形式進行管理和使用。但這樣卻帶來了以下幾個問題：
發(fā)布效率低下。如果需要迭代npm包內(nèi)的邏輯業(yè)務(wù)，需要先發(fā)布npm包之后，在每個使用了該 npm 包的應(yīng)用都更新一次 npm 包版本，再各自構(gòu)建發(fā)布一次，過程繁瑣。如果涉及到的應(yīng)用更多的話，花費的人力和精力就更多了。
多團隊協(xié)作容易不規(guī)范。包含通用模塊的 npm 包作為共享資產(chǎn)，“每個人”擁有它，但在實踐中，這通常意味著沒有人擁有它。它很快就會充滿雜亂且風(fēng)格不一致的代碼，沒有明確的約定或技術(shù)愿景。
這些問題讓我們意識到，擴展前端開發(fā)規(guī)模以便于多個團隊可以同時開發(fā)一個大型且復(fù)雜的產(chǎn)品是一個重要但又棘手的難題。
因此，早在2016年，微前端概念誕生了。
Micro Frontends: https://micro-frontends.org/ 官網(wǎng)定義了微前端概念：
Techniques, strategies andrecipes for building a modern web app with multiple teams that can shipfeatures independently.
從 Micro Frontends 官網(wǎng)可以了解到，微前端概念是從微服務(wù)概念擴展而來的，摒棄大型單體方式，將前端整體分解為小而簡單的塊，這些塊可以獨立開發(fā)、測試和部署。同時仍然聚合為一個產(chǎn)品出現(xiàn)在客戶面前?？梢岳斫馕⑶岸耸且环N將多個可獨立交付的小型前端應(yīng)用聚合為一個整體的架構(gòu)風(fēng)格。
值得留意的幾個點：
微前端不是一門具體的技術(shù)，而是整合了技術(shù)、策略和方法，可能會以腳手架、輔助插件和規(guī)范約束這種生態(tài)圈形式展示出來，是一種宏觀上的架構(gòu)。這種架構(gòu)目前有多種方案，都有利弊之處，但只要適用當(dāng)前業(yè)務(wù)場景的就是好方案。
微前端并沒有技術(shù)棧的約束。每一套微前端方案的設(shè)計，都是基于實際需求出發(fā)。如果是多團隊統(tǒng)一使用了 react 技術(shù)棧，可能對微前端方案的跨技術(shù)棧使用并沒有要求;如果是多團隊同時使用了 react 和 vue 技術(shù)棧，可能就對微前端的跨技術(shù)棧要求比較高。
1. 拆分巨型應(yīng)用，使應(yīng)用變得更加可維護。
2. 兼容歷史應(yīng)用，實現(xiàn)增量開發(fā)。
同步更新
對比了 npm 包方式抽離，讓我們意識到更新流程和效率的重要性。微前端由于是多個子應(yīng)用的聚合，如果多個業(yè)務(wù)應(yīng)用依賴同一個服務(wù)應(yīng)用的功能模塊，只需要更新服務(wù)應(yīng)用，其他業(yè)務(wù)應(yīng)用就可以立馬更新，從而縮短了更新流程和節(jié)約了更新成本。
增量升級
遷移是一項非常耗時且艱難的任務(wù)。比如有一個管理系統(tǒng)使用 AngularJS 開發(fā)維護已經(jīng)有三年時間，但是隨時間的推移和團隊成員的變更，無論從開發(fā)成本還是用人需求上，AngularJS 已經(jīng)不能滿足要求，于是團隊想要更新技術(shù)棧，想在其他框架中實現(xiàn)新的需求，但是現(xiàn)有項目怎么辦?直接遷移是不可能的，在新的框架中完全重寫也不太現(xiàn)實。
使用微前端架構(gòu)就可以解決問題，在保留原有項目的同時，可以完全使用新的框架開發(fā)新的需求，然后再使用微前端架構(gòu)將舊的項目和新的項目進行整合。這樣既可以使產(chǎn)品得到更好的用戶體驗，也可以使團隊成員在技術(shù)上得到進步，產(chǎn)品開發(fā)成本也降到的最低。
獨立部署與發(fā)布
在目前的單頁應(yīng)用架構(gòu)中，使用組件構(gòu)建用戶界面，應(yīng)用中的每個組件或功能開發(fā)完成或者 bug 修復(fù)完成后，每次都需要對整個產(chǎn)品重新進行構(gòu)建和發(fā)布，任務(wù)耗時操作上也比較繁瑣。
在使用了微前端架構(gòu)后，可以將不能的功能模塊拆分成獨立的應(yīng)用，此時功能模塊就可以單獨構(gòu)建單獨發(fā)布了，構(gòu)建時間也會變得非?？?，應(yīng)用發(fā)布后不需要更改其他內(nèi)容應(yīng)用就會自動更新，這意味著你可以進行頻繁地構(gòu)建發(fā)布操作了。
獨立團隊決策
因為微前端構(gòu)架與框架無關(guān)，當(dāng)一個應(yīng)用由多個團隊進行開發(fā)時，每個團隊都可以使用自己擅長的技術(shù)棧進行開發(fā)，也就是它允許適當(dāng)?shù)淖寛F隊決策使用哪種技術(shù)，從而使團隊協(xié)作變得不再僵硬。
自組織模式：通過約定進行互調(diào)，但會遇到處理第三方依賴等問題。
基座模式：通過搭建基座、配置中心來管理子應(yīng)用。如基于 SIngle Spa 的偏通用的乾坤方案，也有基于本身團隊業(yè)務(wù)量身定制的方案。
去中心模式：脫離基座模式，每個應(yīng)用之間都可以彼此分享資源。如基于 Webpack 5 Module Federation 實現(xiàn)的 EMP 微前端方案，可以實現(xiàn)多個應(yīng)用彼此共享資源分享。
其中，目前值得關(guān)注是去中心模式中的 EMP 微前端方案，既可以實現(xiàn)跨技術(shù)棧調(diào)用，又可以在相同技術(shù)棧的應(yīng)用間深度定制共享資源。如果剛開始調(diào)研微前端的話，可以先嘗試了解一下EMP微前端方案，或許會給你帶來不錯的使用體驗。
Systemjs：https://github.com/systemjs/systemjs
在微前端架構(gòu)中，微應(yīng)用被打包為模塊，但瀏覽器不支持模塊化，需要使用 systemjs 實現(xiàn)瀏覽器中的模塊化。
systemjs 是一個用于實現(xiàn)模塊化的 JavaScript 庫，有屬于自己的模塊化規(guī)范。
在開發(fā)階段我們可以使用 ES 模塊規(guī)范，然后使用 webpack 將其轉(zhuǎn)換為 systemjs 支持的模塊。
案例：通過 webpack 將 react 應(yīng)用打包為 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
到此，關(guān)于“如何解決Systemjs模塊化問題”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
當(dāng)前標(biāo)題：如何解決Systemjs模塊化問題
轉(zhuǎn)載來于：http://weahome.cn/article/ighgei.html
重慶分公司
重慶分公司
