關於React，近期工做中項目的一點小體驗

背景

最近一直都在作一個管理後臺的重寫，原項目是.net 4.x + layui作的一個SPA應用，暫不談後臺和數據庫（談的話又有好多要吐槽的了），單單從React開發的角度上來談本身經歷的問題吧。

這篇水文就不從特別技術的角度來說，react、redux什麼的用法就不涉及了，更多的是最近的代碼組織的一點總結。還但願可以有大佬能指點一下，react開發到底如何組織。

數據管理

常見的React技術棧就是React+Redux，其中還涉及有redux-thunk和react-redux，由於傳統的react單向數據流在組件交互頻繁且組件嵌套過深的狀況下數據傳遞效率很低，因此引入redux這樣的解決方案做爲數據集中管理的場所，便於數據交互。

最初個人使用中很天然的選用react+redux做爲解決方案，可是後續的問題也產生了，首先，組件的數據交互並無那麼複雜，假設組件交互要跨過中間一個組件，那麼引入redux是有必定必要性的，可是，若是組件的交互是徹底是父子關係，那麼redux反而會拖累開發的節奏和流暢行。

而後就是，redux+redux-thunk解決方案在項目代碼項目文件的組織上相對繁瑣，若是使用redux-thunk，除了你正常使用redux要使用的：一個actionType文件用於定義action信息、一個actions文件經過參數構造action、一個reducer用於根據action對state進行處理（state通常也在這個文件裏），你還要在action中定義thunk-action，也就是說針對一個請求的action，一般狀況下你須要寫一個觸發的thunk-action和三個請求狀態action分別是start、success和fail，固然在項目小的時候，代碼還不至於難以管理，可是當項目逐步增大的時候，對項目結構的設計和劃分就變得異常重要，由於當不正常劃分時，很容易出現一個文件裏有幾百行的action信息、action構造函數和reducer的switch-case。

還有一個問題就是connect組件問題，使用react-redux的connect方法能夠有效的鏈接基礎組建與業務state、action，可是不要過於依賴這樣的方式，最優的方法仍然是原始的組件見的交互，當試着去對基礎組件使用connect接入redux時，本來的數據交互邏輯從主組件向基礎組件滑坡，最終致使不得不去在維護主組件邏輯的同時經過action影響state去控制基礎組件，這樣在多個文件中切換（主組件、actionType、actions、reducer）很容易出現失誤。

上面的問題我目前的總結就是兩點：

1.能不用redux儘可能不用redux進行數據管理，固然這個值根據項目的實際數據交互程度而定的

2.合理劃分文件目錄結構，必定要在開發前作到心中有數，通常來講數據交互不頻繁的就拆成不一樣的reducer，同一個reducer內action和action-handle過多的狀況下就根據組建拆分紅不一樣的文件，最後只要把全部的文件經過import整合成一個文件去處理就行了，這樣有利於在開發中action和調用action組建的定位。

3.項目的組件鏈接儘可能使用原始的方式，而不要接入redux。而redux的接入通常在模塊的層級上接入。這樣能有效的避免因redux充斥項目而致使開發中邏輯隨意流竄而理清邏輯須要在多個文件中跳轉而引起的效率低下問題。

4.能夠考慮使用redux-actions等輔助庫來減輕action和reducer代碼的繁瑣

目錄結構

如下是我採用的目錄結構

├── src
│   ├── Bcomponent      //業務組建
│   ├── common      //通用內容
│   ├── components      //基礎組件
│   ├── pages           //頁面
│   │   ├── batch       //業務模塊
│   │   ├── commonTool
│   │   └── project 
│   │       ├── landProject     //業務頁面
│   │       │   ├── coordinates         //頁面的獨立組件
│   │       │   ├── detail
│   │       │   ├── docs
│   │       │   ├── mapperview      //每一個獨立組件下都有本身的action和reducer代碼文件方便查找
│   │       │   ├── measureplan
│   │       │   ├── pdfViewer
│   │       │   ├── _redux          //業務頁面的redux相關內容
│   │       │   ├── villageeditor
│   │       │   └── villagelist
│   │       ├── minutes
│   │       │   ├── minutesDetail
│   │       │   └── _redux
│   ├── redux           //全局redux
│   │   ├── common
│   │   ├── commonSaga
│   │   ├── saga
│   │   └── store
複製代碼

