第一部分：前端資料層的探索與實踐（一）
第二部分：前端資料層的探索與實踐（二）
契機
在使用redux的過程中，由於業務複雜度的提升，store裡面儲存的資料越來越多，通常會有多層次的巢狀和重複資料。同時在與後端互動的過程中，我們經常會討論是否要按照UI的層次結構來返回資料，結果被後端駁回，因為如果後端從資料庫中取到資料後，還要特意為前端加一層轉換，一來是考慮到伺服器壓力，二來是考慮到多裝置的時候無法複用介面。
在這樣的契機之下，我開始思考，面對複雜的應用，前端也需要處理業務邏輯，那麼資料應該如何組織和管理？
三種方案
這次我先講正規化化資料。
正規化化
所謂“正規化化”，就是資料庫設計時使用的一系列原理與技術。在講正規化之前，我們先說一下大家都不陌生的關係型資料庫，這就是應用正規化化的典型。
關係型資料庫：建立在關係模型上的資料庫。
關係模型：若干個儲存資料的二維表，每一行稱為一條記錄，每一列稱為一個欄位。表與表之間用關係來描述，有一對一/一對多/多對多三種關係。
藉此兩個概念很容易想到我們接觸得非常多的資料庫。那關係型資料庫在儲存和管理資料的時候遵循哪些原則呢，見下：
第一正規化（1NF）：表列（或稱屬性或稱欄位）具有原子性，不可再分。
第二正規化（2NF）：滿足1NF的前提下，錶行（或稱例項）必須具有唯一可以被區分的主鍵key
第三正規化（3NF）：滿足1NF&&2NF的前提下，每個表中不包含已在其他表中定義的非關鍵欄位，也就是不能有冗餘資料。
前端正規化化資料
明白了正規化化的概念與設計原則，我們以Redux應用為例，看一下我們應該怎樣設計正規化化資料，先看一個簡單的例子，我們組織資料通常是這樣：
- 每種型別的資料應該具有自己的表,
- 每張表儲存在物件中，物件中的每個元素即為一條記錄，用id作為key,資料內容作為value
- 資料A與資料B的關係通過ID來描述
這樣帶來的好處顯而易見：
- 資料更加扁平化，最多隻有一層
- 資料間的關係清晰
- 資料項是唯一的，減少冗餘
- reducer不再需要深層次巢狀處理資料
- 更新資料項時，更新只會發生在當前項，不會對引用該資料項的地方做無必要的重複渲染
- 每個元件可以connect自己的資料，無需一層一層的向下傳遞資料（可提高效能）
應用
當伺服器端把資料傳到前端的時候，我們不太可能手動的去把這些資料正規化化，好在我們已經有了很多成熟的庫，幫我們做轉化。在Redux應用中，推薦比較多的就是 Normalizr 了，這個庫主要是幫我們將資料做正規化化處理，輸出的資料可以放在state中，顯然，這樣的正規化化資料在store中進行手動處理，會非常不方便，也有這樣的庫來幫助我們解決正規化化資料在store中的問題，比如Denormalizr。但是還有一個更好的工具，Redux-ORM，它可以說是Normalizr和Denormalizr的結合（如果是vue，也有類似的工具vuex-orm）。
結束語
一直認為學習要在熟悉掌握基礎的前提下多加實踐，所以我這一部分只是講了一些正規化化的基礎概念，同時引出生態鏈中與此相關的受歡迎的庫。第二部分我將詳細講一下我的Redux-ORM實踐。歡迎小夥伴們一同探討?
參考資料：