正文

umi官網,文章中所提到的例子地址為https://github.com/leomYili/umiAppDemo

簡介

可以先通過官網的例子來大致看一下用法

也可以通過提供的腳手架甚至從 create-react-app(cra) 進行遷移.

那麼與 cra 這類比較整合式的腳手架相比,umi有什麼優勢呢?

umi的優勢

如果讓我來介紹的話,吸引我的點就是:

• 可以從外部以外掛的形式,定製化修改webpack配置
• 可自定義的打包速度,包括了是否編譯node_modules
• 雖然官方提供了很多的外掛,但相比其他腳手架來說,可以解除安裝掉所有外掛,甚至通過外掛的形式可以打RN的包
• 完善的文件以及命令列工具還有環境變數,特別是外掛文件,因為有足夠的例子,可以做到循序漸進;之後如果涉及到微前端,元件打包都是很好的參考
• 還有一整套的解決方案,包括元件開發以及微前端
• 相比較完全自定義打包配置而言,umi確實都可以做到,而且還有外掛規範,方便複用,這一點尤為重要
• 不僅僅是專案腳手架,也提供了元件腳手架,之前的field-form就是用這個打包的

當然也會有不足:

• 內建react-router,以及強制的routers配置,當使用其他的路由方案或者自定義路由時比較麻煩.
• 配置相較其他腳手架來說相對複雜,且因為很多引數無法直觀的展示,所以需要實驗之後才能瞭解用法,建議多看官方的 issues

與 Roadhog 區別

Roadhog 是一個包含 dev、build 和 test 的命令列工具，他基於 react-dev-utils，和 create-react-app 的體驗保持一致。你可以想象他為可配置版的 create-react-app。

相比較來說,這更像 react-app-rewird,所以與 umi 不是一個維度的方案

與 next.js 區別

這點官網上也有對比,而在我看來,最重要的也不是路由配置或者提供了dva(我也不怎麼用dva),而是在兩者相比功能類似的情況下,是否可擴充套件,且是否能夠更多的避免配置一些常用類庫對於研發效率來說才是最重要的,需要一個比較不錯的落地方案,而不是看上去很美好,但實際用不到的功能,比如說ssr,中後臺管理系統中很少會涉及這一方面,更不用說umi也提供了,甚至擴充套件體系中還提供了Alita-基於umi的移動端框架以及 umi-plugin-qiankun、umi-react-native

自定義路由

其實也可以模仿官方的 @umijs/plugin-layout

可以看到,兩者都是遞迴遍歷得到路由樹,然後使用 <Link to={route.path}>{route.breadcrumbName}</Link> 做一層包裹用於跳轉,達到自定義路由的目的

這裡的情況適用於搭建中後臺管理系統

routers

1. getMatchMenu

mpa

這裡需要注意,開啟了mpa之後,就只能對映到一級路由,從 .umi 檔案中可以看出

根路由規則改變了,請使用 XXX.html進行訪問

分包

關於umi的分包,我理解分包是指把一個應用的部分拆出去,然後按需引入.拆的部分可以是路由、model、service、元件等等

這是個小眾的需求,有幾個場景會用上

1.一個場景是路由的分包

一個站點會包含很多路由,然後一些場景下,比如業務專案,或者umi ui的外掛化,或者專案太大了想要拆子系統,都會希望能把其中部分路由拆出去,交給其他人維護,然後拆出去的部分提供umd包進行對接

2.一個場景是元件的分包

比如雲鳳蝶的場景,雲鳳蝶包含page和component,page是架子,由多個component組成,但包含哪些component是不確定的.所以做component的分包可以讓page按需引用component.

對接方式

1.npm依賴
2.umd包

各有優劣勢.第一種應用場景有限;第二種可以在執行時(html)靈活組合,但是會有冗餘問題.

關於冗餘

比如包a和包b都依賴antd,antd應該如何處理?

可以想到的方案有,

1. externals(webpack 支援外部引用)
2. 公用dll

但會帶來額外的問題,

1.某些原本可以按需載入的包無法按需,比如antd,只能全量引入
2.版本同步以及升級問題,比如之後要升級antd@4,那麼所有的分包都需要一起升級

問題彙總

目前umi 3.x問題還是會有一些的,主要是文件裡記錄不全

src/global.js與 src/global.css

自定義字型

總結

迴歸到實際業務中,我們目前所遇到的問題是應用已經變成巨大的包了,雖然使用的技術棧依賴都比較新,但長此以往下去歷史包袱顯而易見的會比較沉重,更不用說各個模組裡混雜的 flow.js TypeScript jsx 各種不相容的寫法了,因此解耦還是很有必要的.

umi可以作為先行試驗方案,主要是為了將專案中打包相關的程式碼從主包中抽離出去,好處是這樣打包器的優化就基本不受老專案的程式碼風格影響,在滿足了之前的需求之後,還可以通過外掛的形式,不斷優化研發流程,提高開發效率,提高效能;且對於日常開發可以做到無感知升級.

使用現在的協同系統中的架構進行除錯和打包與替換為umi做一個對比(相關例子請參考現場演示):

後記

也可以參考 Alita-基於umi的移動端框架 使用 Cordova 來達到跨平臺的目的.成本比RN要小很多.

over!