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 条评论
还没有评论，来抢沙发～