ant Design給人的感覺就是：很強大、很龐大（雜亂）。
它號稱已經應用于多個生產項目了。或者看這里。或者看看dva官方首頁吹的牛B。
官方的dva教程只是告訴你dva/dva-cli有多好用，然后帶你做了一個用戶列表界面的展示。
接下來的思路還是先找重型的腳手架。
進入官方的awesome-ant-design先，在Boilerplates中的前四個是star數超過100的，下面分別看它們。
（【擴展：什么叫awesome？ 和 只有awesome的才是awesome的。P.S.進入了awesome列表，都是些非凡的項目。你去這個列表上看一看，都是些什么！能被這個所謂的awesome收錄，我覺得水準就是世界級的。】）
Ant-Admin
400+ stars。 Demo
特點：全面
React SPA
300+ stars。 Demo
特點：動效
React-antd-admin
180+ stars。 Demo
特點：簡單
React-redux-antd
150+ stars。No Live Demo
試用報告
前三個跑起來以后和Live Demo一毛一樣。
最后一個沒跑起來，放棄。
進入 AntD Admin
項目的package.json解讀：
關于依賴版本的定義，直接version，>,<=這種就不說了。
關鍵是^和~這種的。需要學習一下。
而依賴和dev依賴的區別也要有所了解。
看下dev依賴：
- atool ： ant封的webpack
- babel相關
- dora：配置管理
- eslint相關
- glob：路徑匹配（模糊？正則？）的node組件
- mock
- 等等
至于dependencies就比較常規了，react、ant、dva什么的。
ant-Admin項目代碼本身窺探：
- 結構比較清晰。
- 封裝度不如admin on rest。因為dva就是直接用了antd的ui組件，是組件級別而不是框架級別，dva自己也說提供的api非常少。所以我們甚至在這個腳手架里面還看到less文件。不過說起來其實也還好，因為這樣的話，我們可以自己做封裝，而且樣式也可以更靈活了。
初步體會：
相關學習資料鏈接
- DVA首頁
- 12步30分鐘完成你人生中第一個DVA應用
- 做完人生的第一步，請繼續看：DVA相關概念和課程入門
關于ant組件
總的來說非常強大，它的組件庫豐富，配置靈活，樣式也多變。我簡單試用了一下，單從展示與頁面功能上來說，適配我們的產品絕大部分功能綽綽有余。
在讀腳手架代碼時，發現一個問題，就是兩個框架在組件相關目錄文件內容組織時有些小區別：
- dva-cli的工程的做法是：routes目錄中只放幾大主要模塊的Component（其他框架也這樣做的），但是它不放樣式，只是簡單組織一下大體結構。主要的內容部分是直接引的Component目錄下的模塊組件。
- ant-admin的做法是：routes中每個主要模塊的文件寫的比較復雜，而在Component目錄中的對應目錄做的是這個模塊的部分組件，在routes目錄中的對應文件中對他們進行拼裝，而且實現了一些dispatch/action/行為，而且還會引入樣式。而在Component中，是不實現dispatch的。
- 個人竊以為dva的方式較好。當然，組件復雜的情況下，可以在dva的方式的基礎上，按ant-admin的方式拆開嘛。
當然了，在Component目錄中，做法基本是沒區別的。你定義自己的業務組件，完成對ant組件的使用。
其他區別
發現一個就列一個
結論：dva/antDesign更新快，自我迭代，因此它代表的是最佳實踐。我想后續的話，我們用其他腳手架指導和啟發我們的思路，而整體框架則沿用dva。
關于登錄認證
都SPA了，登錄認證不建議使用老的那一套。因為前后分離了，后端不應該管頁面渲染的事情。如果有個請求被拒絕了，由后端直接扔給瀏覽器一個默認的404的html，那我認為這是前后分離不徹底（同樣的，登錄頁面后端也不要管，也由前端框架來負責。）。
這不是有偏執的牛角尖狂熱癥，同時我認為后端應該轉變或者拋棄傳統的一些思路。
試想，如果我前端又開發了一個手機app版本的，界面是用原生應用生成，數據和web前端一樣，同樣是基于后端。那么，后端發現認證失敗的時候，是還扔給我404的html嗎？
因此，后端只管做好數據提供者就好，任何展示部分不要插手。如果一個后端開發人員就是想插手展示部分，請你學習一下前端開發技術，并轉型成為前端開發人員。算我求你。
前端SPA認證的基本思想，請參考這篇React SPA登錄與身份認證。
基本思想我來解讀一下：
- 請求首頁/登錄頁，不考慮認證。
- 登錄時，后端生成token，response給前端，前端保存。（后端邏輯：接受登錄請求，生成token，response出去。前端邏輯：登錄提交后，等待接受登錄的response，接收到以后成功登錄，保存token。）
- 每次數據請求時，前端在http-header中包含token。（前端邏輯：請求后端數據，并在這個請求中附帶上token）
- 后端可以根據token，決定是返回數據，還是返回拒絕信息。（后端邏輯：先判斷token，如果沒問題就返回數據了。如果不行，返回一些信息，并附帶401或者403狀態碼。）
- 前端根據狀態碼做數據展示或者路由。（前端邏輯：如果是200,201狀態碼，處理并展示數據，總之該怎樣怎樣。如果狀態碼是401或403，那就直接路由到/login，并清空之前的token就好了。）
總結：后端根據token進行認證（安全性有待討論，肯定有加固方式）。由返回碼通知前端認證結果。前端每次請求數據帶token，并且根據返回碼判斷請求成功或者被拒絕。
看似啰嗦的邏輯或者流程，其實并不難做。后端庫是成熟的。
Spring的看這里，SpringMVC的RESTful API中就帶token處理的相關類/API/注解。你只管寫好你的CRUD接口就好，認證這塊公共模塊就給你做好了啊。
前端也是成熟的。
就算是自己封一下也蠻簡單的啊。【請看一下admin-on-rest關于登錄認證的說明，加深理解】
**【TODO】繼續了解JWT的概念，并學習使用react和jwt的結合，以及相關的庫 **
關于Icon
在開發前端工程時，很多地方需要使用一些小的logo圖片。對界面美化、整體風格塑造等等方面都會有用。
主流的方式是使用一些svg等格式的矢量圖。
有沒有現成的圖片？如果有的話，我們如何引用？
當然有現成的！而且在antd admin中，對圖標使用都有現成的例子。
antd admin 直接引用了iconfont的圖標解決方案。這也是ant Design的Icon組件的圖標使用方式。
具體的使用方法是：
1.在iconfont的網站上，眾多開發者發布了非常多的免費使用的圖標庫。
2.使用者在iconfont網站上注冊一個賬號，并在自己的工作空間中創建一個項目。
3.對自己的項目生成一個在線訪問的超鏈接，這個鏈接可以是一個公開的鏈接，公網訪問，而且無需登錄也可訪問。
4.將喜歡的圖標添加到自己的項目中。
5.常規開發前端工程代碼，并在你的代碼中使用Icon組件。
6.將步驟3生成的超鏈接配置到我們的前端工程代碼中，即可在工程中用Icon組件使用步驟4中添加的所有圖標。
7.上面的步驟要求前端工程運行后必須能在線訪問iconfont。因此iconfont即是一個在線的圖標托管系統。如果需要離線使用步驟4中的所有圖標，iconfont也提供打包下載然后本地使用的解決方案。
然而，antd默認使用它的基礎在線的icon組件。每次都會在線向alicdn.com請求圖標。【TODO 如果用了本地圖標解決方案，這種事情還會發生嗎？講道理的話應該不會】
如果你的chrome裝了qq電腦管家插件，它會發生向qq.com某地址請求的事情。我搞了一會兒才搞明白是這個插件的問題。我還以為我用的js庫被企鵝廠搞了。
全局設置
utils/config.js 中可以改一些全局設置。感謝antd admin作者。
關于樣式
可參考阮神的 CSS Modules
