ProComponents 的理念

Ant Design 定義了基礎的設計規範，對應也提供了大量的基礎組件。可是對於中後臺類應用，咱們但願提供更高程度的抽象，提供更上層的設計規範，而且對應提供相應的組件使得開發者能夠快速搭建出高質量的頁面。

在 ProComponents 中咱們內置了一系列的設計規範，預設了經常使用的邏輯。在這個基礎上咱們一樣提供了靈活的支持，好比對於 ProTable 來講你也能夠把它徹底當作 Ant Design 的 Table 來用，對於 ProForm 來講你也能夠直接使用 Ant Design 的基礎組件或者你的自定義組件。咱們但願經過 Pro 系列組件提供快速高效你們高質量中後臺應用的能力，進一步擴展 Ant Design 的能力，歡迎使用並提出寶貴的意見。

設計思路

對於幾乎全部的業務來講，咱們作的其實就是根據一個狀態定義一系列的行爲，以上面的 table 爲例，首先咱們須要一個狀態 dataSource 用於存儲從服務器請求的數據，爲了優化體驗，咱們還須要一個 loading。因而咱們就有了一系列的行爲，咱們須要先設置 loading=true，而後發起網絡請求，網絡請求完成以後就 設置 dataSource 爲請求回來的數據，loading=false，一個網絡請求就完成了，雖然很是簡單，可是一個業務系統有至關多的表格，每一個表格都定義這麼一次，這個工做量就很是大了。

若是要從新請求網絡，咱們就須要封裝一下行爲，將以上的行爲封裝成一個方法，點擊一下從新加載數據，若是你有分頁，那麼就須要新的變量 page，咱們在從新請求以前須要去根據須要來判斷一下是否將頁面重置爲第一頁，這又引入了一個變量。若是你的表格還要控制每頁的數量，那麼將會更加繁雜。這種重複性的勞動會浪費掉咱們的不少時間。

一個狀態加一系列行爲

以上的邏輯幾乎存在於全部中後臺開發中，每增長一個狀態咱們就須要一系列的行爲來進行管理，每一個行爲若是耦合了太多的狀態也會複雜到無以復加。

碰上這種狀況，幾乎全部程序員都會想辦法進行分層，基於一樣的思路，ProTable 但願抽象出一層來解決掉複雜狀態的問題，table 中最經常使用的狀態就是 loading 和 dataSource，包括擴展的 page,pageSize 其實都是服務於網絡狀態，因而 table 抽象出了一個 request 的 api，在其中封裝了 loading 和 dataSource 狀態以及他們全部的行爲，上一頁，下一頁，從新刷新，修改每頁大小等行爲。

這種封裝模式可讓前端從各類狀態管理中脫身出來，專一於業務開發，也不須要 dva，redux 等數據流的方案，更加符合直覺。開發者只須要定義一個狀態，重型組件會自動生成一系列行爲。

爲了漸進式使用咱們也提供了與 Ant Design 相同的 api，徹底能夠降級成爲一個 Ant Design 的 table 使用。

一個組件 ≈ 一個頁面

重型組件區別於傳統組件有個很大的不一樣，重型組件在抽象時是將其當成一個頁面來進行處理，因此 ProTable 會支持網絡請求和自動生成查詢表單，而 ProLayout 會支持自動生成菜單，二者都基於一樣的思想也就是提供頁面級別的抽象。

一個列表頁應該能夠用 ProLayout + ProTable 完成，一個編輯頁應該使用 ProLayout + ProForm 完成，詳情頁能夠用 ProLayout + ProDescriptions 完成。 一個頁面在開發工程中只須要關注幾個重型組件，下降心智負擔，專一於更核心的業務邏輯。

設計與樣式

在實際開發中咱們也常常會碰到一些設計問題，好比經典的按鈕應該放在左面仍是右面，查詢表單怎麼佈局，日期怎麼格式化，數字的對齊問題，在重型組件中都進行了抽象。對於各類行爲與樣式咱們都通過了設計師的討論與設計，默認好看而且好用。

感受很棒？當即使用

參與貢獻

咱們很是歡迎你的貢獻，你能夠經過如下方式和咱們一塊兒共建 🐲 ：

• 在你的公司或我的項目中使用 Ant Design Pro，umi 和 ProComponents。
• 經過 Issue 報告 bug 或進行諮詢。
• 提交 Pull Request 改進 ProComponents 的代碼。