Guided Tours 未来架构演进指南：Calypso 引导框架的懒加载、状态感知与 actionLog 规模化

前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载导读本文基于 wp-calypso 仓库中client/layout/guided-tours/docs/ARCHITECTURE-FUTURE.md的原始设计思考系统梳理 CalypsoWordPress.com 的 JavaScript 前端中 Guided Tours 引导框架的未来架构演进路线包括如何让全部 tour 配置与组件支持懒加载、如何引入状态感知state-aware的动态步骤、如何理解actionLog的动作日志本质以及当动作日志随业务增长后如何优化 selector 的求值性能。读完本文你将理解该框架当前实现的取舍掌握其设计者留下的四类规模化优化思路流式处理、持久化数据结构、深度动作映射、动作类型拆分并能对照仓库源码验证哪些设想已经落地、哪些仍待实现。阅读前建议先了解框架的现有架构可参考同目录下的 ARCHITECTURE.md希望编写自己的 tour 的读者可先阅读 TUTORIAL.md。一、为什么需要一份未来架构文档Guided Tours 作为一套框架已经开放给第三方编写自己的 tour见 TUTORIAL.md。正因为框架逐渐对外作者认为有必要把关于系统演进方向的想法沉淀成文以降低bus factor核心知识只集中在少数人脑中的风险。这份 ARCHITECTURE-FUTURE.md 由此诞生——它不是对现状的说明而是对未来可能性的探讨涵盖四个主题懒加载Lazy loading如何缩减主 bundle、按需加载 tour。状态感知的步骤State-aware steps让Step支持实时响应 state 的动态渲染。actionLog的本质为什么它天然等价于一个流stream。让actionLog规模化应对动作日志不断增长时的性能优化候选方案。下文逐一展开并在每个主题中对照当前仓库源码指出哪些设想已经落地、哪些仍然开放。二、懒加载把 Guided Tours 从主 bundle 中剥离2.1 动机主 bundle 的明显罪状设计文档指出在保持 Calypso 主 bundle 精简、不携带用户大概率用不到的内容这一前提下Guided Tours 当时存在三个明显的体积问题所有 tour 配置视图 逻辑被系统性加载而大多数用户在一次会话中只会看到 0 或 1 个 tour即使没有任何 tour 被触发整套 Guided Tours 组件含一批永远不会渲染的组件也会被加载即使确实要触发 tour也不必在 Calypso 刚加载的瞬间就展示因此加载可以被延迟。2.2 当时的体积基线2017 年 8 月数据文档记录了当时 Guided Tours 对主 bundlebuild的影响模块体积layout/guided-tours视图层、辅助函数、各 tour 配置76 KB stat / 43 KB parsed / 9 KB gzippedstate/ui/action-log原始源码不含 test2.5 KB / 1 KB gzippedstate/guided-tours原始源码不含 test15 KB / 4 KB gzipped作者指出yarn run analyze-bundles对后两者无法给出细粒度数据。值得注意的是当时的结论是由于尚未支持state 分支的懒加载state/ui/action-log必须持续收集信息、state/guided-tours必须运行 selector 来判断是否有 tour 要触发——好在它们恰好是体积最小的部分其余部分视图层与 tour 配置都可以懒加载。2.3 两种切分方案文档规划了两级懒加载策略1Easy chunk整体懒加载GuidedTours /第一步最简单在layout中渲染的根组件GuidedTours /整体走懒加载。文档强调这一步的实际收益需要用真正的测试来验证。从当前仓库看这一步已经落地。index.jsx 中的实现与文档设想几乎一一对应const loadComponent () import( /* webpackChunkName: async-load-calypso-layout-guided-tours-component */ ./component ); function GuidedTours() { // ...通过 getGuidedTourState 判断 shouldShow if ( ! shouldShow ) { return null; } return AsyncLoad require{ loadComponent } /; }即外层组件先通过 selector 判断是否需要展示 tourshouldShow只有确认需要时才通过AsyncLoad 动态import()加载真正的 component.jsx从而把整套视图层拆进名为async-load-calypso-layout-guided-tours-component的独立 chunk。2Finer-grained chunks按 tour 拆分随着 tour 数量增加当前 all-tours.js 已注册 9 个 tour配置清单见 config.js理想状态是先判断是否触发某个 tour再按需加载该 tour 的步骤。前提是tour 的触发条件triggering conditions放在 Guided Tours 的基础 chunk中tour 的其余部分步骤 steps——包含跳转/继续逻辑与 UI 片段放在更小的独立 chunk中。文档给出了两条实现路线方案优点缺点手动解耦遍历每个 tour 配置把顶层属性name、version、path、when集中到公共位置实现简单需要改变 tour 开发者的编写接口编写 Webpack loader编程式地把触发条件聚合到一个模块先例是server/bundler中重写sections.js的 loader魔法式tour 作者无需关心 chunk 划分实现更难、易产生困惑当前仓库里tour 的触发元数据仍以 meta.js 这类文件静态定义含name、version、path、when字段并由 config.js 统一汇总——即细粒度按 tour 拆分尚未实现仍停留在文档所描述的理想状态。这恰恰说明这份未来架构文档至今仍具参考价值。三、状态感知的步骤State-aware steps3.1 设想从静态when到实时渲染函数当前的Step组件通过when属性做条件判断。文档设想在未来的某个版本中支持真正的动态、状态感知步骤其素材来自 PR #10436editortourpr中的 diff 与关帖前的最后几条评论。核心区别如下默认行为不受影响——静态whenStep name… when{ isSomethingSomething } pWelcome!/p… /Step;新的实时状态感知行为——children 改为接收 state 的 render propStep name…{ ( state ) isSomethingSomething( state ) pWelcome!/p }/Step;3.2 与当前实现的对照从当前源码看Step的when判断仍采用selector 求值方式。step.tsx 中通过上下文提供的isValid来判断条件是否成立if ( when ! ( this.context as SectionContext ).isValid( when ) ) { return null; }而在 component.jsx 中isValid被实现为对when函数进行即时求值const getTourWhenState ( state ) ( when ) !! when( state );也就是说当条件满足时展示某一步的能力已经存在但文档所设想的children 直接作为( state ) JSX渲染函数的动态形式尚未实现。文档提示这一增强将改变Step的 children 契约属于未来的 breaking change有兴趣的读者可以直接参考 PR #10436 的讨论来推进。四、actionLog的本质它是一个流stream4.1 为什么是流actionLog1是 Guided Tours 依赖的核心数据结构它是动作actions即事件的集合并且随时间增长只朝一个方向增长。因此它天然等价于一个流stream——尽管这个概念在当时以及现在的 Calypso 中几乎没有被使用过。4.2 流式操作与现有操作的对应关系对actionLog的大多数处理方式——map、filter、reduce、find——在流式处理体系里都有对应的操作符。认识到这一点很重要任何成熟的流处理库如 RxJS在这些操作上都经过高度优化远超手写的基础缓存 启发式方案。当前仓库对actionLog的消费方式印证了这一点。selectors/index.js 中getToursFromFeaturesReached正是对getActionLog做filter筛出ROUTE_SET、reverse、flatMap的典型例子const navigationActions getActionLog( state ) .filter( ( { type } ) type ROUTE_SET ) .reverse(); const matchingTours navigationActions.flatMap( ( action ) guidedToursConfig.filter( ( tour ) tourMatchesPath( tour, action.path ) ) );此外action-log/selectors.js 还提供了getLastAction取日志最后一项。文档正是在提示这些手动实现的操作理论上都可以映射为流操作符从而获得更好的性能与表达能力。五、让actionLog规模化性能问题与四条候选方案5.1 问题的根源订阅类型只会越来越多按设计actionLog的 reducer 会对经过 dispatcher 的所有动作做出反应。文档写作时订阅的类型列表[relevant types]还相对有限GUIDED_TOUR_UPDATE THEMES_RECEIVE ROUTE_SET SITE_SETTINGS_RECEIVE对照当前实现 reducer.js这个列表已经演进为const relevantTypes { GUIDED_TOUR_UPDATE, THEMES_REQUEST_SUCCESS, // 原 THEMES_RECEIVE 已演化为请求成功动作 ROUTE_SET, SITE_SETTINGS_RECEIVE, };并且新增了带 analytics meta 的动作calypso_themeshowcase_theme_click也会被记录——这一点下文 5.5 节还会提到。同时reducer 将日志限制为最近 50 条maybeAdd中.slice( -50 )并给每条动作打上Date.now()时间戳测试 reducer.js test 对此有完整覆盖。文档明确指出了三个只会更糟的趋势未来 Guided Tours 越多订阅的动作类型列表只会增长加入日志的动作类型没有种类限制——从导航、到请求成功的信号、再到具体的用户交互信号其中一部分动作会被非常频繁地触发如ROUTE_SET。5.2 性能影响的机理每次actionLog变化Guided Tours 的主 selector 都会被新 state 重新调用——无论当前是否有 tour 在运行。当时作者认为问题尚可接受靠两点缓解大量使用createSelector做记忆化memoization 简单的缓存启发式订阅的动作类型集合仍然有限。但隐患在于一旦 selector 需要完全重算整个actionLog都要重新遍历一遍——所有子 selector 会在最新的actionLog上执行多次map、reduce等操作即使其中大部分条目在上一版actionLog中已经被处理过。关于为何还没优化文档的立场是过早优化通常是有害的因此这些想法只是为将来某天做储备——那一天要么来自细致的 profiling理想情况要么来自不得已的直觉最坏情况。接下来是四条候选方案其中部分可组合、部分互相排斥。5.3 方案一引入流Streams / RxJS既然actionLog本质是流最直接的方案就是引入 RxJS改进成本最低因为 RxJS 操作符天然适配且针对actionLog这类数据做了优化。但作者冷静地给出了现实评估采用 RxJS 不只是引入一个大库压缩/未压缩30.1/138 KB更是引入一整套新的编程范式。文档原话是尽管我很希望这发生但短期内可能不会。从仓库现状看Calypso 目前并未在 Guided Tours 中采用 RxJS——该设想仍未实施。5.4 方案二持久化数据结构核心思想monoid 与分治这套方案的目标是用一组针对actionLog优化的函数mapActionLog、filterActionLog等替换标准数组遍历。由于actionLog是一个 monoid幺半群任何对它的操作f都可以按**分治divide and conquer**方式分解。特别地f( [ A, B, C ] ) join( f( [ A, B ] ), f( [ C ] ) );其中join是针对f的专用合并函数。利用记忆化跳过全量遍历由于 selector 会对每个新版本的actionLog运行当我们需要计算f( [ A, B, C ] )时很可能已经算过f( [ A, B ] )于是可以复用缓存f( [ A, B, C ] ) join( cached, f( [ C ] ) );从而避免遍历整个actionLog。各遍历函数的分解形式文档逐一给出了基本遍历函数的分治分解从最简单的开始get( [ A, B, C ] ) join( get( [ A, B ] ), get( [ C ] ) ); join ( a, b ) a.concat( b );map( [ A, B, C ] ) join( map( [ A, B ] ), map( [ C ] ) ); join ( a, b ) a.concat( b );filter( [ A, B, C ] ) join( filter( [ A, B ] ), filter( [ C ] ) ); join ( a, b ) a.concat( b );find( [ A, B, C ], f ) join( find( [ A, B ], f ), find( [ C ], f ) ); join ( a, b ) a || b;reduce( [ A, B, C ], f, initial ) reduce( [ C ], f, reduce( [ A, B ], f, initial ) ); // 更简单的写法是不借助 join——除非我们拥有惰性求值lazy eval一个令人遗憾的注意事项JS 的集合用数组实现而非链表因此没有内置方式把集合表达为head新条目 tail其余部分即上一版本。要让上述函数族真正受益于缓存这正是整套方案的意义所在还需要把actionLog实现为基本的双向链表——无论手写还是用库。文档评价这不该很难但确实令人失望。5.5 方案三动作的深度映射A deep map of actions思路用深层次结构替代扁平日志彻底放弃扁平actionLog改用一个按数据类别聚合的深层结构。文档用三个示例说明不再收集ROUTE_SET而是维护导航分支const object { navigation: { lastSection: theme, lastPath: /theme/twentysixteen, history: [ /*...*/ ], }, };不再收集THEMES_RECEIVE/SITE_SETTINGS_RECEIVE而是维护请求分支const object { requests: { themes: { timestamp: 123456789, // last update }, sites: { /*...*/ }, }, };不再收集GUIDED_TOUR_UPDATE而是维护引导状态分支const object { guidedTours: { lastState: { /*...*/ }, }, };收益与代价主要收益有两点Guided Tours 的 selector 可以拥有更细粒度的缓存启发式例如依赖数组从宽泛的state [ state.ui.actionLog ]收窄为state [ state.ui.actionMap.requests.themes ]selector 通常可以更少地遍历大集合虽然大集合仍可能存在于actionMap内部。换句话说pro是只要方案足够健壮、能覆盖 Guided Tours 开发者可能抛出的所有场景selector 调用中的工作量会大幅下降速度会非常可观。con也很明确它不如actionLog灵活——后者只是记录所有必要状态而不提前派生derive这正是当初选择它的原因见 ARCHITECTURE.md日志方案承诺最少、各种 selector 可以互不冲突地消费同一份日志。深层结构要求预先规划数据的存放位置与方式此外一部分原本由 selector 承担的计算会被转移到 reducer 调用中。5.6 方案四区分不同种类的相关动作类型与前三条不同这是一个小幅增强不需要大改架构。当前actionLog把匹配relevantTypes的动作不加区分地收进同一个数组。该方案建议拆成两个数组relevantTourEntryTypes给定 Calypso 现有的 tours能够触发新 tour的动作类型relevantTourAdvancementTypes不用于触发新 tour仅用于把进行中的 tour 从一个步骤推进到下一个的动作类型。只要能把relevantTourEntryTypes维持在一个较小集合那么在确认没有 tour 进行中时就可以跳过大量 selector 调用。值得注意的是当前 reducer.js 已经出现了一个部分预演除了relevantTypes动作外还专门过滤带calypso_themeshowcase_theme_clickanalytics 事件的动作hasRelevantAnalytics/isRelevantAction相当于在按类型收集之外新增了按语义收集的维度。这与文档中从导航、请求成功信号到用户交互信号都可以入日志的预测高度吻合。六、现状盘点哪些设想已落地、哪些仍待探索结合当前仓库源码可以给出如下对照结论文档设想当前状态佐证懒加载GuidedTours /easy chunk已实现index.jsx 通过AsyncLoad 动态import()按需加载 component.jsx按 tour 细粒度拆分触发条件与步骤未实现config.js 仍静态汇总全部 tour 的 meta状态感知步骤children 即 render prop未实现step.tsx 仍使用whenisValid判断actionLog本质是流stream认知成立action-log/selectors.js 的getLastAction等消费方式引入 RxJS未实施仓库中未发现相关依赖持久化数据结构monoid 分治 缓存未实施仍是文档中的理论推导深度动作映射actionMap未实施state.ui.actionLog仍是扁平数组区分 entry / advancement 动作类型未实施但已有雏形reducer.js 已按 analytics 语义过滤动作七、结语这份 ARCHITECTURE-FUTURE.md 的价值不在于预测全部成真而在于它完整记录了 Guided Tours 在演进道路上已知的性能痛点与可行的解法空间体积问题已有清晰的分层拆解思路其中整体懒加载已被当前代码验证可行actionLog的流式本质为未来引入流处理或持久化数据结构提供了理论依据深度动作映射与动作类型拆分给出了把计算从 selector 前移/后移的两种不同权衡方向。对希望深入贡献 Guided Tours 的开发者建议从 selectors/index.js决策算法、reducer.js日志机制与 config-elements配置元素体系三个入口入手再回到本文对照每一条设想即可判断某项优化在今天的 Calypso 中是否仍然成立、值得动手。阅读前请先理解 ARCHITECTURE.md 中关于actionLog的基本架构。↩赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐在 Vite 构建中守护 TypeORM 迁移类名三种修复 JavaScript timestamp appended 报错的配置方案在 Vite 构建中守护 TypeORM 迁移类名三种修复 JavaScript timestamp appended 报错的配置方案 本文聚焦于一个非常前端CMS浏览器资源嗅探扩展猫抓3 步保存网页里的音视频文件浏览器资源嗅探扩展猫抓3 步保存网页里的音视频文件 猫抓cat catch是一款开源浏览器资源嗅探扩展它监听当前页面的网络请求把其中的音视频资源自动列前端CMSCivitai 引导式导览Guided Tours系统实现解析基于 react-joyride 的产品上手引导架构Civitai 引导式导览Guided Tours系统实现解析基于 react joyride 的产品上手引导架构 导读 本文深入解析 Civitai 前后端前端AI 应用上一篇Replay.io DevTools团队协作功能如何高效共享与重现调试会话下一篇在 microsoft/fast-element 中集成 MobX基于每个组件一个 autorun 的零桥接状态管理模式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考