語言的魔力是咒語，芝麻開門，等等，但是在一個故事里的咒語在下一個故事里就沒有魔力了。真正的神奇之處在于懂得哪些詞語，什么時候起作用，為什么起作用;訣竅在于學會訣竅。

自從在React 16.8中正式穩(wěn)定了鉤子已經(jīng)有一段時間了，伴隨它們而來的是一種完全不同的理解我們應用程序工作方式的方式。這既是一件好事，也是一件壞事:鉤子更接近于React編程模型，有助于避免某些微妙而令人困惑的bug，但一些開發(fā)人員也擔心React會成為一個黑盒子。這些擔憂完全有道理;鉤子通?？雌饋砗?ldquo;神奇”，因為大多數(shù)復雜性都隱藏在React的內(nèi)部。

這種“神奇”的感覺主要是因為hook是基于一些現(xiàn)有技術和編程語言研究，而許多開發(fā)人員只是不熟悉。理解hook的一些動機和靈感可以幫助建立一個心理模型來了解幕后發(fā)生了什么。雖然有幾個來源的影響，最初的鉤子建議，可以說最重要的是代數(shù)效應的概念。

注意,本文不介紹如何使用鉤子或內(nèi)部鉤子是如何工作的。這只是考慮鉤子的一種方式。關于如何使用它們的更多信息，我建議從文檔開始。

在深入研究代數(shù)效應的細節(jié)之前，讓我們先退一步。

我們?yōu)槭裁葱枰^子?

類組件似乎工作得很好，為什么要添加另一種編寫組件的方式，至少表面上，做同樣的事情?

React的核心原則之一是，應用程序的用戶界面純粹是應用程序狀態(tài)的函數(shù)。這里，“state”可以指本地組件狀態(tài)和全局狀態(tài)的任何組合，比如Redux存儲。當狀態(tài)更改并通過組件樹傳播時，輸出表示狀態(tài)更改后的新UI。當然，這是對實際更新如何發(fā)生的具體細節(jié)的抽象，因為React處理實際的協(xié)調(diào)和必要的DOM更新，但這個核心原則意味著，至少在理論上，我們的UI總是與數(shù)據(jù)同步的。

當然，這并不總是正確的。類組件暴露了某些場景，如果我們不能在生命周期方法中有效地處理這些狀態(tài)更改，這些場景允許我們忽略狀態(tài)更改。丹·阿布拉莫夫(Dan Abramov)寫了一篇關于與此相關的常見陷阱的優(yōu)秀文章，值得一讀以了解更多細節(jié)。簡而言之，類組件使用不同的生命周期方法來處理副作用，但這將副作用映射到DOM操作，而不是狀態(tài)更改。這意味著，雖然UI的可視化元素可能會響應狀態(tài)更改，但副作用可能不會。

 因為類組件必須做這些內(nèi)部更新，以同步它們的內(nèi)部狀態(tài)時，道具改變，它們的定義是不純的。等等，你可能會說，UI是一個狀態(tài)函數(shù)。

精確。這就是鉤子發(fā)揮作用的地方。

鉤子代表了看待效果的另一種方式。與其考慮組件的整個生命周期，掛鉤允許我們將關注點縮小到當前狀態(tài)。然后，我們可以聲明要在其中運行效果的狀態(tài)，確保這些狀態(tài)更改反映在效果中。當然，一個“效果”可以是很多事情，從用useState處理狀態(tài)，發(fā)出網(wǎng)絡請求或者用useEffect手動更新DOM，或者用useCallback計算昂貴的回調(diào)函數(shù)。

但是我們?nèi)绾卧谝粋€純函數(shù)中推斷這些副作用呢?我很高興你問了!

代數(shù)效應的介紹

代數(shù)效應是通過定義一個效應、一組操作和一個效應處理程序(負責處理如何實現(xiàn)效應的語義)來在純上下文中推理計算效應的一種通用方法。1代數(shù)效應泛化在許多潛在的用途上，如輸入和輸出、處理狀態(tài)、異步/等待，以及更多。

