Calypso Reader 迁移收尾实战：Redux 状态、isRequesting 选择器与 connect() HOC 的完整清理指南

Calypso Reader 迁移收尾实战Redux 状态、isRequesting 选择器与 connect() HOC 的完整清理指南【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址: https://gitcode.com/gh_mirrors/wp/wp-calypso在 WordPress.com 的 Calypso 前端JavaScript React 单页应用中Reader阅读器模块的数据获取正在经历一次系统性迁移从「Redux>grep -r isRequestingXxx client/ --include*.{ts,tsx,js,jsx} -l这一步同样适用于RECEIVEreducer 和各类get*选择器。在删除 bridge、reducer 或选择器之前SKILL.md 第 2 步要求先 grep 确认没有其他代码还在读它们。Step 2用 React Query 状态替换 Redux 请求状态消费者确认后把useSelector( isRequestingXxx )替换为useQuery的解构状态// Before const isLoading useSelector( isRequestingXxx ); // After const { isLoading } useQuery( readXxxQuery() );React Query 的加载状态语义替换时务必理解三种状态的区别它们对应不同的 UI 场景状态语义与旧isRequesting的对应关系isLoading首次加载缓存中还没有数据最接近旧isRequesting首次挂载时的行为适合首屏 spinnerisFetching任何一次请求包括后台 refetch用于微妙的指示器如不打扰用户的细线条 loadingisPending还没有数据query 被 disabled 或首次加载适合 query 因参数缺失被禁用时的兜底判断仓库中的真实 query 工厂如 packages/api-queries/src/read-tags.ts 第 42-58 行会把staleTime设为1000 * 60 * 55 分钟并通过enabled控制带必填参数如locale的 query 是否触发——这些配置都会影响上述状态何时为真。迁移connect()HOC函数组件与类组件两条路connect()高阶组件的迁移是整个清理中最具操作性的部分。核心思路数据读取职责从 Redux 移交 React Queryconnect()要么完全移除要么降级为只映射剩余 Redux 数据。函数组件用 hooks 彻底替换connect()函数组件的替换规则非常明确mapStateToProps中的数据选择器 →useSelector()调用mapStateToProps中的请求状态isRequesting*→useQuery()解构出的状态mapDispatchToProps中的请求 actionrequestXxx→整体删除React Query 负责发起请求mapDispatchToProps中的非请求 action →useDispatch() 直接 dispatchconnect()HOC 本身 → 移除。// Before export default connect( ( state ) ( { items: getItems( state ), isLoading: state.reader.xxx.isRequestingXxx, } ), { requestXxx } )( MyComponent ); // After export default function MyComponent( { someParam }: Props ) { const { data, isLoading } useQuery( readXxxQuery( someParam ) ); const items useSelector( getItems ); if ( isLoading ) return Spinner /; return ItemList items{ items } /; }注意「After」版本中requestXxx完全消失——这正是迁移的核心收益请求的声明、触发、缓存、重试全部交给 React Query组件只需要声明「我需要这份数据」。类组件用小 HOC 桥接不要重写成函数组件hooks不能在类组件中运行。redux-cleanup.md特别强调不要把类组件重写为函数组件作为数据迁移的一部分——那是独立的重构混在一起会让 review 和 revert 都变得困难。正确做法用一个函数式 HOC 包裹类组件在 HOC 里调用useQuery()并把结果作为 props 转发进去。// Old: class reads isRequesting from Redux class MyClassComponent extends Component { render() { if ( this.props.isLoading ) return Spinner /; return ItemList items{ this.props.items } /; } } export default connect( ( state ) ( { items: getItems( state ), isLoading: state.reader.xxx.isRequestingXxx, } ) )( MyClassComponent );// New: functional wrapper bridges React Query into props function MyClassComponentWithQuery( props ) { const { isLoading } useQuery( readXxxQuery() ); return MyClassComponent { ...props } isLoading{ isLoading } /; } // connect() still maps Redux data; no longer maps isLoading export default connect( ( state ) ( { items: getItems( state ), } ) )( MyClassComponentWithQuery );在这个模式中connect()被保留但职责收窄为「只映射 Redux 数据」请求状态改由函数式包装层注入。类组件本体零改动迁移风险最小。若要进一步删除 bridge 组件与整个 Redux slice可参考 SKILL.md 中「Evaluate removing the>export const readSubscribedListsQuery () queryOptions( { queryKey: [ read, lists, subscribed ], queryFn: () fetchReadSubscribedLists(), ...seenCountQueryOptions, } ); export const readListQuery ( owner: string, slug: string ) queryOptions( { queryKey: [ read, lists, owner, slug ], staleTime: 1000 * 60 * 5, queryFn: () fetchReadList( owner, slug ), } );对照 SKILL.md 第 3 步的约定queryKey遵循[read, {domain}, ...params]staleTime对变化缓慢的列表取约 5 分钟。同样值得留意的是该文件第 43-82 行的patchListsSeenCount它通过queryClient.setQueryData直接对订阅列表缓存做乐观补丁——这正是清理时反复强调的「queryKey 消费者」任何修改或删除 queryKey 的操作都必须先 grep 全仓库找到所有对它做setQueryData/invalidateQueries/removeQueries的代码否则改动 key 后这些代码会静默失效用户操作后页面数据永远不刷新详见 SKILL.md 的「Cache-key consumers」强制检查与 Red Flags 清单。乐观更新与 loading 状态的参考实现清理isRequesting*之后UI 的「请求中」反馈由 React Query 承担。mutation 侧为了不损失旧 Redux 流程「dispatch RECEIVE 后界面立即更新」的即时体验mutations.md 第 3 节要求默认采用乐观更新其参考实现是 packages/api-queries/src/me-preferences.ts 第 136-167 行的userPreferenceOptimisticMutationonMutate中先cancelQueries取消在途 refetch再快照旧值、setQueryData写入乐观值onError回滚onSettled中invalidateQueries让缓存最终对齐服务端。这套onMutate / onError / onSettled三段式同样是清理时判断「这个旧 action 能否安全删除」的参考——只有当新链路完整覆盖了旧链路的成功、失败与回滚路径删除才是安全的。清理相关的常见错误与红线综合 redux-cleanup.md 与 SKILL.md 的「Common Mistakes」与「Red Flags」清单清理阶段最容易犯的错误如下错误正确做法忘记从 bridge dispatchRECEIVE只要 bridge 被保留就必须 dispatchRECEIVE因为其他代码仍从 Redux 读数据从 contenteditable="false">【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址: https://gitcode.com/gh_mirrors/wp/wp-calypso创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考