Jay 是一位經驗豐富並且對質量要求很高的開發者，對 Angular、React 等多種框架都很熟悉，我們在開源社群認識，在我做開源社群運營的過程中，Jay 給了我很多幫助，他也是 React DevUI 開源元件庫的建立者。
2021年11月，由 Jay 主導發起了 React DevUI 開源元件庫專案，經過一年多的孵化?，終於在2022年11月23日釋出 18.0.0 正式版本?
特性：
- 基於最新的
React 18+TypeScript+Nx技術棧 - 包含
51個靈活、高質量的元件 - 包含配套的 Admin 系統（持續完善中）
- 支援主題定製
- 支援國際化
- 支援 TypeScript
- 支援 Monorepo
- 支援單元測試（持續完善中）
- 包含完善的設計指南 / 開發規範 / 貢獻流程
- 完善的構建 / 釋出 / 測試 / 依賴管理等基礎設施
除了使用了最新的技術進行元件開發之外，React DevUI 還對元件的細節體驗進行極致的打磨，比如：
- ? 所有元件和網站均遵循WCAG 2.0規範做了無障礙設計（Accessibility），比較明顯的就是焦點管理和對鍵盤方向鍵的支援，歡迎到我們的官網體驗。
- ⚡ 針對大資料量的列表做了極致的虛擬滾動，渲染和篩選數十萬資料無任何卡頓，感興趣可以體驗下我們的Select元件。
- ✨ 在API設計上，我們也經過了仔細的推敲和思考，所有元件的 API 都以易用和是否符合預期為設計原則，簡潔、靈活、開發者友好，從Compose元件就可以窺見一斑。
為什麼要開發這個元件庫
接觸前端從 Vue2 開始，深入學習的是 Angular（公司專案），這裡插一句，Angular 作為前端開發者真的可以好好學一下，主要是學習其程式設計思想和比較與其它框架的差異。我個人對於 React 還是非常感興趣的，所以當時就看了 React17 官網文件和相關教程，state => ui 這種純粹的驅動模式簡直是完美，我喜歡這種可靠的渲染，但奇葩的是非同步函式里呼叫 setState 會立即重新渲染，雖然到目前為止我都沒有過多時間瞭解 React18 之前的東西，不過當時我就想這絕對是個 bug 收集器。
可能緣分是個奇妙的東西，我不知道怎麼就看到的 React18 的新特性，這個 concurrency（併發）那可真是看的我人麻了，這絕對會是目前最好的框架，那一刻 jay 知道必須寫個元件庫。
元件庫的技術選型
開發元件庫的技術棧為 react18 + ts + sass，react18 + ts 沒啥好說的，這裡說說為什麼用 sass。
當初也有人建議用 css in js，其實在這之前我是不知道這個概念的，畢竟沒用過 React，瞭解之後發現其靈活性的確是 sass 無法比擬的，但是我真的要為了這種靈活性捨棄：
- 開發成本，sass 作為最受歡迎的 css 擴充套件，但凡前端幾乎瞭解，不瞭解的也無所謂，sass 完全相容 css 語法。
- 樣式獨立，樣式獨立於元件，我希望開發其它框架元件時不用再寫一套樣式，本質是一種模組化，即樣式的模組化，我相信好處不止於此。
- 效能。
最終我選擇 sass，而且 sass + css 變數 的靈活性不見得不如 css in js，特別是有樣式規範的情況下。
元件遵循的規範
元件庫從誕生之初就遵循下面最基本的規範：
- 如果有 無障礙 支援，那麼一定要實現。
- 國際化（i18n）支援。
- SSR 支援。
- 移動裝置支援。
後面開發中新增了元件類支援：
其它的一些規範：
- Prop 命名，如支援 form 的輸入為
dModel，彈窗狀態統一為dVisible。 - 列表類元件的大資料支援，實現時間複雜度為 O(n)，如 Select 選擇框。
- 一些邊邊角角我實在記不起來了。
樣式規範
元件樣式規範：
- 命名遵循 BEM 規範。
- 明顯的聚焦或啟用樣式反饋。
- 內斂的動畫，即動畫變化屬性數量儘可能少（一般小於等於 2 個），如 Button 聚焦時僅變化背景色或邊框。
優勢在於是由經驗豐富的技術大佬主導的開源專案
說吧，為啥用你這元件庫。
所有元件由 jay 開發，這意味著：
- 所有元件均遵循規範。
- 統一的 API 設計。
- 統一的樣式設計。
- 效能的把控。
- 極簡的大小，npm 包 未壓縮 不超過 1MB！
網址
- GitHub - 歡迎大家點亮Star?
- React DevUI 官網
- React DevUI Admin 官網
--- END ---
我是 Kagol，如果你喜歡我的文章，可以給我點個贊，關注我的掘金賬號和公眾號 Kagol，一起交流前端技術、一起做開源！