在目錄結構設計上必定要下工夫，合理的設計目錄結構對開發的思路理清至關重要

組件設計

react開發最重要的就是組件的開發與使用，在我兩三個月的智障操做下，我認爲組件的開發應該保證這樣的特性：

1. 組件不該負責過多的業務要求，一個組件須要的是在特定的狀況下方便複用，而涉及過多的業務需求在複用層面上顯然是不方便的，舉個例子連選輸入獲取市縣街道，我我的認爲最好的方法是編寫基礎連選組件，而後針對業務你能夠在業務組件層對基礎組件進行進一步包裝，切記開發基礎組件時抱着一步到位的想法。
2. 組件的配置應儘可能簡潔，這點很難去量化，什麼是簡潔根據組件的使用狀況有明顯不一樣，可是，若是當你使用組件時你須要配置不少不少的props，那麼就是不簡潔。是連選框組件，它有已經存在列表下的連選和須要動態獲取的連選，那麼不須要非得讓組件同時能夠知足兩種狀況的配置，把動態獲取放在組件外，這樣組件保證小而美也不會在從新看代碼時腦袋疼。
3. 組件的狀態，基礎組件內狀態不該該涉及到業務，這是爲了組件複用，若是須要將業務包裝在組件內最好仍是經過業務組件對基礎組件進行包裝來達到複用。引入一層業務組件是一個很好的實踐，它可以保證你的邏輯有效的分散又不至於亂流竄。
4. 組件/頁面的模式。個人此次開發中碰到的最頭疼的問題的就是組件的模式，一個簡單的窗體頁面，它要涉及到展現、編輯、新增、校覈和審覈等幾個模式。我在開發時選擇的是同一個組件添加多個模式的狀態，可是到最後一個頁面代碼和邏輯膨脹到本身都難以處理的程度，我感受這絕對不是一個正確的解決方案，可是目前沒有明確的解決方案，只是認爲應該把這樣的頁面分離開。我認爲新版的react hooks可能會更好的解決這個問題，因此暫時很少說了。

代碼問題

項目開發中代碼要保證合理的封裝，而且保證代碼的整潔。這一點我後續也要深刻研究《重構》這本書。

目前個人我的總結簡單的就是這麼幾個方面：

1. 代碼分類，好比說轉化狀態成jsx的代碼，那麼就放在一塊兒，而後給一個「命名空間」好比說叫transition。
2. 合理封裝，一個對象若是涉及到對它的操做並返回一個結果，那麼把它封裝成類就很好，好比我業務中遇到的附件上傳，一個附件類至少須要有附件名、服務器名、路徑、上傳狀態，同時，若是是新上傳的文件預覽須要轉成base64而後再預覽，所以一個toBase64方法就可有放在附件類裏而不須要做爲簡單的一個方法。

先後端鏈接

一個項目的先後端數據傳輸格式必定要協調好，不然有你受的（大哭）。若是請求出錯了，後端必定要返回一個錯誤碼附加錯誤內容，是一個200 ok + 錯誤內容string簡直要死了，前端不得很少寫一個string的錯誤判斷。

另外，若是你的業務是一個傻*的後臺，在先後數據交換沒法優化的狀況下，那麼請放棄對前端的任何深刻重構吧，它絕對會浪費你的青春

寫在最後

一個項目最重要的是防止其逐步腐爛，拯救一個被Green Day感染的項目（jojo梗）簡直讓人崩潰，並且最重要的是公司的狀況，我如今反對任何盲目的重構和重寫，若是想作這個事情，首先要對公司有一個明確的認識，狀況是否容許作，並且老闆是否對這件事情高度關注（口頭說不算，要看他對業務的計劃和本人的狀況）。好了就這麼多，發發牢騷，還得繼續從坑裏面爬出來，真難受。

寫完一點都不想從新排版，心累