React 狀態管理怎麼選提示詞（服務端狀態與客戶端狀態分開，Context、輕量 store、請求庫各管什麼）
React 項目裏狀態越堆越亂、不知道該放 useState、Context 還是全局 store 時用。貼出頁面與狀態清單，AI 先把每個狀態按來源歸類，再給出各自該用的方案、對比理由和分步遷移順序，避免把接口數據和介面狀態攪在一起。
通用大模型 對話模型通用
請你以資深 React 前端工程師的身份，幫我給項目裏的狀態「分家」並選方案。 項目情況： - React 與框架版本：[React 與框架版本] - 頁面與狀態清單（每個頁面有哪些數據、誰讀誰改）： [頁面與狀態清單] - 現在的做法：[現用狀態方案] - 最頭疼的問題：[當前痛點] 第一步，歸類。把清單裏的每個狀態歸入下面四類之一，拿不準的直接問我： A. 服務端狀態：來自接口，別人也可能改，有緩存、過期、重新獲取的問題； B. 地址列狀態：篩選條件、頁碼、當前標籤頁，刷新或分享連結後應當還在； C. 客戶端介面狀態：彈窗開關、表單草稿、主題、當前登入用戶； D. 派生數據：能由其他狀態算出來的，不應該單獨存。 第二步，按類選方案並說明理由： - A 類優先交給數據請求庫（如 TanStack Query、SWR）管理緩存、去重、失效和重試，不要複製進全局 store 再手動同步； - B 類放路由參數； - C 類先看共享範圍：單組件用 useState 或 useReducer；父子幾層用狀態提升；全應用低頻變化的（主題、語言、登入用戶）用 Context，並說明 Context 的值一變，所有消費它的組件都會重渲染，不適合高頻更新；跨得很遠又更新頻繁的才用輕量 store（如 Zustand、Jotai、Redux Toolkit），並按需訂閱； - D 類在渲染時直接計算，確有性能問題再做緩存。 第三步，輸出： 1. 一張表：頁面 | 狀態 | 類別 | 建議方案 | 理由； 2. 兩套整體方案的對比（依賴最少的一套、擴展性更好的一套），給出推薦； 3. 遷移步驟：按風險從低到高排，每步可單獨上線和回滾，寫明驗證方法。 庫的具體 API 以我所用版本的官方文檔為準，你拿不準的寫法標「需核對」，不要憑印象寫。
高亮處換成你自己的內容：[React 與框架版本]、[頁面與狀態清單]、[現用狀態方案]、[當前痛點]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[頁面與狀態清單] 不用貼代碼，按「訂單列表頁：訂單數據（接口）、篩選條件、勾選的行、批量操作彈窗」這樣一行一個頁面列出來就行。[現用狀態方案] 寫實際情況，例如「全部放 Redux，接口數據也存在裏面」。[當前痛點] 越具體越好，如「改一個篩選條件整頁重渲染」「返回列表頁時數據是舊的」。
常見問題與調整：
- 方案一上來就要引入三四個庫 → 追問：「在不新增依賴的前提下，只用 React 自帶能力重新給一版，並說明哪些地方會吃力。」
- 不確定 Context 會不會拖慢頁面 → 追問：「按我的清單，指出哪些狀態放進 Context 會引起大範圍重渲染，該怎麼拆分或換方案。」
- 遷移步驟太粗 → 追問：「只展開第 1 步，列出要改的文件類型、改動前後的代碼對照和回滾辦法。」
示例輸出
示例，僅供參考（後台管理項目，原先所有數據都放在全局 store）
| 頁面 | 狀態 | 類別 | 建議方案 |
|---|---|---|---|
| 訂單列表 | 訂單數據 | A 服務端狀態 | 數據請求庫，按頁碼和篩選條件緩存 |
| 訂單列表 | 篩選條件、頁碼 | B 地址列狀態 | 路由查詢參數 |
| 訂單列表 | 勾選的行 | C 介面狀態 | 頁面內 useState |
| 訂單列表 | 已選訂單總金額 | D 派生數據 | 渲染時由勾選的行計算，不單獨存 |
遷移第 1 步：只把訂單數據從全局 store 挪到請求庫，其他狀態先不動，驗證列表翻頁和篩選結果與原來一致。
tsx
const { data, isLoading } = useQuery({
queryKey: ['orders', page, filters], // 頁碼或篩選變化時自動重新請求
queryFn: () => fetchOrders({ page, filters }),
})同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～