標籤：

redux 有什麼缺點？

02-23

公司在用自己的虛擬dom 框架，但是我覺得沒有一個類似redux的框架管理狀態，不一定是一個好的選擇。但是周圍幾個前段大神都覺得redux有致命缺點，但從我的角度真的沒有找出什麼缺點，求知乎里的前段大神指點。

謝邀，這是一個很好的問題。

即便很多 「Redux」 死忠或者 「Dan Abramov」 腦殘粉，回答到 Redux 缺點時，也一定能夠客觀：因為技術的歸技術，真正的缺點永遠無法被掩蓋。

但是我認為：對於任何技術設計、思想框架，與其說他們的優缺點，不如用「適合不適合」某類場景來表達更加準確、客觀。

事實上，優缺點會隨著業務場景而動態變化。所謂「甲之蜜糖，乙之砒霜」，脫離實際場景談優缺點是毫無意義的。對於 A 的業務，Redux 完美契合，對於 B 的產品，也許就是桎梏枷鎖。

所以下文，主要回答 Redux 的限制或 tradeoffs，原諒我無法使用「缺點」來表達。

其實，Dan Abramov 很早就提到過 「You might not need Redux」，文中提到了 Redux 的限制。他也說過 「Try Mobx」 這種「打臉」行為。歸納一下，Redux 的限制主要體現在：

  • Redux 帶來了函數式編程、不可變性思想等等，為了配合這些理念，開發者必須要寫很多「模式代碼（boilerplate）」，繁瑣以及重複是開發者不願意容忍的。當然也有很多 hack 旨在減少 boilerplate，但目前階段，可以說 Redux 天生就附著繁瑣；
  • 使用 Redux，那麼你的應用就要用 objects 或者 arrays 描述狀態；OMG！
  • 使用 Redux，那麼你的應用就要使用 plain objects 即 actions ，來描述變化；OMG！
  • 使用 Redux，那麼你的應用就要使用純函數去處理變化；OMG！
  • 應用中，狀態很多都要抽象到 store，那麼何時使用 local states 何時接入 Redux store？
  • 不能痛痛快快地寫業務，一個變化就要對應編寫 action（action creator），reducer 等等；
  • 和響應式結合函數式的 Mobx 相比，編程體驗「打折扣」

我在額外追加一條：

Redux 可以理解為一個簡易的發布訂閱系統。那麼因此帶來的內存消費也許會大一丟丟。

以上種種限制，都不是構建一個應用所必要的。而全部都是 Redux 所強加的，那麼這樣好嗎？

對於很多應用，是沒必要的。但是對於另外一些場景，這些限制也都會轉化成閃光之處，缺點彷彿又成了優點，包括且不限於：

  • 便於調試，具體不再展開；
  • 便於線上錯誤收集，只需要發送 states, actions 等快照即可；
  • 結合 localStorage 初始化 store；
  • 便於服務端渲染；
  • 開發在線協作型應用的救命解藥；
  • 時光旅行 Undo／Redo；
  • 便於測試

看個場景吧（取自 Dan Abramov, 沒耐心看可直接看結尾總結），一個簡單的計數使用基本 React：

import React, { Component } from react;

class Counter extends Component {
state = { value: 0 };

increment = () =&> {
this.setState(prevState =&> ({
value: prevState.value + 1
}));
};

decrement = () =&> {
this.setState(prevState =&> ({
value: prevState.value - 1
}));
};

render() {
return (
&
{this.state.value}
&

※react配合redux的生命周期(shouldComponentUpdate)的問題？
※揭秘Redux（1）： 自動機
※redux 中的 state 樹太大會不會有性能問題？

TAG:Redux |