React Hooks 是不能替代 Redux 的

我的許多同事最近通過各種方式問同一類問題：

「如果我們開始用 hook 後，那還有必要用 redux 嗎？」

「react hook 不是讓 redux 過時了嗎？那只用 hooks 就可以做 redux 所有能做的事了吧？」

redux 的作者之一 dan abramov 曾經表達過 你可能不需要 redux 的建議。如果你本來就不需要某樣東西，那你也就不用替換它了。

如果你正在用 react，為了用起來 redux，你還得把 redux-redux 裝到你的應用裡。在專案中使用多個庫顯然會增加最終應用打包的大小，也就會增加載入應用所需的時間。因此，除非有真正的理由，你不應該使用任何庫，如 jquery，redux，mobx，甚至是 react。

當人們問起來 hook 是否能替代 redux 時，他們似乎認為得在這兩者之間做出選擇，但事實並非如此。如果你正開發的應用不需要儲存大量狀態，或者元件層次足夠簡單不需要深層次的 prop 傳遞，那麼用整個狀態管理庫方案是沒有意義的。無論是否使用 hook，應用的狀態都足夠由 react 提供的功能進行管理了。

即便你的應用需要管理乙個龐大的狀態，或者應用的層次結構如古樹的根一樣錯綜複雜，你也不一定非得使用狀態管理庫。深層次傳遞 prop 可能很麻煩，但原生的 react 已經為你提供了包含在 hook 在內的多種狀態管理的選擇，他們都能幫你把狀態管理的井井有條。redux 是乙個輕量級的庫，不過配置相對複雜，增加最終打包的體積，還需要做出各種權衡取捨。不在專案中使用 redux 有許多合理的理由，所以你並不總是需要用它。

雖然如此，我們還是有許多理由使用 redux。如果你的專案本來就在用 redux，那最開始決定使用 redux 應該是有一些好的理由的，比如專案的組織架構需要有乙個可**的，單一事實**的程式狀態；中介軟體功能；或是強大的開發除錯工具。如果你曾有理由使用 redux，那 hook 並不會讓你的這些理由失效。如果你曾需要用 redux，那你也許還得繼續用它。

redux 是乙個狀態管理庫。hooks 是最近才加入 react 的新功能，它可以讓函式元件支援曾經只在 class 元件中支援的特性。

那麼，用函式元件替換 class 元件實現 react 應用會讓狀態管理庫過時嗎？答案是否定的。

關於為何開發 react hook， 官方文件 給出了三個主要原因：

你可以注意到這些動機都跟狀態管理無關。

話雖如此，react hook 確實為你提供了狀態管理的新選擇。值得注意的是，usestate，usereducer 和 usecontext 這些管理狀態的新方法，一定程度上比之前 react 原生提供的方案更好、更有條理。但 react hook 沒有提供超出之前 react 版本的新能力，也不會讓狀態管理庫過時。

react hook 不會使 react 應用做任何它以前做不到的事

沒錯，函式元件可以做到以前只有在 class 元件才能實現的功能，同時函式元件有更好的**組織結構和重用能力，但函式元件做不到 class 元件也做不到的事。react hook 的目的不是為了讓應用更好，而是為了讓開發體驗更好。

usestate 和 usereducer 只是管理元件狀態的方法，其工作方式與 class 元件中的 this.state 和 this.setstate 工作方式的大致相同。對於深層傳遞 prop 的問題，hook 也是無能為力。

人們似乎認為 usecontext 可以把 redux 打入冷宮，因為你可以使用它解決狀態深層次傳遞的問題，但它確實不是什麼新功能。 context api 已經存在於 react 一段時間了。usecontext 只是讓你可以不通過 包裝元件就能使用 context。雖然有些開發人員選擇使用 context 管理整個應用的狀態，但 context 的設計初衷不是如此。官方文件提到：

context 設計目的是為了共享那些對於乙個元件樹而言是「全域性」的資料，例如當前認證的使用者、主題或首選語言。

