前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载导读本文基于 WordPress.com 前端主仓库 wp-calypso 的 client/state/README.md 展开系统讲解 Calypso 如何构建并维护全局应用状态从创建 Redux Store、模块化按需加载 reducer到使用keyedReducer组合集合型状态、用withSchemaValidation校验持久化状态。读完本文你将掌握 Calypso 状态子树的标准目录组织、reducer 注册与依赖图自动加载机制以及如何在真实业务代码中安全地使用状态工具函数。client/state目录承载了 Calypso 全局状态树的所有行为目录下的每个子目录对应全局状态树中的一个子树sub-tree各自拥有独立的 reducer、action 与 selector。根模块导出一个函数调用后返回一个 Redux store 实例该实例将所有 dispatch 的 action 分发给全部已知 reducer。从单体状态到模块化状态Calypso 最初遵循 Redux 官方指南采用单体monolithic状态方案要把一个 reducer 挂进全局 store只需在index.js的组合 reducer 中追加这个函数所有 reducer 都会在应用启动前被一次性加载。随着 Calypso 状态规模膨胀把全部 reducer 提前加载的弊端越来越明显reducer 本身不大但它们往往依赖内外库和大块数据且 reducer 是同步的、无法异步加载于是全部进入了应用的启动关键路径critical path直接影响加载性能详见 docs/modularized-state.md 中的问题分析。因此 Calypso 转向**模块化状态modularized state**方案——reducer 不再全部预加载而是随用户导航按需注册。该方案遵循三条核心原则不需要显式声明哪些页面用了哪些状态这类声明既难确定又难维护不需要大范围改动既有代码因此排除把状态改成异步的方案状态的使用方组件/selector无需感知模块化与否。按需注册 reducerinit 文件与依赖图模块化状态的核心机制是通过副作用完成注册。每个模块化状态子树都有一个init文件负责注册 reducer例如reader的 client/state/reader/init.jsimport { registerReducer } from calypso/state/redux-store; import reducer from ./reducer; registerReducer( [ reader ], reducer );然后所有用到reader状态的 selector 与 action creator 模块都会先导入这个init文件import calypso/state/reader/init; function getStream( state, streamKey ) { return state.reader.streams[ streamKey ] || emptyStream; }真实代码中随处可见这种模式例如 reader/conversations/actions.js 与 get-reader-conversation-follow-status.js 都以import calypso/state/reader/init开头。这样做的效果是注册动作作为依赖图解析的一部分自动发生无需任何手工输入状态随常规构建流程被自动分发到不同 chunk浏览器只在需要时加载对应代码。registerReducer的底层实现在 client/state/redux-store.ts如果 store 尚未就绪注册请求会先进入一个队列reducerRegistrationQueue一旦通过setStore建立了全局 store队列中的全部 reducer 会被同步补注册之后的新注册立即生效。同一 key 重复注册不同的 reducer 会抛出Different reducers on multiple calls to addReducerToStore...错误见 client/state/add-reducer.ts防止模块化与静态注册相互冲突。动态添加 reducer 的底层机制动态注册由 store enhancer 支撑。client/state/utils/add-reducer-enhancer.js 给 store 附加了addReducer( keys, subReducer )方法它把新 reducer 组装进当前组合 reducer 并调用replaceReducer热替换。而 client/state/utils/reducer-utils.ts 中的addReducer会沿着 keyPath 逐层深入组合 reducer 树对尚未存在的 key 用reduceRight自动构建嵌套的combineReducers结构。收拢状态推荐的目录结构为集中管理状态官方建议某一状态子树的全部 reducer、selector 与 action creator 放在client/state/name对应目录下跨多个子树的 selector 则放在client/state/selectors。标准结构见 docs/modularized-state.mdclient/state/ └── { subject }/ ├── init.js ├── reducer.js ├── actions/ | ├── index.js | ├── action1.js | └── action2.js └── selectors/ ├── index.js ├── selector1.js └── selector2.js创建与使用 Redux Store在应用入口或测试中通过 client/state/index.ts 导出的createReduxStore创建 storeimport { createReduxStore } from calypso/state; const store createReduxStore();从源码看store 创建时装配了多层中间件与 enhancerclient/state/index.tsthunkMiddleware支持异步 thunk actionwpcomApiMiddleware数据层中间件必须最早进入中间件链因为它会在网络事件成功/失败/进度发生时重新 dispatch 带特殊 meta 的 action若其他中间件抢先处理可能误触发dynamicMiddlewares支持运行时动态注入中间件浏览器环境还按需追加 analytics、lib、desktop 中间件enhancer 链包含addReducerEnhancer动态加 reducer 的能力来源、调试环境下的consoleDispatcher与actionLogger以及浏览器中的 Redux DevTools 扩展。如果应用启动时已有浏览器持久化的旧状态可以作为initialState传入函数的第一个参数。另外index.ts还重新导出了类型化的useSelector/useDispatch/useStoreReact Hooks供组件在IAppState类型下使用。keyedReducer为集合状态编写简洁 reducer问题集合型 reducer 的样板代码很多业务状态是一组同类对象的集合比如按siteId组织的站点数据、按username组织的用户数据。若不用辅助工具reducer 必须亲自处理集合的散列结构const widgetCount ( state {}, action ) { if ( ADD_WIDGET action.type ) { return { ...state, [ action.siteId ]: state[ action.siteId ] 1, }; } return state; };reducer 明明只想操作一个整数却因为要按siteId存放集合而被迫写出复杂的初始状态与返回语法。用 keyedReducer 解耦keyedReducer( keyName, reducer )实现于 client/state/utils/keyed-reducer.ts提供了胶水它把单个对象的 reducer 提升为一个按键管理的集合 reducer自动从 action 中读取指定 key并把更新只派发到集合中对应条目。于是上面的逻辑可以写成const widgetCount ( state 0, action ) { if ( ADD_WIDGET action.type ) { return state 1; } return state; }; export default keyedReducer( siteId, widgetCount );完整的官方示例age/title/userReducer组合 keyedReducer( username, ... )const age ( state 0, action ) ( GROW action.type ? state 1 : state ); const title ( state grunt, action ) ( PROMOTION action.type ? action.title : state ); const userReducer combineReducers( { age, title, } ); export default keyedReducer( username, userReducer ); dispatch( { type: GROW, username: hunter02 } ); state.users { hunter02: { age: 1, title: grunt, }, };使用该辅助函数的好处单个子 reducer 保持小而清晰更新表达式与集合中其他条目完全解耦自动享受combineReducers的不可变更新语义——若实际没有变化则不会触发更新测试简单无需复杂的 mock。删除条目返回 undefined某些场景需要响应 action 删除集合中的 key。此时让 reducer 返回undefinedkeyedReducer会显式地从状态中移除该 keyconst deleteableUserReducer ( state, action ) DELETE action.type ? undefined : userReducer( state, action ); export default keyedReducer( username, deleteableUserReducer ); state.users { hunter02: { age: 1, title: grunt, }, }; dispatch( { type: DELETE, username: hunter02 } ); expect( state.users ).toEqual( {} );源码级细节与边界行为从 keyed-reducer.ts 的实现可以确认几个值得注意的行为key 校验keyPath必须是非空字符串reducer 必须是函数否则在构造时直接抛TypeErrorkeyPath 支持点号路径除siteId这种单层 key 外也支持meta.dataLayer.requestKey这类点分隔路径不支持括号/引号下标语法路径在构造时解析一次而不是每个 action 解析一遍空 key 短路若 action 中该路径的值为null或undefined整个 super-reducer 原样返回旧 state杜绝null 0这类隐式类型转换引用比较优化若子 reducer 返回的新状态与旧状态严格相等集合不变直接返回原 state初始态去重新状态若为undefined或与 reducer 的初始状态深度相等isEqual该 key 会被从集合中移除已存在时这同时保证了序列化时不会把无意义的初始条目写进持久化存储。与持久化的配合keyedReducer返回的 super-reducer 通过withPersistence实现了serialize/deserialize方法keyed-reducer.ts序列化时逐条目调用内层 reducer 的serialize跳过与初始态相等的条目反序列化时过滤掉undefined或等于初始态的条目。因此集合型状态也能正确接入 Calypso 的状态持久化机制。withSchemaValidation安全加载持久化状态Calypso 启动时会从浏览器持久化存储加载上次保存的状态见 client/state/utils/schema-utils.js。若该状态由旧版本 reducer 写入可能与新状态模型不兼容。withSchemaValidation( schema, reducer )解决此问题它返回一个新 reducer在加载持久化状态时自动做 JSON Schema 校验校验失败则回退到初始状态。const ageReducer withPersistence( ( state 0, action ) GROW action.type ? state 1 : state ); const schema { type: number, minimum: 0 }; export const age withSchemaValidation( schema, ageReducer ); deserialize( ageReducer, -5 ) -5; // 未包 schema直接透传 deserialize( age, -5 ) 0; // 校验失败回退初始状态 deserialize( age, 23 ) 23; // 校验通过实现要点schema-utils.js校验使用is-my-json-valid编译器开发环境NODE_ENV ! production会开启greedy/verbose并输出详细的字段级错误警告生产环境则关闭以省去校验开销快速路径若持久化状态与序列化后的初始状态深度相等直接判定合法跳过昂贵的完整 schema 校验包裹后的 reducer 通过withPersistence附加自定义deserialize持久化值为undefined或校验失败时返回初始状态否则交给内层 reducer 的deserialize处理。状态持久化的配套设施withPersistence 与序列化client/state/utils/with-persistence.ts 为 reducer 附加持久化能力默认serialize为恒等映射原样保存、deserialize为原样还原也可传入自定义的serialize/deserialize方法。keyedReducer与withSchemaValidation内部都依赖它utils/index.ts一并导出了serialize/deserialize供自定义持久化逻辑使用。withStorageKey独立存储 key模块化状态要求每个子树的 reducer 单独持久化。withStorageKey( reader, combinedReducer )见 client/state/reader/reducer.ts为 reducer 打上storageKey标记。在 reducer-utils.ts 的组合序列化逻辑中带storageKey的子 reducer 会被序列化到独立 key 下而不是塞进根对象——这正是模块化状态下各子树状态各自落盘、互不干扰的关键。动态注册后回填持久化状态add-reducer.ts 的addReducerToStore在把新 reducer 挂入 store 时若该 reducer 带有storageKey且提供了getStoredState会异步读取已持久化状态并 dispatchAPPLY_STORED_STATEaction 将其注入组合 reducer 在 reducer-utils.ts 中通过匹配storageKey定位并替换对应子树状态。这保证了按需加载的 reducer 依然能恢复上次会话的状态。新增状态的标准流程综合 client/state/README.md 与 docs/modularized-state.md 的操作指引为 Calypso 添加一块新状态或把旧状态模块化的完整步骤如下编写常规代码按上文目录结构写出 reducer、actions、selectors测试时可暂时挂到 client/state/reducer.js 的根 reducer即默认的非模块化方式但注意该文件的 eslint 规则已禁止新增 legacy reducer文件头部的no-restricted-imports配置就是为了防止继续往这个名单里加人见 reducer.js。添加init.js在子树根部创建 init 文件内容为registerReducer( [ subject ], reducer )。添加package.json声明副作用init 文件有副作用需要显式告知 webpack{ sideEffects: [ ./init.js ] }否则 webpack 在打包优化时可能误删 init 的注册逻辑。用withStorageKey独立持久化把 reducer 的默认导出改为export default withStorageKey( subject, combinedReducer )。确保每个 selector / action creator 导入 init凡访问该状态子树的模块都加上import calypso/state/subject/init包括散落在 client/state/selectors 的跨子树 selector 和直接内联读取 state 的组件——后一种情况通常值得顺手重构为正式 selector。从 legacy 根 reducer 移除完成以上改造后把该 reducer 从 client/state/reducer.js以及 client/landing/login/store登录入口有独立的 reducer 清单中删除。常见问题排查Reducer with key foo is already registered通常意味着忘记把该子树从client/state/reducer或登录入口的 reducer 清单中移除或者 init 文件中用了错误的 key例如复制粘贴串用了其他子树的名称。底层抛错位置在 reducer-utils.ts当沿 keyPath 递归到最终位置却发现已有 reducer 占用时会抛出该错误模块化机制本身也会防止同一子树被初始化两次。模块化后单元测试失败某些测试在模块化后开始失败往往是因为测试自行创建了 Redux store却没有配置好模块化机制。创建 store 后需要调用setStore把它设为全局 storeimport { createReduxStore } from calypso/state; import { setStore } from calypso/state/redux-store; import Thing from ../; describe( Thing, () { test( renders correctly, () { const store createReduxStore(); setStore( store, currentUserId ); // Instantiate and test component } ); } );setStoreredux-store.ts在替换既有 store 时会先清空已注册 reducer再把注册队列中的全部 reducer 同步补挂到新 store 上确保测试环境与生产环境的行为一致。迁移现状与演进方向截至当前仓库状态client/state/reducer.js 中静态加载的 legacy reducer 只剩currentUser、dataRequests、sites三个其余大量状态子树reader、comments、domains、themes、sites之外的各种业务模块均已走模块化注册路径。Calypso 正在持续迁移剩余状态随着迁移推进index.js中静态加载的 reducer 数量会逐步归零最终全部状态加载都经由模块化方式完成——这正是 client/state/README.md 描述的演进终点。总结Calypso 的状态管理方案可以概括为三点用模块化注册解决启动性能——init文件 registerReducer让 reducer 随依赖图按需进包用组合工具简化 reducer 编写——keyedReducer把集合型状态还原为单对象逻辑、withSchemaValidation守护持久化数据的安全回放用统一目录与存储约定保障可维护性——子树代码集中于client/state/name持久化通过withStorageKey各自独立落盘。无论你是要在 Calypso 中新增状态子树还是想理解大型 Redux 应用如何做规模化演进这套模式都值得直接借鉴。赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐终极指南如何使用redux-persist实现Redux状态的模块化持久化终极指南如何使用redux persist实现Redux状态的模块化持久化 在现代Web应用开发中Redux作为状态管理库被广泛使用但页面刷新后状态丢失的前端wp-calypso状态管理揭秘Modularized State模块化状态设计原理深度解析wp calypso状态管理揭秘Modularized State模块化状态设计原理深度解析 wp calypso 是 WordPress.com 的前端应用前端CMSFlutter-Notebook状态管理Redux持久化实现Flutter Notebook状态管理Redux持久化实现 在移动应用开发中状态管理是确保用户体验流畅的核心环节。当应用需要在重启后保留用户数据或界面状态示例工程移动开发上一篇CAMEL 函数风险治理机制解析FunctionRiskToolkit 与 IgnoreRiskToolkit 在 LLMGuardRuntime 中的实践下一篇Apache DataFusion 14.0.0 版本全解析表达式简化重构、Parquet 过滤下推与 SQL 配置能力增强创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考