衆所周知React只負責UI的展示，但是數據控制和數據模式也是逃脫不掉的，總是需要自己去實現，總得來說也就那三種方式，在以前的文章中有介紹，但我個人認爲還是Redux來的高級點，至少可以採用一個全新的JS實現方式，也值得我們去嘗試，Redux採用的是單一數據源，在數據展示時，存在各種不同的展示需求，必然會有不同數據在同一頁面展示，不同頁面展示同一數據的情況，那麼在數據的更新時，也就必然存在不一致，不同步的情況，如何構建一個扁平化的數據結構來適應這種需求呢？weixin公衆號：（React實戰）
在實際項目開發中，我們往往的經歷是：隨意性開發->重構->規範化設計，但是理想往往屈服於現實，重構和重新設計的成本總是巨大的，所以每個軟件項目都是一個遺憾的缺陷品。解決這種狀況的最好辦法是採用成熟的設計方法和設計模式。
在初識Redux時，我是連它這種方式都不認可的，採用單一的數據源，想想就瘋狂，在開發過程中，我們知道會涉及太多的需要展示的數據，壓根不會想這種方式，但別人就這麼幹了，目前看還有大批的擁護者，當然以老外居多。既然採用單一數據源，開篇的問題也就來了，如何構建滿足Redux的數據源？一般來說可以採用兩種方式：一種是獨立數據模型，一種是共享數據模型。
1.獨立數據模型
所謂獨立數據模型就是我們每個組件內的數據獨立維護，例如人員列表組件包括人員列表、人員數據統計等，其所對應的數據模型獨立的佔據着Redux數據模型的一個獨立分支，數據的讀取，轉化和更新均取自自身對於的獨立數據模型分支，這樣也就解決了數據共享帶來的問題。
2.共享數據模型
共享數據模型是採用Redux類似的數據模型思想，將數據模型同一規劃，系統所有頁面均基於同一個Redux數據模型。那麼如何解決數據同步問題呢？我們採用關係數據庫的原理，數據模型採用扁平化，數據實體間的關聯採用ID，而不是具體的數據實體信息，以人員列表舉例說明：人員列表包括：人員列表信息，每個人員信息。在常用的列表中是直接裝載了人員信息，現在則不是，而是隻裝載人員ID。
原始人員列表信息json表示：
persons:[
{id:1,name:’p1’,age:18},
{id:2,name:’p2’,age:13},
{id:3,name:’p3’,age:14},
{id:4,name:’p4’,age:15}
....]
共享數據模型人員列表信息json表示：
{
Persons:{
‘1’：{name:’p1’,age:18},
‘2’：{name:’p2’,age:20},
‘3’：{name:’p3’,age:13},
}，
list:[‘1’,’2’,’3’]
}。
從上面的數據結構就可以看出共享數據模型採用的是關係數據庫思想，列表中並沒有數據實體，如果單個實體信息變化，並不影響其其它關聯數據。但是正如中文換成英文一樣，當你採用一種新的表達方式，隨之而來將帶來新的數據處理方式的變化，甚至有些讓你很不習慣，如列表顯示不再直接讀取，而是需要做一些轉變，如id爲1的person信息：
獨立數據模型：list[0].
共享數據模型：persons[list[0]].
除此之外還有一些另外的操作，包括：查詢數據轉換、數據更新操作等。你可以自己實現，也可以採用第三方庫實現，如：Normalizr庫。
正如我之前所說，理想和現實總是有差距的，在初入Redux時，一般還是採用獨立數據模型爲好，這樣更利於獨立開發。共享數據模型看起來很美，但需要較好的前期規劃，並且開發成本也更高，量力而行吧。
。