淺談umi3的微內核體系

利益無關，恰好看到umi3發佈了，其中的微內核特性挺吸引個人，因而就趁機看了一下，一探究竟。最近一次據說微內核仍是鴻蒙系統，雖然還沒看到影子。。。

插件體系

umi3的代碼組織的主要核心就是插件體系，插件驅動整個內核運轉，跟webpack有點像，可是又借鑑了babel的配置方式，有preset和plugin，其中preset裏面又能夠嵌套preset和plugin，在運行的時候會同時掃描umi配置文件、傳入的opts配置、pkg的配置、process.env等等去讀取插件，umi3從編譯、打包到cli的運轉都是經過運行插件去完成這一些的功能，對於它自身的核心包而言，就是負責去管理註冊調度這些插件，你能夠認爲它整合核心是很是小的，離開了插件，甚至不少內置的api沒辦法調用。

插件管理

umi3的插件完成的功能很是多，同時也管理很好。整個插件的調用管理採用狀態機的方式，就是你在當前階段只能完成某些操做，例如註冊plugin和preset就只能在插件註冊和pereset註冊的階段，其餘狀況下是不容許註冊的。

插件能夠幹什麼

插件還能夠校驗配置，校驗的配置是掛載在插件下的，這樣具體的插件文件只能加一個校驗配置，雖然有些限制，可是咱們能夠配置多個插件啊，逃：）。配置的校驗是在讀取配置的時候，遍歷全部插件，而後根據當前配置的key去查看當前插件是否有校驗配置，若是有，就進行配置的校驗。在內部初始化插件的時候，會調用插件方法，插件方法自己可能會經過注入hook和method等，其中注入的hook是相當重要的，由於在applyPlugin的時候，說白了，就是去觸發咱們經過插件註冊的hook。其中，觸發的時候，會由於觸發類型的不一樣，例若有add、modify、event三種，不一樣類型觸發hook的方式會致使相同key的hooks（複數）調用的方式不一樣，可能concat返回值或者modify等等，這些藉助於webpack的tapable去組織。

例如，umi dev這個命令，就是註冊dev的command，而後在你調用umi dev的時候，調用你傳入的方法，去初始化.umi文件夾，調用bundler編譯等等。除了內置插件外，其餘功能，你均可以經過添加插件或者本身編寫插件去完成。

再講兩點

再講兩點，在umi3的新版本里面看到兩個特性，支持 路由組件的導出擴展屬性和css智能模塊化，這裏就順便再講下。

css智能模塊化

umi3中css能夠智能被是否須要模塊化，原理很簡單，經過ast分析，以下的代碼中import中，specifiers的長度不爲空，其中一項爲style，那麼咱們須要改造一下source

import style from '.a.scss'
複製代碼

在source.value添加modules的loader，source.value = ${value}?${opts.flag || 'modules'};，改造以後的代碼以下，默認是modules，固然咱們還能夠傳入opts.flag傳入本身自定義的loader

import style from '.a.scss?modules'
複製代碼

支持路由組件的導出擴展屬性

好比按照如下這麼寫，路由上會多一個 title 屬性，這個umi3發佈中提到的一個功能，具體怎麼實現呢？

function HomePage() {
  return <h1>Home Page</h1>;
}
HomePage.title = 'Home Page';
export default HomePage;
複製代碼

原理很簡單，經過分析AST，找到默認導出,再找到全部的表達式，若是表達式是賦值表達式，並且左邊是對象，右邊的賦值是字符串、數字、布爾值，則把屬性導出來。

對umi3的理解暫時就這麼多，可能有理解誤差或者鄙陋，歡迎指出。