這有點抽象，所以讓我們寫一些代碼來看看這在實踐中是如何工作的。遺憾的是，JavaScript實際上并不支持代數(shù)效果，盡管React可能在內(nèi)部模仿它們。雖然有一些不同的語言2支持代數(shù)效果，但我們將使用Eff，這是一種專門圍繞代數(shù)效果設計的函數(shù)式編程語言。不用擔心，大多數(shù)人不會知道Eff，所以我將在后面解釋一些語法。

代數(shù)效果的一個常見用例是處理有狀態(tài)計算。記住，效果只是在具有一組操作的接口中。

讓我們把它分解一下。我們有一個具有三個分支的處理程序，它們都返回一個函數(shù)。該函數(shù)將用于處理某些效果(或缺少效果)。

第一個分支，y ->有趣的currentState -> (y, currentState)，表示沒有效果，當我們到達我們正在處理的代碼塊的末尾時就會發(fā)生這種情況(我們很快就會看到)。這里的y是函數(shù)的返回值，所以它只返回內(nèi)部返回值和狀態(tài)的元組。

第二個和第三個分支匹配我們的效果，但是有一個可疑的論點，k，這里是一個延續(xù)，它表示在我們執(zhí)行效果之后的剩余計算。

GOTO,但更好的在我的心里，我是一個像神諭的人;我的創(chuàng)建設置標簽，我的方法執(zhí)行跳轉(zhuǎn)。然而，這是一種非常強大的goto指令。如果您的頭發(fā)在這一點上變綠了，不要擔心，因為您可能只處理延續(xù)的用戶，而不是概念本身。

這個小gem來自于GNU Smalltalk延續(xù)文檔。對于有些人來說，對GOTO的引用可能會讓您感到有些厭惡，但是延續(xù)仍然作為控制流而存在是有原因的，這是關于上下文的。GOTO更危險的方面之一是被扔進了一個無效的上下文中，但是使用延續(xù)，您實際上是在存儲一個動態(tài)進程，因此變量、指針等都將是有效的。

因為延續(xù)表示運行中的整個過程，所以它們本質(zhì)上是效果發(fā)生時調(diào)用堆棧的快照。當我們得到一個效果時，就好像我們在計算中按下一個巨大的暫停鍵，直到我們正確地處理這個效果。呼叫continue k4就像再次按下播放按鈕一樣。

當我們開始這個計算時，我們首先從state獲得用戶，它運行處理程序中的第二個分支。在這一點上，我們已經(jīng)按下了pause按鈕，所以當我們從state得到這個函數(shù)時，函數(shù)已經(jīng)停止運行。處理程序返回一個函數(shù)，該函數(shù)調(diào)用continue k currentState，用currentState的值恢復我們的計算。

每次執(zhí)行一個效果時，都會發(fā)生相同的流。按暫停，做一些工作，按播放。

這里，親愛的讀者，是代數(shù)效應的力量真正閃耀的地方。你看，我們?nèi)绾伪３譅顟B(tài)并不重要。當然，現(xiàn)在它只是內(nèi)存中的一個對象，但如果它在數(shù)據(jù)庫中呢?如果它存儲在瀏覽器的localStorage中呢?據(jù)celebrate所知，這些都是一樣的。如果需要，我們可以使用存儲鍵值存儲中的狀態(tài)的redisState處理程序交換狀態(tài)處理程序。

在JavaScript中，您的代碼必須知道什么是同步的，什么不是。如果將來發(fā)生更改，并且狀態(tài)是異步處理的，我們將需要開始處理承諾，這將需要對涉及此函數(shù)的所有內(nèi)容進行更改。但是使用代數(shù)效果，我們可以完全停止當前進程，直到效果完成，而不是維護一個運行的進程，該進程包含對另一個進程的引用。

