1樓：兒蔥
redux 理解成本會比較高，本來比較簡單的單項資料流模型，同時高複雜度的元件我認為是不適合redux 的，主要是渲染更新效能不好控制。
2樓：哇塞田
瀉藥,給你說乙個事情,我們之前有乙個新來的實習生,又一次實習生開始寫我們的業務的時候要用到redux,然後那個實習生寫完了以後問我:"不就是改個狀態麼?為什麼要這麼麻煩,要有reducer,要有store等等..."
3樓：「已登出」
加乙個有點像抖機靈的回答吧。
redux最大的缺陷其實是它不應該這麼火，或者說不應該由它來火起來。
如果是某些整合了redux，非同步管理和immutable等功能的框架來負責火起來，而redux作為基礎庫來支撐它們，就比較容易接受了。
雖然造輪子的確有趣，但是實際上一線的開發可不需要什麼百花齊放的輪子……而redux的功能卻太單一了。
如果乙個庫被用來做狀態管理，我可能就更希望它能完整地hold住這件事情。而不是留下一大堆非同步誰來處理，state物件的不變性怎樣保證這類緊密相關的問題就給我來處理……
不是因為我不想動腦子，而是因為乙個庫不能自己處理這些問題卻又流行起來的話，市面上過一段時間就會出現十幾數十個奇奇怪怪的方案來處理這個問題……
你自己寫久了然後決定根據經驗封裝乙個，然後下個專案想換某個據說流行的腳手架，發現腳手架用了另外乙個。然後過一段時間社群告訴你，那個腳手架的方案也涼了，現在流行的是另外乙個。
……得了吧，您可別鬧了，等我搞明白到底該用啥庫時黃花菜都涼了。
實話實說，react+自己用類寫狀態管理+rxjs，大部分專案夠用了，專案沒複雜到那個份上之前，何必閒的沒事為難自己呢。
4樓：Larry
不能說是缺點吧，不過很多人吐槽的點倒是有：
1.繁瑣。
2.store設計，過於扁平化不好管理，但是樹結構過深修改麻煩，需要一定的經驗。
try mobx。
5樓：Kian
目前自己用了這麼久，感覺redux還有有一些缺點，首先，你要不停的connect元件，如果專案大規模使用redux的話，需要對資料結構進行構建專案前的模擬，不然哪些資料該存在store裡哪些存了反而會麻煩。 其次，你不能吧redux當作乙個任何資料都可以存的快取區，因為最重要一點是每當你reload頁面的時候，你所有存在store裡的資料都會被清空，所以一些需要長久儲存的資料比如token，你還是需要放在localStorage裡。 總之，redux是乙個解決react資料流通的利器，解決了很多痛點，但是要清楚它不是萬能的就行了。
Redux有哪些最佳實踐
最近在使用redux observable，具體這種流式程式設計配合redux非常的完美，最佳實踐可以看一下 redux obervable的官方示例 redux observable redux observable hapood 我來安利一波我們的最佳實踐。redux會將所有元件的state全部...
為什麼 Redux 會這麼火？
多年來，前端工程師忍辱負重，操著賣白粉的心，賺著買白菜的錢，一直處於程式設計師鄙視鏈的底層 於是有大牛就把後端 MVC 的開發思維搬到前端，將應用中所有的動作與狀態都統一管理，讓一切有據可循 使用 Redux，借助 Redux DevTools 可以實現出 華麗如時光旅行一般的除錯效果 實際上就是開...
USB Type C 有什麼缺點
衍x usb全稱通用序列匯流排，通用就說明了他支援的協議，裝置型別繁雜多樣，usb c也是一樣的，它作為一種物理介面，繼承了usb b的電氣單向性 就是能定義電流只從裝置a傳輸到裝置b，usb a是不存在這個功能的 同時也為更多協議的支援做了物理基礎 線更多了 缺點就在於物理介面支援，但是，協議的支...