技本功丨利用 Atomic 構建 React 項目工做流，so easy!

近日刷微博，#2018年結婚率創新低#榮登熱門話題NO.1，滬浙最不積極。

生活壓力越大，缺愛的人也愈來愈多。。。據本萌的不徹底觀察，程序猿雖然是壓力加成的職業，在袋鼠雲仍是有很多早早脫了單。至於，脫單失敗的各位，那真的是憑實力單身啊~

罷遼罷遼~母胎solo多是這輩子都沒法改變的定局。若是你也是上述這類想要改變的實力單身者，歡迎給咱們投稿示愛，讓咱們一塊兒，用知識改變命運！

夫子說

用過 React 的朋友都知道，React 項目文件夾的劃分是有不少種的，在 React 官方關於文件結構這個部分給出了一些社區比較常見的構建方式的示例。例若有經過features或者routes進行分組的，也有經過模塊類型（type) 劃分的。在文檔提到了一種針對components 進行細化組織的方法 —— Atomic Design。若是還沒了解過這個設計方法的朋友，不妨來看一看。

什麼是Atomic

Atomic 是一套指導設計前端組件（Components）架構的方法。在咱們的平常工做中，如何更好的劃分和管理前端組件經常會是咱們碰到的問題。Atomic 經過一系列設計思想和原則，能夠很好指導咱們的項目架構。用 Atomic 做者本身的話說，這套設計方法的靈感是來自於本身曾經學習過的化學課，以及對天然知識自己的思考。做者經過原子（Atoms)、分子(Molecules)、 有機體(Organisms)、模板(Templates), 頁面(Pages) 這5種基本類型組件，經過靈活的組合，從而來知足咱們平常的頁面開發需求。

幾種組件的關係 - 官方圖片（參考資料：https://dwz.cn/tNve6oid）

1原子（Atoms）

正如化學知識中所表述的，原子（Atoms)是元素能保持其化學性質的最小單位，因此正好利用原子的概念，能夠用來組件系統中的最小單位的組件，或者說抽象到最小粒度的組件，即咱們在 HTML 中常見的一些基本元素，例如：按鈕（buttons)，表單標籤(labels)，輸入控件（input)等等。既然是最小單位，Atom 類型的組件顯然是沒法再進行任何拆分了，若是能繼續拆分，那麼該組件應該被劃分爲分子組件（Molecules）。

2分子（Molecules）

咱們都知道，在化學概念中，分子是有若干原子組成。經過組合各類原子組件，咱們能夠輕易的能夠組合出某種功能的分子組件。例如經過組合 input 控件和 button 組件，咱們能夠獲得一個搜索（Search)分子組件，經過組合 button 和 a 標籤，能夠能夠組合分頁（Pagination）組件。

3有機體（Organisms）

僅靠分子組件和分子組件的抽象，仍然是不能知足咱們實際工做中對組件複用的需求，例如咱們咱們大部分項目中都有導航欄（Navigation Bar)、頁頭（Header)、頁腳（Footer)、邊欄（Sidebar)、列表（List) 等等組件，顯然能夠根據須要能夠抽象成獨立組件，以便後來的項目能夠直接使用。能夠看到的是，在有原子和分子組件的狀況下，咱們經過靈活組合這些原子、分子組件的方式，即可輕易達到咱們的需求。而經過這類方式組合的組件類型咱們便稱之爲有機體組件（Organisms)。

4模板（Templates）

到這裏，模板層就很好理解了。很顯然，模板層是原子、分子、有機組件的結合體。例如包含頭部（Header、Content、Footer)常見部分的首頁模板、又或者各類左右上下佈局模板組件等等。

5頁面（Pages）

頁面這一層多是複用率最低的一層了，由於業務需求大部分時候各不相同的，固然也不排除有複用頁面的狀況。頁面組件天然就是個包含了其餘四種組件類型的綜合體了。有了前幾層組件的抽象，能夠輕鬆的應對各類業務頁面，而且不斷地能夠豐富新組件到各種型本身中去，以便後面的項目中持續使用。

綜合看下來，經過這5種組件的劃分，就能夠很好的知足咱們實際項目中對頁面組件進行劃分和管理了。

Atomic實踐

根據 Atomic 的思路, 以 src 目錄爲基礎，在 React 項目中，我能夠獲得了相似以下的開發目錄：

固然，像我一般喜歡把 pages 的層級提升，也就是把他與 components 同層，也就是：

最 後

在實際工做中，每每咱們會引用第三方的組件庫，因此不少粒度組件都不須要咱們編寫，或者說須要咱們獨立編寫的只有不多一部分，那麼能夠根據本身的實際情況來適當的縮減目錄結構，包括目錄名稱，在跟項目成員溝通達成一致的狀況下，也能夠用其餘的命名規則。若是你正在設計一個完整的 UI 組件系統的話，或者你在開發一個大型的Web系統，那麼更詳細的劃分規則可能會更有利於後期的維護和開發了。

Atomic 始終是一套設計思想，在實踐中咱們能夠更靈活的根據本身業務，團隊的狀況進行合適的調整，從而更好的知足咱們的開發需求。