前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载本篇文章以 wp-calypso 仓库中 client/state/data-layer/wpcom/sites/comments/README.md 为主线剖析评论列表请求COMMENTS_LIST_REQUEST如何经由>registerHandlers( state/data-layer/wpcom/sites/comments/index.js, mergeHandlers( fetchHandler, replies, likes ) );其中fetchHandler负责四个核心动作类型全部通过dispatchRequest串联发请求fetch→ 成功onSuccess→ 失败onError三个环节Action 类型fetch发请求onSuccess成功处理onError失败处理COMMENTS_CHANGE_STATUSrequestChangeCommentStatushandleChangeCommentStatusSuccessannounceStatusChangeFailureCOMMENTS_LIST_REQUESTfetchCommentsListaddCommentsannounceFailureCOMMENT_REQUESTrequestCommentreceiveCommentSuccessreceiveCommentErrorCOMMENTS_EDITeditCommentupdateCommentannounceEditFailure动作类型的定义位于 client/state/action-types.jsCOMMENTS_LIST_REQUEST、COMMENT_REQUEST、COMMENTS_CHANGE_STATUS、COMMENTS_EDIT等而动作创建函数集中在 client/state/comments/actions.js。数据层的入口统一从client/state/comments/actions.js中引入本模块第 27 行import calypso/state/data-layer/wpcom/sites/comments确保动作被分发时对应处理器已被注册。二、请求发起端COMMENTS_LIST_REQUEST动作的诞生COMMENTS_LIST_REQUEST由动作创建函数requestCommentsList生成见 client/state/comments/actions.js#L123-L126export const requestCommentsList ( query ) ( { type: COMMENTS_LIST_REQUEST, query, } );值得注意的配套动作是requestPostComments同一文件的 L87-L111它面向某篇文章下的评论场景默认status approved、direction before并携带order、number分页数量来自NUMBER_OF_COMMENTS_PER_FETCH常量、author_wpcom_data等查询参数。而requestCommentsList接受的query则更通用除listType必须为site与siteId外其余参数全部透传给 WordPress.com 站点评论 API。三、核心链路fetchCommentsList组装 API 请求按 README 所述COMMENTS_LIST_REQUEST动作由获取站点评论 API 端点上的近期评论列表来完成。对应实现是fetchCommentsListclient/state/data-layer/wpcom/sites/comments/index.js#L120-L146其关键逻辑export const fetchCommentsList ( action ) { if ( site ! action?.query?.listType ) { return; } const { postId, siteId, status unapproved, type comment } action.query; const path postId ? /sites/${ siteId }/posts/${ postId }/replies : /sites/${ siteId }/comments; const query { ...omit( action.query, [ listType, postId, siteId ] ), status, type, }; return http( { method: GET, path, apiVersion: 1.1, query, }, action ); };3.1 三个可配置要点listType守卫只有query.listType site才真正发起请求这是防止与某文章评论等其他列表请求混淆的防御性设计。路径分叉传入postId时请求/sites/{siteId}/posts/{postId}/replies文章回复否则请求/sites/{siteId}/comments站点级全部评论。默认参数status默认unapproved、type默认comment均可被query覆盖listType、postId、siteId这三个内部元数据会被omit剔除不会泄露到 API 查询串中。对应 API 文档见代码注释中引用的 WordPress.com API 1.1 的GET /sites/$site/comments/。http动作来自 client/state/data-layer/wpcom-http/actions.js数据层管线会据此发起真实请求并在响应后回调addComments。四、onSuccessaddComments的多COMMENTS_RECEIVE分发README 的核心README 明确了两条设计事实都落在成功处理函数addCommentsclient/state/data-layer/wpcom/sites/comments/index.js#L148-L173中复用COMMENTS_RECEIVE动作因为评论 reducer 早已为此动作存在跨文章评论会触发多个COMMENTS_RECEIVE返回的评论若属于不同文章数据层会对每篇文章各分发一次COMMENTS_RECEIVE——这是评论 reducer 原始设计方式的直接后果。4.1 实现细节export const addComments ( { query }, { comments } ) { const { siteId } query; if ( 0 comments.length ) { return updateCommentsQuery( siteId, [], query ); } const actions [ updateCommentsQuery( siteId, comments, query ) ]; const byPost groupBy( comments, ( { post: { ID } } ) ID ); Object.entries( byPost ).forEach( ( [ post, postComments ] ) actions.push( receiveComments( { siteId, postId: parseInt( post, 10 ), // keyBy object property names are strings comments: postComments, } ) ) ); return actions; };空列表特判当返回 0 条评论时不派发任何COMMENTS_RECEIVE而是直接调用updateCommentsQuery( siteId, [], query )初始化评论树comments tree。代码注释指出这是 Jetpack 站点的必要 workaround——Jetpack 站点通过fetchCommentsList而非fetchCommentsTreeForSite填充评论树需要先让CommentList知道树已加载但为空。按文章分组借助automattic/js-utils的groupBy按comment.post.ID分组再对每组调用receiveComments({ siteId, postId, comments })生成各自的COMMENTS_RECEIVE动作。由于groupBy以对象属性承载分组属性名是字符串因此postId需parseInt( post, 10 )转回数字。UI 查询状态同步updateCommentsQuery源自 client/state/comments/ui/actions.js负责更新评论列表的 UI 查询状态使列表渲染层能感知本次查询结果。4.2 为什么要一个动作对应一篇文章这正对应 README 的说明这是评论 reducer 原始构建方式的后果。 从 client/state/comments/reducer.js#L108-L120 可以看到COMMENTS_RECEIVE的 reducer 分支case COMMENTS_RECEIVE: { const { skipSort } action; const comments action.comments.map( ( _comment ) ( { ..._comment, contiguous: ! action.commentById, has_link: commentHasLink( _comment.content, _comment.has_link ), } ) ); const allComments unionById( state[ stateKey ], comments ); return { ...state, [ stateKey ]: ! skipSort ? orderBy( allComments, getCommentDate, [ desc ] ) : allComments, }; }itemsreducer 以siteId:postId为键stateKey维护每篇文章的评论列表新评论经unionById按 ID 去重合并默认按评论日期倒序排序orderBy( ..., getCommentDate, [ desc ] )并补充contiguous、has_link等派生字段。由于状态树按站点 文章为粒度组织一次列表请求返回跨文章数据时数据层就必须拆成多个COMMENTS_RECEIVE各归其位否则 reducer 无法把评论准确落到各自文章的条目列表下。五、周边扩展回复、点赞处理器主文件通过mergeHandlers( fetchHandler, replies, likes )把回复与点赞两组处理器合并注册它们共享同一套dispatchRequest模式。5.1 发表回复COMMENTS_REPLY_WRITEclient/state/data-layer/wpcom/sites/comments/replies/new/index.js 中writeReplyComment调用通用工具dispatchNewCommentRequest向/sites/{siteId}/comments/{parentCommentId}/replies/new发POST请求成功回调updatePlaceholderComment、失败回调handleWriteCommentFailure。这三个工具函数定义在 client/state/data-layer/wpcom/sites/utils.jscreatePlaceholderComment生成 ID 为placeholder- Date.now()的占位评论status: pending、isPlaceholder: true、placeholderState: PENDING确保占位 ID 在站点 文章范围内唯一dispatchNewCommentRequest先派发COMMENTS_RECEIVE把占位评论插入状态树乐观更新父评论场景下skipSort: true同时发出 HTTP 请求updatePlaceholderComment成功后删除占位评论、用服务器返回的真实评论替换并派发COMMENTS_COUNT_INCREMENT递增计数handleWriteCommentFailure失败时记录COMMENTS_WRITE_ERROR带文章标题的错误文案并弹出错误通知。5.2 点赞与取消点赞点赞likes/new/index.js 处理COMMENTS_LIKE向/sites/{siteId}/comments/{commentId}/likes/new发POST成功时用bypassDataLayer( { type: COMMENTS_LIKE, ..., like_count } )将服务端like_count写回状态失败时回滚派发COMMENTS_UNLIKE并弹出 Could not like this comment 通知。取消点赞likes/mine/delete/index.js 处理COMMENTS_UNLIKE请求/sites/{siteId}/comments/{commentId}/likes/mine/delete成功回写COMMENTS_UNLIKE与like_count失败时反向回滚为COMMENTS_LIKE。点赞/取消点赞的乐观更新与回滚逻辑与itemsreducer 中COMMENTS_LIKE/COMMENTS_UNLIKE分支更新i_like与like_count字段一一对应。六、错误处理与用户体验评论列表获取失败时announceFailureindex.js#L175-L187会通过getRawSite读取站点信息若有站点名则显示Failed to retrieve comments for site “%(siteName)s”否则显示通用文案并派发errorNotice。状态变更COMMENTS_CHANGE_STATUS失败时announceStatusChangeFailure不仅回滚之前的乐观状态变更bypassDataLayer重新派发changeCommentStatus到上一次状态还按目标状态approved/unapproved/spam/trash给出差异化错误文案并提供 Try again 重试按钮。成功路径handleChangeCommentStatusSuccess则先清除对应错误通知若携带refreshCommentListQuery还会重新请求评论列表以刷新界面。单条评论请求COMMENT_REQUEST的错误处理receiveCommentError还有一处精妙设计由于无法区分网络失败与 shadow sync 失败当查询参数带force: wpcom时自动改用不带force的查询重试真实站点请求端在requestComment中为force场景附加了noRetry()策略避免重试风暴。七、演进方向从COMMENTS_RECEIVE到更语义化的动作README 最后指出目前使用COMMENTS_RECEIVE因为评论 reducer 已经为此存在未来当COMMENTS_ADD这样的更语义化动作可用时应改为使用它。 从当前仓库代码看client/state/comments/reducer.js 仍以COMMENTS_RECEIVE作为列表写入入口而COMMENTS_RECEIVE_ERROR、COMMENTS_WRITE_ERROR共同承担占位评论的错误状态记录placeholderState: PLACEHOLDER_STATE.ERROR。这意味着如果你要扩展评论数据层新增列表类请求时应沿用复用COMMENTS_RECEIVE、按siteId:postId分组派发的既有约定若未来引入专门的COMMENTS_ADD动作再逐步将addComments的 onSuccess 迁移到新动作同时保持 reducer 兼容。八、小结一份可复用的数据层实现清单梳理本文涉及的完整调用链与源码证据动作创建client/state/comments/actions.js#L123-L126 的requestCommentsList生成COMMENTS_LIST_REQUEST处理器注册client/state/data-layer/wpcom/sites/comments/index.js 的fetchHandler经registerHandlers注册请求组装fetchCommentsList按listType site守卫选择/sites/{id}/comments或/posts/{id}/replies路径默认statusunapproved、typecomment结果分发addComments空列表时初始化评论树非空时按文章分组派发多个COMMENTS_RECEIVE与itemsreducer 的siteId:postId粒度一一对应周边能力回复走replies/new的占位评论乐观更新流程点赞/取消点赞分别走likes/new与likes/mine/delete失败均自动回滚。这套动作 数据层 分组派发 乐观更新的模式不仅是评论模块的实现核心也是理解 wp-calypso 其他>赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐让老款Mac重获新生OpenCore Legacy Patcher完整指南让老款Mac重获新生OpenCore Legacy Patcher完整指南 OpenCore Legacy Patcher是一款革命性的开源工具专门为苹果官前端CMSwp-calypso 评论组件Comments Block源码解析从 post Prop 到线程化评论树的完整实现wp calypso 评论组件Comments Block源码解析从 post Prop 到线程化评论树的完整实现 导读 本文基于 wp calypso前端CMS深入解析 wp-calypso 订阅者管理模块从路由、数据层到源码实现的完整指南深入解析 wp calypso 订阅者管理模块从路由、数据层到源码实现的完整指南 导读 本文围绕 wp calypso 仓库中 client/my sites前端CMS上一篇WeChatFerry 如何三步把微信变成大模型机器人微信 Hook 完整教程下一篇终极指南如何简单配置Alienware灯光与风扇控制彻底摆脱AWCC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
