數棧是雲原生—站式數據中臺PaaS，咱們在github和gitee上有一個有趣的開源項目：FlinkX，FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，也能夠採集實時變化的數據，是全域、異構、批流一體的數據同步引擎。你們喜歡的話請給咱們點個star！star！star！前端
github開源項目：https://github.com/DTStack/flinkxgit
gitee開源項目：https://gitee.com/dtstack_dev_0/flinkx
github
用過 React 的朋友都知道，React 項目文件夾的劃分是有不少種的，在 React 官方關於文件結構這個部分給出了一些社區比較常見的構建方式的示例。例若有經過features或者routes進行分組的，也有經過模塊類型（type) 劃分的。在文檔提到了一種針對components 進行細化組織的方法 —— Atomic Design。若是還沒了解過這個設計方法的朋友，不妨來看一看。架構
1、什麼是Atomic
Atomic 是一套指導設計前端組件（Components）架構的方法。在咱們的平常工做中，如何更好的劃分和管理前端組件經常會是咱們碰到的問題。Atomic 經過一系列設計思想和原則，能夠很好指導咱們的項目架構。用 Atomic 做者本身的話說，這套設計方法的靈感是來自於本身曾經學習過的化學課，以及對天然知識自己的思考。做者經過原子（Atoms)、分子(Molecules)、 有機體(Organisms)、模板(Templates), 頁面(Pages) 這5種基本類型組件，經過靈活的組合，從而來知足咱們平常的頁面開發需求。ide
一、原子（Atoms）工具
正如化學知識中所表述的，原子（Atoms)是元素能保持其化學性質的最小單位，因此正好利用原子的概念，能夠用來組件系統中的最小單位的組件，或者說抽象到最小粒度的組件，即咱們在 HTML 中常見的一些基本元素，例如：按鈕（buttons)，表單標籤(labels)，輸入控件（input)等等。既然是最小單位，Atom 類型的組件顯然是沒法再進行任何拆分了，若是能繼續拆分，那麼該組件應該被劃分爲分子組件（Molecules）。佈局
二、分子（Molecules）學習
咱們都知道，在化學概念中，分子是有若干原子組成。經過組合各類原子組件，咱們能夠輕易的能夠組合出某種功能的分子組件。例如經過組合 input 控件和 button 組件，咱們能夠獲得一個搜索（Search)分子組件，經過組合 button 和 a 標籤，能夠能夠組合分頁（Pagination）組件。atom
三、有機體（Organisms）url
僅靠分子組件和分子組件的抽象，仍然是不能知足咱們實際工做中對組件複用的需求，例如咱們咱們大部分項目中都有導航欄（Navigation Bar)、頁頭（Header)、頁腳（Footer)、邊欄（Sidebar)、列表（List) 等等組件，顯然能夠根據須要能夠抽象成獨立組件，以便後來的項目能夠直接使用。能夠看到的是，在有原子和分子組件的狀況下，咱們經過靈活組合這些原子、分子組件的方式，即可輕易達到咱們的需求。而經過這類方式組合的組件類型咱們便稱之爲有機體組件（Organisms)。
四、模板（Templates）
到這裏，模板層就很好理解了。很顯然，模板層是原子、分子、有機組件的結合體。例如包含頭部（Header、Content、Footer)常見部分的首頁模板、又或者各類左右上下佈局模板組件等等。
五、頁面（Pages）
頁面這一層多是複用率最低的一層了，由於業務需求大部分時候各不相同的，固然也不排除有複用頁面的狀況。頁面組件天然就是個包含了其餘四種組件類型的綜合體了。有了前幾層組件的抽象，能夠輕鬆的應對各類業務頁面，而且不斷地能夠豐富新組件到各種型本身中去，以便後面的項目中持續使用。
綜合看下來，經過這5種組件的劃分，就能夠很好的知足咱們實際項目中對頁面組件進行劃分和管理了。
2、Atomic實踐
根據 Atomic 的思路, 以 src 目錄爲基礎，在 React 項目中，我能夠獲得了相似以下的開發目錄：
固然，像我一般喜歡把 pages 的層級提升，也就是把他與 components 同層，也就是：
這裏有個倉庫 Demo 能夠參考：
https://github.com/wewoor/atomic-example
3、總結
在實際工做中，每每咱們會引用第三方的組件庫，因此不少粒度組件都不須要咱們編寫，或者說須要咱們獨立編寫的只有不多一部分，那麼能夠根據本身的實際情況來適當的縮減目錄結構，包括目錄名稱，在跟項目成員溝通達成一致的狀況下，也能夠用其餘的命名規則。若是你正在設計一個完整的 UI 組件系統的話，或者你在開發一個大型的Web系統，那麼更詳細的劃分規則可能會更有利於後期的維護和開發了。
Atomic 始終是一套設計思想，在實踐中咱們能夠更靈活的根據本身業務，團隊的狀況進行合適的調整，從而更好的知足咱們的開發需求。
更詳細內請看Atomic Design：