從頭開始建構 React 應用程式
如果你的應用程式有現有框架無法妥善滿足的限制、你偏好建構自己的框架，或者你只是想學習 React 應用程式的基礎知識，你可以從頭開始建構一個 React 應用程式。
步驟 1：安裝建置工具
第一步是安裝一個建置工具，例如vite、parcel 或 rsbuild。這些建置工具提供打包和執行原始碼的功能，提供用於本地開發的開發伺服器，以及一個用於將應用程式部署到生產伺服器的建置命令。
Vite
Vite 是一個建置工具，旨在為現代網頁專案提供更快、更精簡的開發體驗。
npm create vite@latest my-app -- --template react-tsVite 具有明確的設計理念，並提供開箱即用的合理預設值。Vite 擁有豐富的外掛生態系統，支援快速重新整理、JSX、Babel/SWC 和其他常見功能。請參閱 Vite 的React 外掛 或 React SWC 外掛以及React SSR 範例專案以開始使用。
Vite 已經在我們的一個 推薦框架中被用作建置工具：React Router。
Parcel
Parcel 結合了出色的開箱即用開發體驗與可擴展的架構，可以將你的專案從剛開始的階段帶到大型生產應用程式。
npm install --save-dev parcelParcel 開箱即用地支援快速重新整理、JSX、TypeScript、Flow 和樣式設定。請參閱Parcel 的 React 使用指南以開始使用。
Rsbuild
Rsbuild是一個由 Rspack 驅動的建置工具，為 React 應用程式提供無縫的開發體驗。它附帶精心調整的預設值和效能最佳化，可供立即使用。
npx create-rsbuild --template reactRsbuild 內建支援 React 功能，如快速重新整理、JSX、TypeScript 和樣式設定。請參閱Rsbuild 的 React 指南以開始使用。
注意
用於 React Native 的 Metro
如果你要從頭開始使用 React Native，你需要使用Metro，這是 React Native 的 JavaScript 打包工具。Metro 支援為 iOS 和 Android 等平台進行打包，但與這裡的工具相比缺少許多功能。除非你的專案需要 React Native 支援，否則我們建議從 Vite、Parcel 或 Rsbuild 開始。
步驟 2：建構常見的應用程式模式
上面列出的建置工具一開始提供的是僅限客戶端、單頁應用程式（SPA），但不包含針對路由、資料獲取或樣式設定等常見功能的任何進一步解決方案。
React 生態系統包含許多解決這些問題的工具。我們列出了一些廣泛使用的工具作為起點，但如果其他工具更適合你，請隨意選擇。
路由
路由決定了當使用者造訪特定 URL 時要顯示的內容或頁面。你需要設定一個路由器來將 URL 對應到應用程式的不同部分。你還需要處理巢狀路由、路由參數和查詢參數。路由器可以在你的程式碼中配置，或者根據你的元件資料夾和檔案結構來定義。
路由器是現代應用程式的核心部分，通常與資料獲取（包括為整個頁面預取資料以加快載入速度）、程式碼分割（以最小化客戶端套件大小）和頁面渲染方法（以決定每個頁面的生成方式）整合在一起。
我們建議使用：
資料擷取
從伺服器或其他資料來源擷取資料是大多數應用程式的關鍵部分。正確地執行此操作需要處理載入狀態、錯誤狀態以及快取擷取的資料，這可能相當複雜。
專為資料擷取設計的函式庫會為您處理擷取和快取資料的繁重工作，讓您專注於應用程式需要哪些資料以及如何顯示它們。這些函式庫通常直接在您的元件中使用，但也可以整合到路由載入器中，以實現更快的預擷取和更好的效能，同時也能用於伺服器端渲染。
請注意，直接在元件中擷取資料可能會因網路請求瀑布流而導致載入時間變慢，因此我們建議盡可能在路由載入器或伺服器端預先擷取資料！這允許在顯示頁面時一次性擷取頁面所需的所有資料。
如果您要從大多數後端或 REST 風格 API 擷取資料，我們建議使用：
如果您要從 GraphQL API 擷取資料，我們建議使用：
程式碼分割
程式碼分割是將您的應用程式分解為可按需載入的較小套件的過程。應用程式的程式碼大小會隨著每個新功能和額外依賴項的增加而增加。應用程式可能會變得載入緩慢，因為整個應用程式的所有程式碼都需要在可以使用之前傳送。快取、減少功能/依賴項以及將部分程式碼移至伺服器執行可以幫助緩解載入緩慢的問題，但這些是不完整的解決方案，如果過度使用可能會犧牲功能。
同樣地，如果您依賴使用您框架的應用程式來分割程式碼，您可能會遇到載入速度比完全沒有進行程式碼分割時更慢的情況。例如，延遲載入圖表會延遲傳送渲染圖表所需的程式碼，將圖表程式碼與應用程式的其餘部分分開。Parcel 支援使用 React.lazy 進行程式碼分割。然而，如果圖表在初始渲染之後才載入其資料，那麼您現在需要等待兩次。這是一個瀑布流：您必須等待每個步驟逐一完成，而不是同時擷取圖表資料並傳送渲染它的程式碼。
按路由分割程式碼，當與打包和資料擷取整合時，可以減少應用程式的初始載入時間以及應用程式最大可見內容的渲染時間（最大內容繪製）。
有關程式碼分割的說明，請參閱您的建置工具文件：
提升應用程式效能
由於您選擇的建置工具僅支援單頁應用程式 (SPA)，您將需要實作其他渲染模式，例如伺服器端渲染 (SSR)、靜態網站生成 (SSG) 和/或 React 伺服器元件 (RSC)。即使您最初不需要這些功能，未來可能會有某些路由受益於 SSR、SSG 或 RSC。
- 單頁應用程式 (SPA)載入單個 HTML 頁面，並在使用者與應用程式互動時動態更新頁面。SPA 更容易上手，但初始載入時間可能較慢。SPA 是大多數建置工具的預設架構。
- 串流伺服器端渲染 (SSR)在伺服器上渲染頁面，並將完全渲染好的頁面傳送給客戶端。SSR 可以提升效能，但設定和維護可能比單頁應用程式更複雜。加上串流功能後，SSR 的設定和維護可能變得非常複雜。請參閱Vite 的 SSR 指南。
- 靜態網站生成 (SSG)在建置時為您的應用程式生成靜態 HTML 檔案。SSG 可以提升效能，但設定和維護可能比伺服器端渲染更複雜。請參閱Vite 的 SSG 指南。
- React 伺服器元件 (RSC)讓您可以在單一的 React 樹中混合建置時元件、僅伺服器元件和互動式元件。RSC 可以提升效能，但目前需要深厚的專業知識來設定和維護。請參閱Parcel 的 RSC 範例。
您的渲染策略需要與您的路由器整合，以便使用您的框架建置的應用程式可以在每個路由層級選擇渲染策略。這將實現不同的渲染策略，而無需重寫整個應用程式。例如，您應用程式的登陸頁面可能受益於靜態生成 (SSG)，而具有內容動態的頁面可能最適合使用伺服器端渲染。
為正確的路由使用正確的渲染策略可以減少載入第一個位元組內容所需的時間 (首次位元組時間)、渲染第一段內容的時間 (首次內容繪製)，以及渲染應用程式中最大可見內容的時間 (最大內容繪製)。
還有更多…
這些只是新應用程式從頭開始建置時需要考慮的功能的幾個例子。您將遇到的許多限制可能難以解決，因為每個問題都與其他問題相互關聯，並且可能需要您不熟悉的問題領域的深厚專業知識。
如果您不想自己解決這些問題，您可以從一個框架開始，它提供了這些開箱即用的功能。