1樓：kobe gor
是否扁平化這個是建立在業務的複雜度的基礎上，之前開始設計store的時候也糾結是否扁平化的越多越好，最後是根據業務、UI、驗證分別對應不同的Object。這樣設計目前沒有啥大問題，這個就要需要在實踐中不斷的糾正。
2樓：於冬
這個東西主要看專案規模和開發周期來決定吧
小專案短平快就貼合ui做資料
大專案長週期就盡量把資料組織的規範一些以利於後期維護
3樓：
偏向展示的，用巢狀吧，迴圈方便。
如果有更新需求，建議用正規化化展平，不然redux的reducer很難寫。或者乾脆別有redux，用mobx就好了。
4樓：王德福
好吧蟹妖~
關於 store 如何組織的問題，其實本質是資料如何組織的問題，這個問題的答案你當然不可能在前端的書籍和文章中找到答案，朋友你需要一本
資料庫系統概論（第5版） (豆瓣)
哈哈哈，看我認真臉...
@Lucas HC 提到了正規化化，而正規化是資料庫理論的基礎知識。資料結構是否合理，是否冗餘，都可以通過正規化的方式檢驗。如果不是計算機專業的盆友，不妨找本大學教材看看。
大學教材這個東西，無論如何你都可以在乙個禮拜之內看懂60%。
然後你就發現你困惑的事情，在幾十年前就有人意識到，並且給出了解決理論。
關於前端資料的組織，我們能想到的乙個極端就是完全按照表結構來做，完全扁平，通過外來鍵連線,在業務層進行拉取組裝。
另乙個極端則是前端資料層和 UI 完全對應，也就是說把邏輯耦合進了資料結構中，你把整顆樹畫出來就是個低配版的網頁了。
不管怎麼說，後端的資料層才是真正的資料層，前端的資料都是中間層，這個中間層裡面你想摻多少的業務邏輯都看個人喜好了，你可以一棵樹直接全都搞定，也可以在前端做資料和業務分離。
我的感覺來說，如果專案不大，也不涉及資料間複雜的計算依賴關係，前端資料層更貼合 UI 會用起來比較方便。如果內容太多，那還是做純粹一點的介面，畢竟有非常成熟的資料庫理論可以給你提供支援。
前端資料層更貼合 UI 會用起來比較方便，但是我們也需要給工程化讓步，這種資料冗餘是否是對專案有害，要看資料和專案的規模。
直覺來說就是，你覺得資料怎麼冗餘這麼多，巢狀這麼多，我不開心了，那就拆平一點。反正你們讚不讚我都已經申請了...【live 預告】前端資料管理與前端框架選擇
p.s. @知乎小管家 感謝提醒，順便說一下，你們能不能管一管那個發"前端是一門技術，也是一門美麗的藝術"的團夥啊...
5樓：
一般原則是扁平化。但也取決於需求，如果資料源頭就是乙個複雜的tree，沒有必要為了刻意扁平化而再轉換資料。
combineReducers用得比較多。有當成namespace來用的傾向。
6樓：冰淤
以modules，namespace，樹狀結構來劃分，都是乙個意思。建議不要扁平化。
至於取資料時字串的長短，我感覺這都無所謂，專案大到這個地步，可讀性更重要。
以UI還是業務劃分，不同場景下不一樣，視情況而定。
什麼是扁平化設計 Flat Design ，扁平化設計是未來的趨勢嗎？
shadow.Chi 現在的趨勢是semi flat designhttp Hugo Flat Design 是一種極簡主義風格，和擬物化 Skeuomorph 設計理念相左，基本上拋棄了所有 3D 效果，而重心放在簡單化的元素 字型形態以及 扁平 的顏色 大意就是去掉漸變和裝飾 上 如 Lambi...
主流UI設計風格由擬物化向扁平化的轉變，是否減輕了UI設計師的工作量？或者說對設計師的工作有何影響？
小鹿 減輕了你的工作量，也縮短了你的職業壽命。UI 設計行業作為網際網路行業的乙個熱門職位，本身就存在著激烈的競爭，扁平風格的盛行，降低了 UI 設計師在產品設計團隊中的價值和話語權，就是給線框圖填個色，這誰都能做 已經有很多互動設計師在兼職做 UI 設計的工作了。同時，也降低了行業的門檻，會有更多...
文字比較多的PPT，如何做出扁平化效果？
rryu 我覺得題主先消化再提煉重點的做法很對。補充一點，有一種PPT不是用來宣講而是發給領導閱讀的，這種多字的PPT可以參考一些內容相近的雜誌或者畫報來設計。重點是分段，提煉重點列條。樣式上，正文段落找適合閱讀的字型，字型大小，行距和內容有關的配圖。 想做出好的ppt，和扁平化沒啥關係。做pres...