正文
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
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應該如何處理?
可以想到的方案有,
- externals(webpack 支持外部引用)
- 公用dll
但會帶來額外的問題,
1.某些原本可以按需加載的包無法按需,比如antd,只能全量引入
2.版本同步以及升級問題,比如之后要升級antd@4,那么所有的分包都需要一起升級
問題匯總
目前umi 3.x問題還是會有一些的,主要是文檔里記錄不全
src/global.js與 src/global.css
自定義字體
總結
回歸到實際業務中,我們目前所遇到的問題是應用已經變成巨大的包了,雖然使用的技術棧依賴都比較新,但長此以往下去歷史包袱顯而易見的會比較沉重,更不用說各個模塊里混雜的 flow.js TypeScript jsx 各種不兼容的寫法了,因此解耦還是很有必要的.
umi可以作為先行試驗方案,主要是為了將項目中打包相關的代碼從主包中抽離出去,好處是這樣打包器的優化就基本不受老項目的代碼風格影響,在滿足了之前的需求之后,還可以通過插件的形式,不斷優化研發流程,提高開發效率,提高性能;且對於日常開發可以做到無感知升級.
使用現在的協同系統中的架構進行調試和打包與替換為umi做一個對比(相關例子請參考現場演示):
| project | dev調試速度 | build包大小 |
|---|---|---|
| heihu-web | 3.55 min | 50.5 MB |
| umi-heihu-web | 1.12 min | 23 MB |
后記
也可以參考 Alita-基於umi的移動端框架 使用 Cordova 來達到跨平台的目的.成本比RN要小很多.
over!