React不將Vite作為構建應用的首選原因是什么

這篇文章主要介紹“React不將Vite作為構建應用的首選原因是什么”，在日常操作中，相信很多人在React不將Vite作為構建應用的首選原因是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”React不將Vite作為構建應用的首選原因是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

在React文檔中，對于構建新的React應用，首推的方式是CRA（create-react-app）。

CRA推出于2016年，彼時還沒有成體系的React腳手架工具供大家使用，再加上這是官方工具，一經推出就受到了歡迎。截止當前，CRA倉庫已經收獲快10wstar。

但是，隨著時間的推移，出現了很多優秀的替代品，比如parcel、vite提供的React模版。而CRA本身的進步速度卻在放緩，其上一次提交要追溯到去年9月8日。此外，CRA對一些流行工具的支持也不是很好，比如在TailwindCSS文檔中就不推薦使用CRA：

CRA的定位

既然眾矢之的是CRA，那么首先我們需要明白CRA在React體系下的定位，再來看看Vite能否在這個定位下取代前者。

CRA誕生的時期（2016年），是SPA（單頁應用）最火熱的時期。在當時，他很好的解決了兩個痛點：

0配置初始化項目

這點不用過多介紹，執行如下命令后就能生成一個CSR（客戶端渲染）的React項目：

npx create-react-app 項目名復制代碼

集成工具鏈

CRA將當時的一些工程化最佳實踐都封裝在react-scripts包下，并抹平這些工具不兼容的地方。

開發者既享受了開箱即用的最佳實踐，又不用擔心某些工具升級后對項目造成的影響（CRA會處理）。

后來的很多優秀腳手架工具（比如Vite、Parcel），也都沿用了這種開箱即用的理念。

除了以上兩點，隨著CRA的走紅，React團隊還將他作為新特性的快速分發渠道，比如：

• Fast Refresh（針對React的熱更新，不會丟失組件狀態）

• Hooks推出后的一系列lint規則

依托CRA龐大的裝機量與使用量，這些集成到CRA的特性可以快速部署到開發者的項目中，達到快速提高普及率的目的。

試想，如果沒有CRA的推動，Hooks的lint規則很難在開發者中有這么高普及率，Hooks的理念也就不會這么快席卷整個前端框架領域。

從以上三點來看，Vite完全可以成為比CRA性能更優的替代品。

但是，React團隊的考量不僅如此。

腳手架工具的不足

雖然CRA開箱即用，但他提供的能力并不全面，比如他并不提供：

• 狀態管理方案

• 路由方案

• 數據請求方案

為什么不提供呢？因為在CRA發展的時期，這些方案還未形成最佳實踐。

隨著時間發展，開發者逐漸摸索出解決這些問題的最佳實踐。比如請求瀑布問題，考慮如下組件：

function App() {  const [data, update] = useState(null);  useEffect(() => {    fetch('http://...').then(res => update(res.json()))
  }, [])  
  return <Child data={data}/>}復制代碼

只有當App組件渲染后才能開始請求數據，這個請求時機是比較滯后的，如果Child依賴data來請求自己的數據，那么由于App請求的滯后導致Child的請求也滯后了，這就是請求瀑布問題。

這個問題常見的解決方法是 —— 將請求數據的邏輯收斂到路由方案中。

再比如，隨著業務不斷迭代，業務代碼體積越來越大，常見的優化手段是懶加載組件。

但是，手動執行懶加載常常會產生意料之外的問題。比如，頁面中有個圖表組件<Chart/>，如果開發者懶加載了這個組件，但是該組件在on mount時請求數據，這又會陷入請求瀑布問題。

要徹底解決這個問題，需要配合3類技術方案：

• 數據請求方案（解決數據流向問題）

• 路由方案（解決數據請求時機問題）

• 打包方案（解決懶加載的實現問題）

類似的問題還有很多，比如CSR首屏渲染速度慢的問題（需要通過SSR解決）。

可見，CRA僅僅提供了CSR環境下一個開箱即用的模版，但是隨著項目變得越來越復雜，一些業務細節問題CRA是沒有提供開箱即用的解決方案的。

從這個角度看，即使切換到Vite還是會面臨同樣的問題。

新時代的框架

隨著各種常見問題的最佳實踐被探索出來，逐漸誕生了一些以React為基礎，集成各種業務問題最佳實踐的框架，比如Next.js、Remix。

其中，Remix就是以React-Router（路由解決方案）為基礎，逐漸發展出來的囊括路由、數據請求、渲染為一體的全棧框架。

那么，能否將CRA迭代為類似Next.js、Remix這樣的全棧框架，一勞永逸解決CRA對各種最佳實踐的缺失呢？

React團隊認為，這樣做需要極高的開發成本，而且隨著時代發展，總會出現更多CRA不支持的最佳實踐（就像他當前面臨的問題一樣），那么CRA終有一天會被再度淘汰。

所以，這個方案不可取。

既然這個方案不可取，那么用Vite取代CRA的方案也不可取。因為單純使用Vite并沒有解決最佳實踐的缺失，必須在此基礎上實現那些最佳實踐（比如路由、數據請求...），那又回到了開發一個全棧框架。

最終，React團隊更傾向如下解決方案：將CRA作為一個腳手架工具，啟動后會根據用戶的不同場景需要（比如是SSR還是CSR）推薦不同的框架，再將CRA作為不使用框架情況下的兜底方案。

并且，在實現上，可能將兜底方案中的webpack切換為Vite。

到此，關于“React不將Vite作為構建應用的首選原因是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！