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

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

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

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

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

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

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

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

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

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

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

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

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

代數(shù)效應(yīng)的介紹

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

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

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

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

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

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

GOTO,但更好的在我的心里，我是一個像神諭的人;我的創(chuàng)建設(shè)置標(biāo)簽，我的方法執(zhí)行跳轉(zhuǎn)。然而，這是一種非常強(qiáng)大的goto指令。如果您的頭發(fā)在這一點(diǎn)上變綠了，不要擔(dān)心，因?yàn)槟赡苤惶幚硌永m(xù)的用戶，而不是概念本身。

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

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

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

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

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

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

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

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

反應(yīng)中的代數(shù)效應(yīng)

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

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

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

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

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

結(jié)論

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

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

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