1樓：
最近在使用redux-observable，具體這種流式程式設計配合redux非常的完美，最佳實踐可以看一下 redux-obervable的官方示例 redux-observable/redux-observable
2樓：hapood
我來安利一波我們的最佳實踐。
redux會將所有元件的state全部都扔進乙個大的state中去維護，每次reducer只會更新一小部分。這要求開發者要自行構建良好的state組織結構，否則當頁面元件越來越多時，很容易被乙個超級大的state繞暈。
我們現在在專案中使用了redux-arena,它可以將redux與react打包成乙個模組載入，如果react元件被解除安裝，那麼react元件在redux中的state/reducer/saga都會被自動解除安裝，徹底解決state樹和reducer過於龐大的問題。
一張gif圖說明redux-arena做了什麼，如下圖所示，當切換pageA和asyncPageB的掛載和解除安裝，會觸發redux中全域性state樹的改變，所有與當前頁面展示無關的state和reducer徹底不復存在，你看到的state一定是當前被掛載的元件的state，極大地提公升了state的可讀性。
還有一篇相關介紹在這裡：https://
zhuanlan /p/28690716
3樓：王小一
我認為只從頂層傳入資料的做法太複雜了。
如果子孫很多，那麼頂層要接入十幾二十個資料，然後一層層分發下去，思考負擔很重，對可讀性，可維護性，都是一種損害。
應該讓元件和資料是一一對應的關係，每個元件自己接入想要的資料。這會導致多寫一些重複邏輯，沒關係，抽出公共方法就行了。總比一層層傳props方便。
這樣也導致介入點很多，介入點很多會造成混亂嗎？我認為不會，只要資料和元件是一一對應的，就不會混亂。混亂來於資料歸屬不清晰。
4樓：alcat2008-洋
仔細閱讀 Redux 官方裡的乙個 issue，集思廣益，不過就是略長。
Recommendations for best practices regarding action-creators, reducers, and selectors · Issue #1171 · reactjs/redux · GitHub
5樓：yangli
1. 當建立action的時候，如果按照官方的做法會寫很多，你可以試試redux-action之類的庫，其實就是語法糖。
2. 可以找乙個middleware來做async的操作，redux promise之類的，然後也可以再封裝一層middleware，fetch_start之類的操作可以不用寫了，然後在後面直接監聽completed操作。當然，靈活性會差一些，大多數時候還是比較有用。
也可以直接上redux-saga處理複雜的控制流。
3. redux的還有乙個優勢是做統計方面的需求很簡單，直接加個middleware，然後發統計資訊就行了，大概就和redux-logger這樣的差不多，簡單輕鬆。
4. 結合react的一些特性使用，willReceiveProps裡面判斷是不是re-rendering，會減少一些需要一些順序執行actions的情況。
5. connect的時候根據元件來connect，這樣會好維護一點，別從頂層直接什麼都扔乙個component裡面。
6. form使用 redux-form， 這樣可以抽離form元件，其實和5是乙個意思，就是是有個開源庫做了form表單元件。
7. redux裡面貌似是少有區域性的，大多數時候少用setState還是對的，但是也不一定。總體來說區域性狀態是用state還是處理到state tree上，只能說看情況，跟外部的關係相關。
如果和外部某些關係比較強，做在state tree上，如果是外部不可見，最好state。
6樓：body no
這裡不多說了
還是這個個人覺得最牛的腳手架
GitHub - bodyno/react-starter-kit: 完美使用 React, Redux, and React-Router！最好用的腳手架
看原始碼的時候要仔細
收穫肯定是很大的
7樓：jason濤
自己做的專案用過redux。最佳實踐是除非你只做1版，要不就不要用。
嘗試過後的結論，寧用flux也別用redux。迭代的太快了，version 各種變。更不要提裡面一堆概念了，想法是好的，敢不敢穩定點。
8樓：
2. 根據你的需求，選擇middleware (thunk vs saga?...)
4. 關於檔案的結構，小專案用型別分類，大專案用feature分類
5. 區分smart component (know the state) 和 dump component (stateless)
6. component裡不要出現任何async calls，交給action creator來做
7. reducer盡量簡單，複雜的交給action creator
8. reducer裡return新state的時候：
// add new item to state array
// bad and does not work
case "ADD":
return state.push(newItem);
// Good
case "ADD":
returnstatenewItem
];// delete new item to state array
// bad and does not work
case "DELETE":
return state.splice(index, 1);
// Good
case "DELETE":
return state.slice(0, index).concat(state.slice(index + 1));
// update new item to state array
// First way
case "EDIT":
return state.slice(0, indexconcat([{id: "id", value: "newValue"slice(index + 1);
// Second way
case "EDIT":
return state.map((item) =>if (item.id === "id"returnitemvalue: "newValue"elsereturn item
9. action creator裡，用promise/async/await以及redux-thunk來幫助你完成想要的功能
10. 在test裡不管你用tape還是mocha，請用http://
airbnb.io/enzyme/
11. 有些時候有些專案你並不需要redux
洗手間整理收納有哪些最佳實踐？
小燕子 我的衛生間因為初始不是自己裝修的，所有格局已經無法改變，但是通過最近的整理我進行了收納的規劃，不知道能否給你幫助。添置了乙個五層的收納箱 最下面開始依次收納 洗衣液 柔順劑，消毒液 牙刷，香皂，牙膏等衛浴用品 衛生巾 坐便墊等 吹風機 在坐便上的置物架，放了衛生紙，基本收納了所有衛浴用品。見...
Java並發包最佳實踐是什麼？
clerk 要啥並發包，要啥自行車，fork join map reduce 非同步框架等一大堆，我覺得普通開發者直接使用並發包的場景不多 toruneko 我想要在併發環境下測試乙個balancer，如果不用barrier，我可能得不到相對公平的競爭，甚至原本需要競爭的執行緒，是按照順序執行的。另...
Redis 在 SNS 類應用中的最佳實踐有哪些？
李亞龍 量不大的情況下，可以用來存多終端的漫遊訊息，價效比非常高。可以根據活躍使用者數和訊息量的統計分布，動態調整單使用者的會話數上限和單會話的訊息條數上限。資料不需要持久化，當然在記憶體裡直接放訊息內容也要注意安全。 Gary Chen 海量 and 高效能應用 參考 http 劉曉慶 1.訊息佇...