我不喜歡React的N個理由

語言: CN / TW / HK

theme: condensed-night-purple

打臉系列

歡迎使用全新虛擬列表解決方案 vv-react-table 🤐

開源地址:vv-react-table

使用文檔:文檔

前言

在過去的三個月裏,我從vue技術棧切換到了react技術棧,並使用react技術棧高質量完成了公司一個大型內部項目。而vv-react-table就是在此項目中沉澱出來的關於虛擬列表列表解決方案。

即便如此,我還是想説 我並不喜歡React

令人髮指的 useState

我們知道,在 react-hook中,我們需要使用 useState聲明一個響應式變量,如下所示:

js const [name,setName] = useState('劉小灰') 調用 setName方法就可以改變 name 的值。 但是由於 React響應式並沒有採用 Vue 那一套數據劫持的解決方案,導致每次更新響應式變量時,頁面需要重新執行。在不採取任何優化策略情況下,一個響應式變量的改變就會影響到整個組件乃至子組件的更新。

尤其是在大型項目中,React的渲染邏輯會變的撲朔迷離,作為開發者,我們需要時刻小心不必要的渲染、或者不正常的渲染。

個人覺得 React 非直覺 的渲染邏輯,在UI層面會給開發者帶來不小的心智負擔。我把這種設計稱之為不合理設計。

能力不足的 useEffect

這一點有社區 ahooks 來補充,尚且不説。但是單從語法層面,當 useEffect 的第二個參數是一個引用類型時,很容易當代碼進入死循環,比如一下代碼: ```ts import React, { useEffect, useState } from 'react'; const Demo = () => { const [count, setCount] = useState([]); const newArr = [4, 5]; useEffect(() => { setCount((count) => { return [...count, Math.random()]; }); }, [newArr]);

return

我是demo
; }; export default Demo; `` 更多情況下newArr變量是從props` 中傳遞過來的,所以處理起來變的十分麻煩。

過於靈活的語法

有的人可能會問,語法靈活可擴展性強,難道不好嗎?但是在一個項目團隊裏,尤其是團隊成員技術能力參差不齊的時候,你會發現React會在每個人手裏各顯神通。最後會導致整個項目的代碼可讀性很差。如果來個新人維護項目話就會帶來不小的維護成本及安全隱患。

還有就是,因為太靈活,導致連官網都沒有給出寫React的最佳實踐。

沒有統一的技術方法

Create React App 作為唯一一個 React 官方腳手架,顯得過於簡陋,拿來學習尚可,但作為項目開發,沒有給開發者提供一套完整的服務,這就導致我們必須藉助第三方框架,比如過於臃腫的 umi 等。

對於初學者,你可能會很糾結選哪個框架去學習?選哪個框架作為狀態管理...

為什麼大廠都傾向於React

拋開一切,如果現在把 Vue3React放在一起做抉擇的話,我想大廠也會很大概率選擇 Vue。但現實是有太多的 歷史原因。導致他們只能使用React

總結

當然 React 也有很多優點,比如 Props的設計以及友好的 TS 支持。但從語言的設計層面來講,React 可能有太多歷史包袱,很多東西設計的不符合直覺,需要開發者深入理解。最後倒是覺得 vue3 是 React 的最佳實踐

那麼,你覺得呢?歡迎下方留言討論

補充

在我寫補充內容的時候,離這篇文章的發佈僅僅過去了一天就收到大家一百四十多條的評論。原來 V R 之爭還是如此的激烈。我覺得這是一個好現象,不論誰對誰錯,至少評論的人留下了他們對 框架的理解和對技術的思考。我覺得這一點對於一個技術人來説至關重要。

就個人而言,我對 vue(指的是vue3版本) 和 react 的對比很純粹。就單單看他們的語言設計。我還是喜歡Vue這種符合常理和直覺的設計,更確切的説是中庸的設計,或許是因為我自己就是個中庸的人吧。

喜歡哪個框架是要用哪個框架是兩把事。在工作中我也使用 react 去開發項目,使用react造輪子 比如 vv-react-table虛擬列表解決方案。但是沒辦法,我還是喜歡vue,這種感覺説不清,或者説是一種信仰。