您好,登錄后才能下訂單哦!
小編給大家分享一下如何使用React進行組件庫開發,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
概述
我們都知道,組件化的開發模式對于我們的開發效率有著極大的提升,針對我們日常使用的基本組件進行封裝,可以大量的簡化我們對于基本UI的關注度,讓我們的工作聚焦在業務邏輯上,很好的分離業務與基礎UI的代碼,使得整個項目更有調理,這也是我們要進行本組件庫開發的原因。
然而現有React開源組件有很多,像ant-design和material-ui等等,是否需要花費精力打造適合自身團隊的組件庫往往需要酌情考慮。我們來看下我現有團隊及業務的幾個特點:
前端人員較多,需要相互協作,且有余力對組件進行開發
產品業務相對復雜,需對某些組件進行定制化開發
已經有成熟的設計規范,針對各種基礎組件、基礎樣式等進行定義
目前的項目較為凌亂,第三方組件引用雜亂無章
可以看出,我們擁有封裝自己組件的精力和基礎,并且擁有通過基礎組件封裝改變目前開發現狀的需求。所以,這件事情是我們應該并且需要盡快完成的事情。
技術選型
針對組件庫的封裝,我們首先面對的是技術選型以及方案的規劃。大概包括以下兩點:
最基本的技術方案
開發流程和規范
技術方案選擇
Webpack + React + Sass
由于團隊現有的項目都是基于React+Redux進行開發的,那我們選擇的開發語言無疑是React。
SASS
針對css選擇,雖然現在針對組件化開發,比較流行CSS Modules和CSS-IN-JS兩中模塊化解決方案,我們更希望我們的組件是可進行定制的。因此針對組件,我們以Sass作為預編譯語言,提搞效率和規范性。配合css-modules,我們可以很方便的進行針對實際需求進行樣式更改。例如我們有一個Tab組件,我們已經定義好了其通用的樣式:
.tip-tab { border: 1px solid #ccc; } .tip-tab-item { border: 1px solid #ccc; &.active { border-color: red; } }
而在業務中,針對某一個需求,我們需要針對Tab組件的樣式進行微調。讓其在激活(active)狀態下border-color是藍色的。你當然可以說,我們可以讓我們的組件暴露出一些props,針對這些修改進行配置,傳入不同的props對應不同的風格。但是我們往往無法滿足所有的業務需求,不可能針對組件把各種樣式都封裝進去。針對這種方案,我們采用css-modules為其添加唯一的模塊樣式:
<Tab styleName="unique-tab" />
針對該模塊,對其進行基本樣式的修改:
.unique-tab { :global { .tip-tab-item { border-color: #eee; &.active { border-color: blue; } } } }
這樣,針對該模塊的定制樣式,能很好的進行針對需求的樣式定制,同時不對全局樣式進行污染。
Icon
針對項目圖標,計劃使用svg-sprite方案。但是由于產品處于在不斷迭代的過程中,新的圖標不斷在增加。目前我們并不會對圖標統一進行打包,而是在每次進行組件打包的過程中,從項目中導入所有的圖標。用以下方式進行引入:
import Icon from '@common/lib' import errorIcon from '@images/error.svg' <Icon link={errorIcon} />
其實更好的方式是針對所有的圖標進行統一打包,生成svg-spirte文件(具體原理可以查詢svg-sprite,在此不再贅述)。當我們進行使用時,只需直接引用即可,避免每次都進行打包,減少webpack處理依賴的時間:
<Icon type="error" />
開發流程和規范
針對開發流程和規范,我們遵循以下幾個原則:
組件庫完全獨立于項目進行開發,便于后續多個項目進行使用等
組件庫包含三種模式:開發,測試,打包,文檔案例,區分不同的入口及狀態
使用pure-renderautobind等盡可能保證組件的性能及效率
保證props和回調的語義性,如回調統一使用handleXXX進行處理
為了便于后續的擴展,我們更希望整個組件庫完全脫離于項目進行開發。保證組件庫僅對于最基本的組件進行封裝,將項目UI代碼與業務邏輯進行分離。
針對不同的模式下,我們有不同的文件入口,針對開發模式,我們啟動一個dev-server, 在里面對組件進行基本的封裝,并進行調試。打包時,我們只需對組件內容進行封裝,暴露統一的接口。在文檔中,我們需要進行案例和說明的展示。所以我們在利用webpack的特性進行各種環境的配置:
npm run dev // 開發 npm run test // 測試 npm run build // 構建 npm run styleguide // 文檔開發 npm run styleguide:build // 文檔打包
組件庫作為項目的最小力度支持,我們需要保證其最基本的渲染效率,因此我們采用pure-render/autobind等對其進行基本的優化。React有很多優化方式,在此不進行贅述。
打包
基礎
針對組件庫的打包,我們以UMD格式對其進行打包。webpack可以針對輸出進行格式設置:(引自cnode)
“var” 以變量方式輸出
“this” 以 this 的一個屬性輸出: this[“Library”] = xxx;
“commonjs” 以 exports 的一個屬性輸出:exports[“Library”] = xxx;
“commonjs2” 以 module.exports 形式輸出:module.exports = xxx;
“amd” 以 AMD 格式輸出;
“umd” 同時以 AMD、CommonJS2 和全局屬性形式輸出。
配置如下:
output: { path: config.build.assetsRoot, filename: utils.assetsPath('js/[name].js'), chunkFilename: utils.assetsPath('js/[id].js'), library: 'TipUi', libraryTarget: 'umd' }
依賴
很明顯,我們封裝的是一個針對React的組件庫,并不應該把React引用進去。一般我們可以采用externals的方式對其進行處理。
在這里, 我們采用dll方式將其與其他第三方依賴統一進行打包,并將manifest.json和三方依賴的輸出文件輸出到項目中去,在項目中也使用dllReference進行引用。避免在項目中使用到這些依賴時重復進行打包。
同時,由于我們的組件庫處于一個不斷維護的狀態。這就需要我們維持好項目庫和項目之間的打包關系,具體的流程如圖所示:
在每次進行項目打包的時候,首先檢測UI庫是否有更新,若沒有更新,則直接進行打包。反之繼續檢測dll的依賴是否有變化,若有,則打包dll,否則直接打包組件庫內容。然后將輸出結果同步到項目中,再進行最終打包。
當然,以上的這些流程都是自動進行的。
文檔和示例
一個完善的文檔對于一個組件庫是及其重要的,每個組件有什么樣的配置參數,擁有哪些事件回調,對應的Demo和展示效果。假設沒有這些,除了封裝組件的人,沒有人知道它該如何使用。但是寫文檔的過程往往是痛苦的,在這里推薦幾個文檔生成庫,可以極大的簡化文檔工作:
docsify 基于Vue的組件生成器,輕量好用
react-styleguidist 基于React的組件庫文檔生成器,自動根據注釋生成文檔,支持Demo展示。超好用
bisheng ant design自己寫的文檔生成器
我們使用的styleguidist, 可以將md自動轉化為文檔,支持在md內直接調用你封裝好的組件并進行展示,簡單好用。最后封裝的文檔大概長這樣:
其實封裝組件庫這種工作有很多的東西值得琢磨和鉆研,由于篇幅原因,在這里只對開發過程中比較糾結的選型和打包等進行討論,后續再對具體組件的封裝進行討論。在書寫的同時,不斷參考下ant design這種優秀的組件庫,能學到很多的東西。更深刻的理解封裝組件的思想,是一個很好的過程。
以上是“如何使用React進行組件庫開發”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。