前端【免费下载链接】hyperapp1kB-ish JavaScript framework for building hypertext applications项目地址https://gitcode.com/gh_mirrors/hy/hyperapp点击查看免费下载本文以 Hyperapp 架构文档中的 views.md 为核心系统讲解视图View这一贯穿整个框架的核心概念如何用h()、text()、memo()三个构建块声明式地描述界面、如何组合组件、如何借助虚拟 DOM 与记忆化优化渲染性能并结合 index.js 源码剖析其底层实现。读完本文你将掌握 Hyperapp 视图的定义、签名、组件化、条件渲染、DOM 复用Recycling、Keys 与 Memoization 的完整实战方案。什么是视图View定义一个view视图是对“应该渲染什么”的声明式描述并且通常受当前 state状态 影响。在 Hyperapp 中视图被实现为一个纯函数它接收当前状态返回一个 虚拟 DOM 节点VNode。当发生 状态转换 时你的视图会自动随之更新无需手动操作 DOM。签名View : (State) - VNode纯函数的性质决定了视图具备两大优势一是可预测——相同输入永远得到相同输出方便测试与调试二是自动同步——Hyperapp 内部会在状态变化时重新调用视图并 diff 新旧 VNode把变更精确地落到真实 DOM 上。这一点可以从 index.js 的update()与render()实现得到印证每当state引用发生变化框架便通过requestAnimationFrame调度一次render而render就是调用顶层view(state)得到新的 VNode 树再交给patch进行差异更新。描述视图三大构建块视图的构建块是h()、text()和memo()三个函数。h()创建元素节点并绑定动作h()不仅描述使用了哪些 HTML 元素还负责挂接 actions动作——比如把onclick事件与某个 action 关联起来const view (state) h( button, { class: { calling-acid-burn: state.beingFramed }, onclick: FindThatDisk, }, text(Its in that place where I put that thing that time.) )其签名为h(tag, props, children?)tag可以是任意 HTML、SVG 或自定义元素名props是属性对象class、style、key、on*事件等children可以是单个 VNode 或 VNode 数组。从源码 index.js 可以看到h()内部会把class统一规范化为字符串见createClass支持字符串、对象、嵌套数组三种格式的递归合并并把children统一包装成数组。text()创建文本节点text()仅用于创建文本节点因此单独用它构成的视图必然是极简的const view () text(Go home and be a family man!)注意text()接收的content在语义上应当是字符串或数字——虽然技术上可以传入任何值但最终用于渲染的只是它的字符串化结果。源码 index.js 显示text(value, node)会生成一个type TEXT_NODE即 3的特殊 VNodetag字段即文本内容。memo()包装其他视图函数memo()的设计目的是配合其他产生 VNode 的函数使用因此它本身并不直接“描述”一个视图而是对视图做缓存包装const view (state) memo(scenicView, state.vacationSpot)其签名为memo(view, data)把view函数与一份可索引数据data打包成一个 VNode只有当这份数据发生变化时才重新计算被包装的视图。在源码 index.js 中memo只是简单地生成{ tag: view, memo: data }这样的结构真正的判断逻辑在maybeVNodeindex.js中当tag是函数且propsChanged(oldVNode.memo, newVNode.memo)返回真时才会重新调用视图函数否则复用旧的 VNode。组件Components视图天然是可组合的因此组件可以简单也可以复杂。小型应用可能只需要一个视图而大型应用通常会拆出大量子视图。定义Hyperapp 中的component组件既可以是子视图subview也可以是任何其他能生成 VNode 的函数。签名Component : (GlobalState | PartialState) - VNode | [...VNodes]组件通常是 UI 的“积木式”小部件而仪表盘、页面这类较大的 UI 片段则是由这些小部件组装而成的。注意组件不拥有自己的局部状态——正如 state 文档 所说Hyperapp 对状态结构不做强约束组件可以直接访问整个状态的任意部分这既是灵活性也是责任所在。下面这个例子中coinsDisplay是以子视图形式存在的组件直接关心全局状态而questionBlock则是返回 VNode 的函数组件只关心传入的部分状态// Component : (GlobalState) - VNode const coinsDisplay (state) h(div, { class: coins-display }, text(state.coins)) // Component : (PartialState) - VNode const questionBlock (opened) opened ? h(button, { class: question-block opened }, text(?)) : h( button, { class: question-block, onclick: [ HitBlockFromBottom, { revealItem: beanstalk }, ], }, text(?) ) // Component : (GlobalState) - VNode const level (state) h(div, { class: level }, [ coinsDisplay(state), questionBlock(state.onlyQuestionBlockOpened), ])注意onclick使用了action 描述符action descriptor语法[Action, Payload]——这正是 actions 文档 中“给 action 传 payload”的标准方式类型层面由 index.d.ts 的CustomPayloads约束。命名建议组件推荐使用camelCase命名并采用能简洁描述“被组合元素群用途”的名词例如articleHeader、questionBlock。返回多个 VNode 的组件组件允许返回 VNode 数组。但如果要把这种组件用在兄弟节点列表中就需要对其结果做展开spread// Component : () - [...VNodes] const finishingMoveOptions () [ h(button, { onclick: FinishHim }, text(Fatality)), h(button, { onclick: FinishHimAsAnAnimal }, text(Animality)), h(button, { onclick: TurnHimIntoABaby }, text(Babality)), h(button, { onclick: BefriendHim }, text(Friendship)), ] const view () h(div, {}, [ h(em, {}, text(Finish them:)), ...finishingMoveOptions(), ])这里的核心原因在于h()的children参数本身就是一个 VNode 数组如果把数组组件整体塞进去就会形成“数组中套数组”的嵌套结构只有展开后才能与em等兄弟节点平级。从 index.js 可以看到h()仅对children做一次数组化isArray(children) ? children : [children]并不会递归扁平化因此展开是必须的。使用视图顶层视图Top-Level View每个 Hyperapp 应用都有一个涵盖其他所有视图的基础视图即通过app()的view:属性定义的顶层视图。当状态被初始化或每次更新时Hyperapp 都会自动调用该视图并传入当前状态app({ // ... view: (state) h(main, {}, [ earthrealm(state), edenia(state), ]), })关于view:还有几点值得注意参见 app.md一个应用只能有一个顶层视图只要状态变化view:函数就会被重新调用用新状态渲染 UIview:与node:是成对出现的只要提供了view:就必须同时提供node:挂载节点。从类型定义 index.d.ts 的AtLeastSomething约束可以看出viewnode是app()必选属性组之一app()返回的 dispatch 函数可让应用外部控制状态变化适合“页面只有一部分用 Hyperapp 实现”的场景。条件渲染Conditional Rendering视图的某些元素可以有条件地显示或隐藏。由于h()的children允许出现false、null、undefined等值在类型层面由MaybeVNodeS描述见 index.d.ts所以可以直接用 JavaScript 的布尔表达式控制渲染const view (state) h(div, {}, [ state.flying h(div, {}, text(Flying)), state.notSwimming || h(div, {}, text(Swimming)), ])state.flying ...在flying为假时求值为false该节点不会被渲染state.notSwimming || ...则相反——notSwimming为真时直接短路跳过渲染。在源码层面maybeVNodeindex.js会把true/false/空值统一替换为空的文本节点text()保证 diff 算法的输入始终是结构合法的 VNode 树。复用RecyclingHyperapp 开箱即用地支持视图的hydration水合。如果指定的挂载节点mount node中已经填充了 DOM 元素Hyperapp 会回收并复用这些既有元素而不是丢弃它们重新创建。这可以用于 SSR服务端渲染或预渲染pre-rendering场景从而获得 SEO 与性能收益!-- 挂载节点内预填充内容 -- main idapp!-- 服务端渲染出的 HTML --/mainapp({ // ... node: document.getElementById(app), })其底层机制在 index.js 的recycleNode函数中app()启动时会遍历挂载节点的现有子节点把文本节点转换为text()节点、元素节点转换为带有SSR_NODEtype 1标记的普通元素 VNode。这个标记非常重要——在patch算法中当oldVNode.type SSR_NODE时会走特殊分支index.js允许带 key 的旧节点按位置直接复用避免误删服务端渲染的内容。此外patch会先做属性对比index.js只有value、selected、checked等特殊属性以 DOM 当前值比较其余属性仅当新旧值不同才调用patchProperty更新从而最大化复用效率。虚拟 DOMVirtual DOM定义虚拟 DOMVDOM是当前页面上已存在 DOM 元素的内存中表示。Hyperapp 用它来决定如何高效地更新真实 DOM。虚拟 DOM 是一种树形数据结构其中每个节点代表一个可能被渲染、也可能不被渲染的 VDOM 元素。前面已经看到h()、text()、memo()分别返回不同类型的 VNodeh()→ 元素节点type为 1对应Node.ELEMENT_NODEtext()→ 文本节点type为 3对应Node.TEXT_NODEmemo()→ 一个“惰性”节点tag是被包装的视图函数memo字段存的是传入的数据。这些 VNode 结构定义在 index.js 的createVNode中{ tag, props, key, children, type, node }其中node字段在渲染后被填充为对应的真实 DOM 元素供后续 diff 直接定位。修补 DOMPatching the DOM当 Hyperapp 准备更新 DOM 时会从顶层视图的根 VNode所对应的元素开始。它检查该 VNode 所代表元素是否发生变化如果发生变化该元素会被重新渲染然后对根 VNode 的每个子节点递归重复这一过程。这一过程对应 index.js 的patch(parent, node, oldVNode, newVNode, ...)递归算法其核心策略是引用相等短路oldVNode newVNode时直接跳过——这正是记忆化能生效的前提文本节点快路径新旧都是文本节点时仅当内容不同才更新nodeValue元素类型变化oldVNode.tag ! newVNode.tag时创建新节点、移除旧节点同类型元素先对比并修补属性然后对子节点采用头尾双指针 key 映射的 diff 策略从两端向中间收敛避免全量遍历最后把新 VNode 的node字段指向真实 DOM 元素并返回供上层递归继续使用。Keys有时 Hyperapp 需要帮助才能确定某些元素是如何变化的。这种情况通常出现在基于状态中的数组渲染出的 VNode上数组项在状态变化时可能大量移位因此渲染后代表它们的 VNode 可能与之前完全不同。既然 Hyperapp 无法确切知道它只能假设一切皆变导致每次都做一次完整渲染。为数组项提供稳定的key就能让 diff 算法识别“同一项”从而只移动、新增或删除发生变化的元素。在patch的中间收敛逻辑中index.js旧子节点会按key建立映射表keyed新子节点带着key过来时先在表中查找命中则直接移动并复用对应 DOM 节点。用法示例参见h()的key:文档const pokedex (pokemon) h( ul, {}, pokemon.map((p) h(li, { key: p.id }, text(p.name))) )建议用数据中天然唯一的 id如p.id作为key避免使用数组下标否则重排时依然会引发错误复用。记忆化Memoization记忆化是一种优化技术把某次计算的结果存储起来供未来直接复用避免重复计算的开销。Hyperapp 中的记忆化针对的是VNode 的渲染过程通过memo()实现。当被记忆的视图重新渲染时它接收到的“state”实际上是建立记忆时定义给该视图的 props即memo()的第二个参数data。Hyperapp 的不可变性保证如果两个值引用相等它们必然完全相同。因此只有当传入的 props 发生变化时Hyperapp 才重新计算被记忆的组件这是安全且高效的。具体到源码maybeVNodeindex.js对函数型tag的判断逻辑是当旧 VNode 没有memo记录或propsChanged(oldVNode.memo, newVNode.memo)检测到新旧数据不同两个对象逐键做!比较见 index.js时才调用newVNode.tag(newVNode.memo)重新渲染否则直接复用旧的渲染结果。完整可运行的示例包括“改变列表影响普通视图但不影响记忆化视图”的对照实验见memo()文档。性能注意事项记忆化是为了提升渲染性能但它不是万能药。如果用它包装那些需要在每次状态变化时都更新的节点那么“渲染前先检查 props 是否变化”的额外开销反而会成为长期的净性能损失。记忆化适合完全不需要更新或只是偶尔更新的节点正如 memo.md 所强调的过度使用memo()会导致性能下降只有在确定能改善渲染时才使用拿不准就做基准测试benchmark还有一个 Memo Data GotchaHyperapp 对 memo 数据做的是逐索引index-for-index比较因此字符串与数组这类可索引类型可能在某些边界情况下被判定为“相等”而跳过重渲染。例如ab与[a,b]逐索引比较结果相同若在数组与字符串之间来回切换状态格式记忆化视图可能不会如预期地更新。最后与所有优化一样务必测量你的应用性能确认真正获得收益后再采用并根据测量结果随时调整。小结Hyperapp 的视图体系是一条完整链路纯函数式的view(state)定义 →h()/text()/memo()构建 VNode 树 →app()挂载并驱动顶层视图 → 状态变化触发patch递归 diff → 最小化更新真实 DOM。组件化让视图可以按需拆分组合条件渲染与 Recycling 让视图在 SSR/预渲染场景下直接可用Keys 与 Memoization 则是应对数组渲染和性能瓶颈的两大关键手段。相关 API 与源码均可继续查阅h()、text()、memo()、app()、actions 架构、state 架构、effects 架构以及核心实现 index.js 与类型定义 index.d.ts。赞分享前端【免费下载链接】hyperapp1kB-ish JavaScript framework for building hypertext applications项目地址https://gitcode.com/gh_mirrors/hy/hyperapp点击查看免费下载相关推荐OpenTUI 声明式渲染树组合指南从 h() 到 vnode、mount 与 delegateOpenTUI 声明式渲染树组合指南从 h 到 vnode、mount 与 delegate 导读 本文聚焦 OpenTUI 核心包中 compositionUI组件CLI跨平台Hyperapp 的 h() 函数从虚拟 DOM 节点到视图构建的完整指南Hyperapp 的 h 函数从虚拟 DOM 节点到视图构建的完整指南 导读 h 是 Hyperapp 中创建 虚拟 DOM 节点VNode https:前端终极指南Xilem框架四层架构深度解析—从声明式编程到高效渲染终极指南Xilem框架四层架构深度解析—从声明式编程到高效渲染 Xilem是一个实验性的Rust原生UI框架采用先进的响应式架构通过四层设计实现高效的界面前端桌面应用上一篇Flink数据湖集成实战Iceberg、Hudi、DeltaLake对比下一篇KTransformers支持的先进模型优化案例创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考