Hyperapp是一个轻量级视图库,拥有完备的界面渲染、以及视图数据交互更新能力。专一于视图渲染的核心部分,使得它的体积很是轻巧,也使得它具有"无限可能"。在设计上并没有涉及太多复杂场景,尤其适用于轻量级的移动开发场景。html
Hyperapp
仅关心状态渲染、调度生成后actions对象。在状态管理上,咱们能够自主使用flux
、redux
,甚至无需使用任何状态管理库。node
Hyperapp
提供vnode
生成辅助函数,但并不限制渲染模板的选择,咱们能够自由选择相似JSX
,甚至类VUE
的模板语言。webpack
在Hyperapp
初始渲染以后,触发视图更新的惟一方式是,经过调用action
变动状态,从而触发视图更新。这使得咱们能够创建易于跟踪、健壮、可维性强的应用。git
详细的分析,能够在源码注释仓库下看到,里面有hyperapp
各个源码重要细节的分析。下面来介绍一下hyperapp
源码有意思的地方:github
专一于视图渲染&数据交互更新,在实现上也是恰到好处地实现这些功能。具有内置状态驱动的视图更新引擎、标准VNode
四板斧、DOM-diff
机制。在这点来讲,hyperapp
处于新生期,须要具有完善的生态,才能够发挥出强大的内核能力。web
VNode四板斧:redux
// 基本的HTML标签均可以被抽象成以下形式: // { // nodeName, // attributes, // children, // key // } // TextNode只有一个nodeValue,SVG也是比较特殊,因此在更新时候也会对这两种类型作特殊处理
DOM-diff 原则:app
// 1. 平级对比,非平级则认为是不同的dom,直接铲平重建 // 2. 只更新同类型节点,非同类型同样铲平重建 // 3. 尽量利用现有dom,免除额外的删除建立开销,只须要从新插入(appendChild or insertBefore) // 4. index&key相同的vdom,对应的dom无需对比,直接复用,下一个!
hyperapp
在细看一些实现上,会以为有些"不严谨",可能会被钻空子。好比:clone、get等函数实现,或者是Promise、Array的判断。dom
事实上,这些函数用于在有标准DOM结构的实现、自调用的源码上,做为判断能达到"刚恰好"的要求。既不会浪费性能体积,也不会致使出错。异步
function get(path, source) { for (var i = 0; i < path.length; i++) { source = source[path[i]] } return source } // const result = { winner: { name: 'Tony' } } // get(['winner', 'name'], result) => Tony
没必要具有lodash get
的兼容性,以最优形态抽象出适用于源码的函数,即是最好的。
说出来你可能不信,hyperapp
仅有四个生命周期函数。
他们分别是:
视图渲染
oncreate(DOMElement)
onupdate(DOMElement)
视图销毁
销毁前执行:
onremove(DOMElement, action)
销毁前通知:
ondestory(DOMElement)
这使得hyperapp
比较适用于轻交互场景,配合webpack
的模板语法编译能力,能够实现很是轻量级的移动应用。
在列表渲染时候,hyperapp
严格要求组件提供对应key
属性。
若是没有对应的key
,至关于默认每次渲染都是全新的列表,这会涉及到原有列表DOM
的销毁、新列表DOM
建立以及添加,大型列表上有可能会致使性能问题。
也正由于这个特性,使得在良好结构下,hyperapp
的渲染性能表现不亚于现有主流渲染库。
Hyperapp
虽然精巧,却彻底支持SSR
特性。在初次渲染时候,会将现有DOM
结构转成vdom
,当有行为触发数据变更时,高效进行dom-diff
以更新现有视图。