換句話說，放在 context 中的資料不應該經常更新。

文件還建議要謹慎使用 context，因為「它會讓**復用變得更困難「。他們還警告開發人員，如果使用不當，context 還會導致不必要的重新渲染。

我見到過一些專案成功使用 react context 管理整個應用的狀態。理論上這確實是一種選擇。但 context 的設計初衷並不包含狀態管理，而這是 redux 或是其他狀態管理庫的設計目的。

此外，react hook 絕對不意味著 redux 的滅亡，如果你瞅一眼 react-redux 最近更新的文件，你會看到：

沒錯，react hook 有助於重振 react-redux 庫，並移除了一些它的痛點。這與「hook 會替代 redux」這個觀點相去甚遠。

我在另一篇文章深入介紹了 react-redux 中的 hook 。在引入 hook 之前，你必須定義 mapstatetoprops 與 mapdispatchtoprops 函式、並用 connect 函式包裝你的元件來建立出乙個高階元件。該高階元件會把 dispatch 函式與 redux store 的一部分狀態通過你定義的對映函式作為 props，傳到被 conntext 包裝的元件中。

我們來看個非常簡單的計數器應用示例（實際上因為過於太簡單不必使用 redux，但這個例子是為了表達一下資訊的概述）。假設我們已經定義了 redux store，並在其他地方定義了增加和減少的動作建立方法。

真是繁瑣。如果我們可以不用把元件包裝在高階元件內就能讓元件訪問到 redux store，不更好嗎？沒錯，這就是 hook 可以發揮的地方了。hook 其主要功能就是**復用，同時消除高階元件導致的「包裝地獄」問題。

簡而言之，useselector 允許你將 redux store 的各個狀態切片儲存為元件的變數。usedispatch 非常簡單，你可以通過它發出動作更新 redux store。最重要的是，你不再需要實現醜陋的對映函式，並把元件包裝在 connect 函式中了。現在，一切都很好的包含在你的元件裡。這樣的實現更簡短，也就更具有可讀性、更有條理。

顯然，這兩種技術可以相互補充。react hook 不會「替換 redux」，它只是為你提供了更新、也許更好的方式組織你的 react 應用；如果你最終決定使用 redux 管理應用狀態，也許能寫出更高內聚的元件。

所以，請不要再問 "react hook 是否取代了 redux？" 的問題了。

相反，請問一下自己：「我在開發怎樣的應用？我需要怎麼樣的狀態管理需求？redux 是否對我來說是合理的方案，或者它對於我的需求過度複雜了？如果我決定使用 redux 和 react hook（或是 mobx+hook, redux+jquery 等技術組合）我怎樣才能讓這些技術相互補充，和諧工作呢？」

英文原文：

React Hooks 是不能替代 Redux 的

我的許多同事最近通過各種方式問同一類問題 如果我們開始用 hook 後，那還有必要用 redux 嗎？react hook 不是讓 redux 過時了嗎？那只用 hooks 就可以做 redux 所有能做的事了吧？隨便搜一下 google，你就會發現人們也在網際網路上問同樣的問題。簡單來說，reac...

可能是你見過最好的 React Hooks 庫

ahooks 1 是由螞蟻 umi 團隊 淘系 ice 團隊以及阿里體育團隊共同建設的 react hooks 工具庫。ahooks 基於 react hooks 的邏輯封裝能力，提供了大量常見好用的 hooks，可以極大降低 複雜度，提公升開發效率。ahooks 致力成為和 antd fusion...

lvs為何不能完全替代DNS輪詢

任何一台機器掛了，服務受不受影響 能否通過增加機器，擴充系統的效能 反向 負載均衡 請求是否均勻分攤到後端的操作單元執行 nginx 乙個高效能的web server和實施反向 的軟體 lvs linux virtual server，使用集群技術，實現在 linux作業系統層面 的乙個高效能 高可...