前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载导读Atomic Transfer自动迁移是 WordPress.com 将站点迁往 Atomic 托管平台的过程它属于有状态的持续运行流程stateful process客户端必须精确跟踪其进度才能正确渲染迁移中的进度条、结算成功页乃至取消订阅时的回滚提示。wp-calypso 在 client/state/atomic-transfer/ 状态子树中集中管理这一过程本篇文章将以 client/state/atomic-transfer/README.md 为核心骨架结合 actions、reducer、data-layer 轮询实现、selector 与 UI 消费方源码完整讲解该子树的动作定义、状态字段语义、status状态机、轮询与超时机制以及如何在自己的组件中接入这套状态。读完本文你将掌握 wp-calypso 中一个站点仅存一条迁移记录的存储约定、两类 Action 的职责边界以及CLIENT_TIMEOUT等细粒度状态在真实业务中的落地方式。状态子树总览一个站点一条迁移记录Atomic Transfer 的存储约定非常明确每个站点在同一时刻最多只有一条 transfer 记录All Atomic transfer information is stored as a single possible transfer per site。因此子树没有设计成数组或集合而是用siteId作为键、单条对象作为值。在 reducer.js 末尾可以看到这一结构的组装方式export default withStorageKey( atomicTransfer, keyedReducer( siteId, atomicTransfer ) );keyedReducer( siteId, atomicTransfer )把每个站点独立成键互不干扰withStorageKey( atomicTransfer, ... )为这个 reducer 绑定存储键atomicTransfer使得 Redux 树中对应形如state.atomicTransfer[ siteId ]的结构。配合 init.js 中的registerReducer( [ atomicTransfer ], reducer )该子树会按需注册进 Redux storelazy 注册这也是 package.json 声明sideEffects: [./init.js]的原因——只有 importinit.js才产生副作用。读取侧与之对称selector get-atomic-transfer.js 用可选链安全取值export default ( state, siteId ) state.atomicTransfer?.[ siteId ] ?? {};当站点从未发起过迁移或状态缺失时它返回空对象{}这与 README 中_falsey_无任何迁移信息的语义吻合。对应测试 client/state/selectors/test/get-atomic-transfer.js 验证了无站点 ID、无记录时返回空对象有记录时原样返回三种分支。Actions两个动作一进一出README 给出了子树的全部动作本质上是发起请求与写入结果两个动作actiondescriptionfetchAtomicTransfer返回ATOMIC_TRANSFER_REQUESTaction typesetAtomicTransfer返回ATOMIC_TRANSFER_SETaction type其实现见 actions.jsexport const fetchAtomicTransfer ( siteId ) ( { type: ATOMIC_TRANSFER_REQUEST, siteId, } ); export const setAtomicTransfer ( siteId, transfer ) ( { type: ATOMIC_TRANSFER_SET, siteId, transfer, } );两个 action 类型在 client/state/action-types.ts 中定义export const ATOMIC_TRANSFER_REQUEST ATOMIC_TRANSFER_REQUEST; export const ATOMIC_TRANSFER_SET ATOMIC_TRANSFER_SET;值得注意的是同文件还定义了ATOMIC_TRANSFER_INITIATE_TRANSFER、ATOMIC_TRANSFER_REQUEST_LATEST、ATOMIC_TRANSFER_SET_LATEST等相邻动作——它们服务于自动化迁移automated transfer的另一套数据流见 client/state/atomic/transfers/reducer.js与本文讨论的atomic-transfer子树是两个并行实现阅读时注意区分。动作层测试 client/state/atomic-transfer/test/actions.js 精确断言了两个 creator 的输出形状fetchAtomicTransfer( 1 )产出{ type: ATOMIC_TRANSFER_REQUEST, siteId: 1 }setAtomicTransfer( 1, { status: pending } )产出携带transfer对象的 set 动作。Reducer合并写入谨慎清场reducer.js 是整个子树的唯一事实来源实现export const atomicTransfer ( state {}, action ) { switch ( action.type ) { case ATOMIC_TRANSFER_SET: return { ...state, ...action.transfer }; case ATOMIC_TRANSFER_REQUEST: { if ( state.status ! transferStates.CLIENT_TIMEOUT ) { return state; } const { status, ...rest } state; return rest; } } return state; };两种 action 的处理逻辑分别对应ATOMIC_TRANSFER_SET浅合并。用{ ...state, ...action.transfer }把服务端返回的最新 transfer 字段合并进既有记录。atomic_transfer_id、blog_id、status、created_at等字段都由服务端下发客户端原样保存。ATOMIC_TRANSFER_REQUEST仅在超时态下清场。若当前状态不是CLIENT_TIMEOUT请求动作不会改动任何数据纯幂等一旦当前是CLIENT_TIMEOUT则通过解构const { status, ...rest } state剔除超时状态保留其余字段。这一设计有明确的业务动机CLIENT_TIMEOUT是客户端本地写入的临时裁决并非服务端事实。当用户重新发起请求例如重新加载页面再次查询时必须先把上次的超时残留清掉否则一次旧的超时会被误当作本次等待的结局。测试 client/state/atomic-transfer/test/reducer.js 对这条逻辑给了三个典型用例请求动作会丢弃CLIENT_TIMEOUT状态但保留atomic_transfer_id、blog_id等其他字段对ACTIVE、COMPLETED等状态请求动作原样返回toBe( state )引用相等证明未产生新对象空状态不受影响。status 状态机从从未迁移到已迁移README 指出status代表某个站点在迁移流程中所处的位置顶层语义可归纳为三段——从未尝试迁移 / 正在迁移 / 已经迁移而正在迁移内部还有更细的子状态用于过程追踪。原始表格完整如下statusmeaningPENDINGA Transfer record was created but the transfer has not startedACTIVEA transfer is in progressCOMPLETEDThe transfer has completed and the Atomic site is readyERRORThe transfer failedREVERTEDThe transfer was revertedCLIENT_TIMEOUTThe client stopped waiting after five minutes; transfer may still finish on the serverfalseyNo information about any transfers exists in Calypso在源码中这些状态收敛为 constants.js 的transferStates常量对象注意 README 中的状态是大写枚举名代码中实际以小写字符串存储export const transferStates { PENDING: pending, ACTIVE: active, COMPLETED: completed, ERROR: error, REVERTED: reverted, CLIENT_TIMEOUT: client_timeout, PROVISIONED: provisioned, };代码常量比 README 多出PROVISIONED: provisioned一项说明常量是服务端状态集合的超集保留给服务端可能下发的其他状态。而存储到 Redux 中的实际值是小写字符串如activeUI 组件通过transferStates.ACTIVE等常量引用避免魔法字符串散落各处。三类结局状态与状态机的收敛迁移的终态判定集中在>const settledStates [ transferStates.COMPLETED, transferStates.ERROR, transferStates.REVERTED ];收到这三种状态之一轮询立即停止其余状态含PENDING、ACTIVE、PROVISIONED及未知字符串一律继续轮询。测试 client/state/data-layer/wpcom/sites/transfers/test/latest.js 专门用test.each( [ reverting, unknown ] )验证了未知状态也会被当作未定局继续轮询体现了状态机对服务端新状态的向前兼容。状态在 UI 中的语义status不只是内部数据它直接驱动用户可见行为。最典型的消费方是 client/my-sites/checkout/checkout-thank-you/transfer-pending/index.tsx其中的跳转逻辑完整映射了状态语义COMPLETED→ 跳到/checkout/thank-you/${ siteSlug }/${ orderId }展示成功页ERROR/REVERTED→ 提示迁移未能完成请稍后重试跳回/stats/${ siteSlug }CLIENT_TIMEOUT→ 提示迁移耗时超出预期可能仍在后台继续刷新页面即可查看并跳回统计页其余状态PENDING/ACTIVE等→ 持续渲染Loading进度条Setting up your site / Upgrading infrastructure / Preparing WooCommerce三步。另一个消费场景是取消订阅时的回滚提示client/components/marketing-survey/cancel-purchase-form/index.tsx 通过getAtomicTransfer( state, purchase.blog_id )读取迁移记录把atomicTransfer.created_at格式化成回滚日期我们将在 {{迁移日期}} 把站点回滚到安装第一个插件/主题时的状态见 atomic-revert-step.tsx。这解释了为什么 README 说子树提供了将其可视化呈现所需的全部信息——除status外created_at、atomic_transfer_id等字段同样承载着用户可感知的语义。轮询与超时CLIENT_TIMEOUT 背后的完整机制CLIENT_TIMEOUT是 README 中最特殊的子状态——客户端停止等待五分钟后迁移仍可能在服务端继续。它并非服务端下发而是>export const requestTransfer ( action ) [ http( { method: GET, path: /sites/${ action.siteId }/transfers/latest, apiVersion: 1.2, }, action ), // ...arming the deadline timer ];请求打到 WordPress.com REST API 的/sites/{siteId}/transfers/latestAPI 版本 1.2返回该站点最近一次迁移记录。轮询节奏与期限data-layer 中定义了三个关键常量export const TRANSFER_POLL_DEADLINE_MS 5 * 60 * 1000; // 五分钟总期限 const POLL_INTERVAL_MS 10000; // 每 10 秒轮询一次 const MISSING_RECORD_ATTEMPTS 6; // 空记录最多重试 6 次机制要点10 秒一个轮询周期receiveTransfer收到未定局状态或空响应后用setTimeout( () dispatch( fetchAtomicTransfer( siteId ) ), POLL_INTERVAL_MS )安排下一轮请求schedulePoll五分钟硬期限每次发起请求的同时若该站点的 wait 尚未有 deadline 定时器则设置TRANSFER_POLL_DEADLINE_MS的定时器到期调用giveUp向 store 写入setAtomicTransfer( siteId, { ...transfer, status: transferStates.CLIENT_TIMEOUT } )——这就是CLIENT_TIMEOUT的写入点每站点一个 waitwaits是一个MapsiteId, timers同一站点的重复请求共享 deadline 定时器测试should not extend the deadline of a wait already in progress验证了这一点并且clearTransferWaits()可在测试或全局场景中清理全部定时器迟到响应不复活超时gaveUp()先读 store若发现该站点已是CLIENT_TIMEOUT且 transfer ID 匹配则拒绝接受迟到响应防止旧的超时等待被服务端迟到的答复复活进度条。错误处理的分层语义onTransferError对错误做了三种区分每种的处置都与状态语义严格对应latest.js4xx /no_transfer_record客户端无法读取状态但迁移本身在服务端照常运行因此不写入ERROR而是直接giveUp写入CLIENT_TIMEOUT文案明确表述迁移可能仍在继续其中no_transfer_record有 6 次短重试预算以覆盖购买后记录尚未落库的常见竞态5xx 等服务器错误走默认指数退避重试继续keepWaiting其余未知错误同样继续等待直到五分钟期限由 deadline 兜底结束。测试文件 client/state/data-layer/wpcom/sites/transfers/test/latest.js 用约 20 个用例覆盖了这条链路的全部关键分支请求超时、新请求重新起算期限、空响应恢复轮询、迟到响应维持超时、新 transfer ID 开启全新等待、4xx 结束等待、5xx 继续轮询、超时后停止重试等。关键调用链与代码位置索引关注点位置状态子树文档client/state/atomic-transfer/README.md动作创建器client/state/atomic-transfer/actions.js状态常量含PROVISIONEDclient/state/atomic-transfer/constants.jsReducer 与存储键绑定client/state/atomic-transfer/reducer.js按需注册入口client/state/atomic-transfer/init.jsaction type 定义client/state/action-types.ts读取 selectorclient/state/selectors/get-atomic-transfer.jsHTTP 轮询 / 超时 / 错误处理client/state/data-layer/wpcom/sites/transfers/latest.js迁移中进度页结算成功页client/my-sites/checkout/checkout-thank-you/transfer-pending/index.tsx取消订阅回滚提示client/components/marketing-survey/cancel-purchase-form/step-components/atomic-revert-step.tsx动作层测试client/state/atomic-transfer/test/actions.jsReducer 测试client/state/atomic-transfer/test/reducer.js轮询/超时/错误测试client/state/data-layer/wpcom/sites/transfers/test/latest.jsSelector 测试client/state/selectors/test/get-atomic-transfer.js如何在组件中接入这套状态综合上面的实现接入方式可以归纳为四步发起查询useEffect中或connect的 mapDispatchToProps 中dispatchfetchAtomicTransfer( siteId )data-layer 会自动接管 HTTP 请求与轮询组件无需关心网络细节。参考 transfer-pending/index.tsx。读取记录通过getAtomicTransfer( state, siteId )获取 transfer 对象注意站点无记录时返回{}应使用transfer.status的可选访问或判空。按状态分派 UIPENDING/ACTIVE显示进行中COMPLETED展示成功结果ERROR/REVERTED提示失败并引导重试CLIENT_TIMEOUT提示可能仍在后台继续falsey 则按从未迁移处理。留意 client-only 语义CLIENT_TIMEOUT由客户端写入latest.js不代表服务端失败若组件在超时后再次 dispatch 请求reducer 会自动清除旧超时标记reducer.js新等待从零开始。小结wp-calypso 的atomic-transfer状态子树虽小却完整示范了有状态长流程在前端 Redux 架构中的经典做法纯 action 表达意图、reducer 单点维护事实、data-layer 承担网络与定时副作用、selector 提供安全读取。status状态机把从未迁移 / 迁移中 / 已迁移三个顶层阶段细化为六个可观测状态并以CLIENT_TIMEOUT优雅处理了客户端等待上限与服务端后台继续执行之间的不对称轮询、五分钟期限、错误分层与迟到响应防复活等机制共同保证了进度 UI 既实时又诚实。赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐wp-calypso Automated Transfer 状态子树解析从 status 语义到 Redux 状态管理实战wp calypso Automated Transfer 状态子树解析从 status 语义到 Redux 状态管理实战 Automated Transfe前端CMSwp-calypso 已安装插件状态管理模块Installed Plugins深度解析Actions、Selectors 与 Reducer 全指南wp calypso 已安装插件状态管理模块Installed Plugins深度解析Actions、Selectors 与 Reducer 全指南 wp前端CMS深入解析 wp-calypso 当前用户状态模块Action、Reducer 与 Selector 实战指南深入解析 wp calypso 当前用户状态模块Action、Reducer 与 Selector 实战指南 导读 本文以 wp calypsoWordPr前端CMS上一篇gh0stzk dotfiles Neovim设置详解从Treesitter到LSP服务器的完整开发环境配置下一篇awesome-diarization终极资源清单100论文和工具一网打尽创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考