React Hooks的丑陋一面
在這篇文章中，我將分享我對React Hooks的觀點，正如這篇文章的標題所暗示的那樣，我不是一個忠實的粉絲。
讓我們來分析一下React官方的文檔中描述的放棄類而使用鉤子的動機。
動機1：class令人困惑
| 我們發現，class可能是學習React的一大障礙，你必須了解 this 在JavaScript中的工作方式，這與大多數語言中的工作方式截然不同。你必須記住要綁定事件處理程序，代碼會非常啰嗦，React中函數和類組件之間的區別，以及何時使用每個組件，甚至在有經驗的React開發人員之間也會導致分歧。 |
好吧，我可以同意 this 在你剛開始使用Javascript的時候可能會有點混亂，但是箭頭函數解決了混亂，把一個已經被Typescript開箱即用支持的第三階段功能稱為“不穩定的語法建議”，這純粹是煽動性的。React團隊指的是class字段語法，該語法已經被廣泛使用并且可能很快會得到正式支持：
- class Foo extends React.Component {
- onPress = () => {
- console.log(this.props.someProp);
- } render() { return <Button onPress={this.onPress} />
- }
- }
如你所見，通過使用class字段箭頭函數，你無需在構造函數中綁定任何內容，并且它始終指向正確的上下文。
如果Class令人困惑，那么對于新的鉤子函數我們能說些什么呢?鉤子函數不是常規函數，因為它具有狀態，看起來很奇怪的 this(又名 useRef )，并且可以具有多個實例。但這絕對不是類，介于兩者之間，從現在開始，我將其稱為 Funclass。那么，對于人類和機器而言，那些Funclass會更容易嗎?我不確定機器，但我真的不認為Funclass從概念上比類更容易理解。
類是一個眾所周知的思想概念，每個開發人員都熟悉 this 的概念，即使在javascript中也有所不同。另一方面，Funclass是一個新概念，一個很奇怪的概念。它們讓人感覺更神奇，而且它們過于依賴慣例而不是嚴格的語法。你必須遵循一些嚴格而奇怪的規則，你需要小心你的代碼放在哪里，而且有很多陷阱。還要準備好一些可怕的命名，比如 useRef( this 的花哨名字)、useEffect、useMemo、useImperativeHandle(說什么呢?)等等。
類的語法是為了處理多實例的概念和實例范圍的概念(this 的確切目的)而專門發明的。Funclass只是一種實現相同目標的奇怪方式，許多人將Funclass與函數式編程相混淆，但Funclass實際上只是變相的類。類是一個概念，而不是語法。
在React中，函數和類組件之間的區別，以及何時使用每一種組件，甚至在有經驗的React開發人員之間也會產生分歧。
到目前為止，這種區別非常明顯——如果需要狀態或生命周期方法，則使用類，否則，使用函數或類實際上并不重要。就我個人而言，我很喜歡這樣的想法：當我偶然發現一個函數組件時，我可以立即知道這是一個沒有狀態的“啞巴組件”。遺憾的是，隨著Funclasses的引入，情況不再是這樣了。
動機2：很難在組件之間重用有狀態邏輯
具有諷刺意味嗎?至少在我看來，React最大的問題是它沒有提供一個開箱即用的狀態管理方案，讓我們對應該如何填補這個空白的問題爭論了很久，也為Redux等一些非常糟糕的設計模式打開了一扇門。所以在經歷了多年的挫折之后，React團隊終于得出了一個結論：組件之間很難共享有狀態邏輯......誰能想到呢?
無論如何，勾子會使情況變得更好嗎?答案是不盡然。鉤子不能和類一起工作，所以如果你的代碼庫已經用類來編寫，你還是需要另一種方式來共享有狀態的邏輯。另外，鉤子只解決了每個實例邏輯共享的問題，但如果你想在多個實例之間共享狀態，你仍然需要使用stores和第三方狀態管理解決方案，正如我所說，如果你已經使用它們，你并不真正需要鉤子。
所以，與其只是治標不治本，或許React是時候行動起來，實現一個合適的狀態管理工具，同時管理全局狀態(stores)和本地狀態(每個實例)，從而徹底扼殺這個漏洞。
動機3：復雜的組件變得難以理解
如果你已經在使用stores，這種說法幾乎沒有意義，讓我們看看為什么。
- class Foo extends React.Component {
- componentDidMount() {
- doA();
- doB();
- doC();
- }
- }
在這個例子中，你可以看到，我們可能在 componentDidMount 中混合了不相關的邏輯，但這是否會使我們的組件膨脹?不完全是。整個實現位于類之外，而狀態位于store中，沒有store 所有狀態邏輯都必須在類內部實現，而該類確實會臃腫。但看起來React又解決了一個問題，這個問題大多存在于一個沒有狀態管理工具的世界里。實際上，大多數大型應用程序已經在使用狀態管理工具，并且該問題已得到緩解。另外，在大多數情況下，我們也許可以將這個類分解成更小的組件，并將每個 doSomething() 放在子組件的 componentDidMount 中。
使用Funclass，我們可以編寫如下代碼：
- function Foo() {
- useA();
- useB();
- useC();
- }
看起來有點干凈，但是是嗎?我們還需要在某個地方寫3個不同的useEffect鉤子，所以最后我們要寫更多的代碼，看看我們在這里做了什么——有了類組件，你可以一目了然地知道組件在mount上做什么。在Funclass的例子中，你需要按照鉤子并嘗試搜索帶有空依賴項數組的 useEffect，以了解組件在mount上做什么。生命周期方法的聲明性本質上是一件好事，我發現研究Funclasss的流程要困難得多。我見過很多案例是Funclasses讓開發者更容易寫出糟糕的代碼，我們后面會看到一個例子。
但是首先，我必須承認 useEffect 有一些好處，請看以下示例：
- useEffect(() => {
- subscribeToA(); return () => {
- unsubscribeFromA(); }; }, []);
useEffect 鉤子讓我們將訂閱和退訂邏輯配對在一起。這其實是一個非常整潔的模式，同樣的，把 componentDidMount 和 componentDidUpdate 配對在一起也是如此。以我的經驗，這些情況并不常見，但它們仍然是有效的用例，在這里 useEffect 確實很有用。問題是，為什么我們必須使用Funclass才能獲得 useEffect?為什么我們的Class不能有類似的東西?答案是我們可以：
- class Foo extends React.Component {
- someEffect = effect((value1, value2) => {
- subscribeToA(value1, value2); return () => {
- unsubscribeFromA(); }; }) render(){ this.someEffect(this.props.value1, this.state.value2);
- return <Text>Hello world</Text>
- }}
effect 函數將記住給定的函數，并且僅當其參數之一已更改時才會再次調用它。通過從我們的render函數內部觸發效果，我們可以確保它在每次渲染/更新時都被調用，但只有當它的一個參數被改變時，給定的函數才會再次運行，所以我們在結合 componentDidMount 和 componentDidUpdate 方面實現了類似 useEffect 的效果，但遺憾的是，我們仍然需要在 componentWillUnmount 中手動進行最后的清理。另外，從render內調用效果函數也有點丑。為了得到和useEffect完全一樣的效果，React需要增加對它的支持。
最重要的是 useEffect 不應該被認為是進入funclass的有效動機，它本身就是一個有效的動機，也可以為類實現。
動機4：性能
React團隊說類很難優化和最小化，funclass應該以某種方式改進，關于這件事，我只有一件事要說——給我看看數字。
我至今找不到任何論文，也沒有我可以克隆并運行以比較Funclasses VS Class的性能的基準演示應用程序。事實上，我們沒有看到這樣的演示并不奇怪——Funclasses需要以某種方式實現這個功能(如果你喜歡的話，也可以用Ref)，所以我很期待那些讓類難以優化的問題，也會影響到Funclasses。
不管怎么說，所有關于性能的爭論，在不展示數據的情況下實在是一文不值，所以我們真的不能把它作為論據。
動機5：Funclass不太冗長
你可以找到很多通過將Class轉換為Funclass來減少代碼的例子，但大多數甚至所有的例子都利用了 useEffect 鉤子，以便將 componentDidMount 和 componentWillUnmount 結合在一起，從而達到極大的效果。
但正如我前面所說，useEffect 不應該被認為是Funclass的優勢，如果忽略它所實現的代碼減少，那么只會留下非常小的影響。而且，如果你嘗試使用 useMemo，useCallback 等來優化Funclass，你甚至可能得到比等效類更冗長的代碼。
當比較小而瑣碎的組件時，Funclasses毫無疑問地贏了，因為類有一些固有的模板，無論你的類有多小你都需要付出。但在比較大的組件時，你幾乎看不出差別，有時正如我所說，類甚至可以更干凈。
最后，我不得不對 useContext 說幾句：useContext其實比我們目前原有的類的context API有很大的改進。但是再一次，為什么我們不能為類也有這樣漂亮而簡潔的API呢? 為什么我們不能做這樣的事情。
- //inside "./someContext" :
- export const someContext = React.Context({helloText: 'bla'});
- //inside "Foo":
- import {someContext} from './someContext';
- class Foo extends React.component {
- render() {
- <View>
- <Text>{someContext.helloText}</Text>
- </View>
- }
- }
當上下文中的 helloText 發生變化時，組件應該重新渲染以反映這些變化。就是這樣，不需要丑陋的高階組件(HOC)。
那么，為什么React團隊選擇只改進useContext API而不是常規content API?我不知道，但這并不意味著Funclass本質上更干凈。這意味著React應該通過為類實現相同的API改進來做得更好。
因此，在提出有關動機的問題之后，讓我們看一下我不喜歡的有關Funclass的其他內容。
隱藏的副作用
在Funclasses的 useEffect 實現中，最讓我困擾的一件事，就是沒有弄清楚某個組件的副作用是什么。對于類，如果你想知道一個組件在掛載時做了什么，你可以很容易地檢查 componentDidMount 中的代碼或檢查構造函數。如果你看到一個重復的調用，你可能應該檢查一下 componentDidUpdate，有了新的 useEffect 鉤子，副作用可以深深地嵌套在代碼中。
假設我們檢測到一些不必要的服務器調用，我們查看可疑組件的代碼，然后看到以下內容：
- const renderContacts = (props) => {
- const [contacts, loadMoreContacts] = useContacts(props.contactsIds);
- return (
- <SmartContactList contacts={contacts}/>
- )
- }
這里沒什么特別的，我們應該研究 SmartContactList，還是應該深入研究 useContacts?讓我們深入研究一下 useContacts 吧：
- export const useContacts = (contactsIds) => {
- const {loadedContacts, loadingStatus} = useContactsLoader(); const {isRefreshing, handleSwipe} = useSwipeToReresh(loadingStatus); // ... many other useX() functions
- useEffect(() => {
- //** 很多代碼，都與一些加載聯系人的動畫有關。*//
- }, [loadingStatus]); //..rest of code
- }
好的，開始變得棘手。隱藏的副作用在哪里?如果我們深入研究 useSwipeToRefresh，我們將看到：
- export const useSwipeToRefresh = (loadingStatus) => {
- // ..lot's of code
- // ...
- useEffect(() => {
- if(loadingStatus === 'refresing') {
- refreshContacts(); // bingo! 我們隱藏的副作用
- }
- }); //<== 我們忘記了依賴項數組！
- }
我們發現了我們的隱藏效果，refreshContacts 會在每個組件渲染時意外地調用fetch contacts。在大型代碼庫和某些結構不良的組件中，嵌套的 useEffect 可能會造成麻煩。
我并不是說你不能用類編寫糟糕的代碼，但是Funclasses更容易出錯，而且沒有嚴格定義生命周期方法的結構，更容易做糟糕的事情。
膨脹的API
通過在類的同時增加鉤子API，React的API實際上增加了一倍。現在每個人都需要學習兩種完全不同的方法，我必須說，新API比舊API晦澀得多。一些簡單的事情，如獲得之前的props和state，現在都成了很好的面試材料。你能寫一個鉤子獲得之前得 props 在不借助google的情況下?
像React這樣的大型庫必須非常小心地在API中添加如此巨大的更改，這樣做的動機甚至是不合理的。
缺乏說明性
在我看來，Funclass比類更混亂。例如，要找到組件的切入點就比較困難——用classes只需搜索 render 函數，但用Funclasses就很難發現主return語句。另外，要按照不同的 useEffect 語句來理解組件的流程是比較困難的，相比之下，常規的生命周期方法會給你一些很好的提示，讓你知道自己的代碼需要在哪里尋找。如果我正在尋找某種初始化邏輯，我將跳轉(VSCode中的cmd + shift + o)到 componentDidMount，如果我正在尋找某種更新機制，則可能會跳到 componentDidUpdate 等。通過Funclass，我發現很難在大型組件內部定位。
約定驅動的API
鉤子的主要規則(可能也是最重要的規則)之一是使用前綴約定。
就是感覺不對
你知道有什么不對勁的感覺嗎?這就是我對鉤子的感覺。有時我能準確地指出問題所在，但有時只是一種普遍的感覺，即我們走錯了方向。當你發現一個好的概念時，你可以看到事情是如何很好地結合在一起的，但是當你在為錯誤的概念而苦惱的時候，發現你需要添加更多更具體的東西和規則，才能讓事情順利進行。
有了鉤子，就會有越來越多奇怪的東西跳出來，有更多“有用的”鉤子可以幫助你做一些瑣碎的事情，也有更多的東西需要學習。如果我們需要這么多的utils在我們的日常工作中，只是為了隱藏一些奇怪的復雜，這是一個巨大的跡象，說明我們走錯了路。
幾年前，當我從Angular 1.5轉到React時，我驚訝于React的API是如此簡單，文檔是如此的薄。Angular曾經有龐大的文檔，你可能要花上幾天的時間才能涵蓋所有內容——消化機制、不同的編譯階段、transclude、綁定、模板等等。光是這一點就給我很大的啟示，而React它簡潔明了，你可以在幾個小時內把整個文檔看一遍就可以了。在第一次，第二次以及以后的所有次嘗試使用鉤子的過程中，我發現自己有義務一次又一次地使用文檔。
總結
我討厭成為聚會的掃興者，但我真的認為Hooks可能是React社區發生的第2件最糟糕的事情(第一名仍然由Redux占據)。它給已經脆弱的生態系統增加了另一場毫無用處的爭論，目前尚不清楚鉤子是否是推薦的使用方式，還是只是另一個功能和個人品味的問題。
我希望React社區能夠醒來，并要求在Funclass和class的功能之間保持平衡。我們可以在類中擁有更好的Context API，并且可以為類提供諸如useEffect之類的東西。如果需要，React應該讓我們選擇繼續使用類，而不是通過僅為Funclass添加更多功能而強行殺死它而將類拋在后面。
另外，早在2017年底，我就曾以《Redux的丑陋面》為題發表過一篇文章，如今連Redux的創造者Dan Abramov都已經承認Redux是一個巨大的錯誤。
只是歷史在重演嗎?時間會證明一切。
無論如何，我和我的隊友決定暫時堅持用類，并使用基于Mobx的解決方案作為狀態管理工具。我認為，在獨立開發人員和團隊工作人員之間，Hooks的普及率存在很大差異——Hooks的不良性質在大型代碼庫中更加明顯，你需要在該代碼庫中處理其他人的代碼。我個人真的希望React能把 ctrl+z 的鉤子全部放在一起。
我打算開始著手制定一個RFC，為React提出一個簡單、干凈、內置的狀態管理方案，一勞永逸地解決共享狀態邏輯的問題，希望能用一種比Funclasses不那么笨拙的方式。