當然，狀態(tài)不是我們能用代數(shù)效應處理的唯一東西。假設我們有一些網(wǎng)絡請求，我們想要創(chuàng)建或清理，我們想要執(zhí)行，但我們只想在函數(shù)完成后執(zhí)行。我們稱之為延遲效應。

此時，我相信你們會想"太好了，我們可以隨時暫停執(zhí)行。這和鉤子有什么關系?好吧，我們在Eff中列出的兩個效果存在于React中，只是它們的名字不同:state處理程序(意料之中)反映了useState，而我們的defer處理程序工作起來很像一個簡化的useEffect。前面的示例與用戶界面沒有直接關系，但是暫停和恢復過程的心理模型，以及在延續(xù)之后的調(diào)度效果，是理解鉤子和React未來的核心。

反應中的代數(shù)效應

讓我們把注意力轉(zhuǎn)回反應。之前我們討論了為什么需要鉤子，但問題是我們?nèi)绾慰创^子?；叵胍幌挛覀冏畛鯇⒋鷶?shù)效果定義為一組操作和一組效果處理程序。這里的操作是我們的鉤子(例如useState, useEffect，等等)，并在渲染期間處理這些效果。

由于鉤子的一些規(guī)則，我們知道效果處理程序是反應呈現(xiàn)周期的一部分。例如，如果您嘗試在一個React組件之外調(diào)用useEffect，您可能會在無效鉤子調(diào)用的一行中得到一個錯誤。鉤子只能在函數(shù)組件的內(nèi)部調(diào)用。類似地，如果你在沒有正確處理的情況下在Eff中執(zhí)行一個效果，你會看到運行時錯誤:未捕獲的效果延遲。雖然我們必須自己在Eff中設置處理程序，但在React中，它們是作為渲染周期的一部分設置的。

為什么這很重要呢?理解React對何時以及如何運行您的效果的實現(xiàn)負責是很重要的，因為它允許我們在React中隱藏大量的復雜性。例如，useEffect的關鍵用途之一是作為調(diào)度器。特別是對于計算開銷較大的ui(比如復雜的動畫)，調(diào)度工作單元是非常復雜的，并且React需要能夠決定什么工作是最高優(yōu)先級的。在更高的級別上，React可以暫停和恢復單個組件的呈現(xiàn)，這同樣可以對屏幕上的組件或響應用戶輸入的組件進行優(yōu)先級排序。安德魯·克拉克(Andrew Clark)寫了一篇關于纖維如何起作用及其設計目標的精彩概述，但這篇關于日程安排的小文章在這里尤為重要:

基于推的方法要求應用程序(你，程序員)決定如何安排工作?；诶姆椒ㄔ试S框架(React)更聰明地為您做出這些決定。

通過允許反應分離效果和渲染，我們允許它減輕我們的一些復雜性。隨著React越來越多地轉(zhuǎn)向懸念和并發(fā)模式，這一點將變得越來越重要。

結論

當我們對工具的思維模型與它的工作方式不一致時，通常會產(chǎn)生最痛苦的bug。對于許多React開發(fā)者來說，我認為我們很難看到grok在調(diào)用useState時發(fā)生了什么。我的希望是，對代數(shù)效應的理解至少為鉤子在幕后所做的工作提供了一個稍微好一點的模型。當然，值得重申的是，這并不是說鉤子就是這樣工作的——只是試著去理解它們。

這篇文章并沒有過多地探討React的內(nèi)部工作原理，但希望它能提供對鉤子和效果更普遍的更好的直覺。代數(shù)效應是編程語言研究中最近才出現(xiàn)的一個領域，至少我自己知道，要更好地理解它們需要大量的閱讀。如果你想深入研究代數(shù)效應的背后，我在下面列出了一些建議。

盡管一些社區(qū)的投訴反應成為一個黑盒,重要的是要記住,新工具的存在是有原因的,而更廣泛的鉤子和反應的主要目標是保護我們免受一定的復雜性,我們不想處理,讓我們專注于構建更好的ui和取悅用戶。