FDCon2019 第4届中国前端开发者千人峰会 - 《Omi - Cross-Frameworks Framework》

你们好，此次给你们讲下 Omi 框架 以及即将发布的 Omim 你们有没有数左边的图片里有多少个 Omi？Omi 团队很在乎这里，特地数了下，有三个。Omi 团队但愿 Omi 之后在各大会议里可以印刷得更加大一些。今天给你们带来的主题是 《Omi - Cross-Frameworks Framework》，这也是 Omi 最新的 slogan。Omi 基于 Web Components 设计，和三大框架并非你死我活的关系，能够很好的共存，无缝地集成，等听完这个分享你们就能 get 到 Omi 的精髓。子标题的灵感来自于 preact 做者之前打算分享的《Push react to the limit》，原本 TFC2017 邀请了他，后来我的缘由他没有来，固然他后来去了google，可能这个标题政治不正确:)。

这是此次分享所包含的内容，不是目录。会涉及到上面4部份内容。

第一部分讲下 Omi & Web Components。

Omi 准确来讲是 5-6年前开始弄的，可是真正切换到 shadow dom v1 仍是2018年10月份左右，比 google 的 angular 更早使用 shadow dom v1。切换以后，获得了一段快速发展的时期，一致延续到如今。当时是什么初衷让我开始打造 Omi？

先来看看 react 的生命周期。当年看 React 的生命周期函数太长并且太多了，因此我要写个生命周期函数更短且更少的框架，好比 Omi 的(install, uninstall, installed)，并且贴合 npm 的命令:)。

看下 Omi 中的生命周期，没有与对应的 shouldComponentUpdate对应的生命周期函数，没有 state 初始化、没有 constructer 函数，生命周期函数命名更加端、生命周期函数更加少。大道至简是真理，Omi 但愿开发者不用手动优化 shouldComponentUpdate，怎么作到的，后面 PPT 会讲。

打造 Omi 的初衷，还有一点很是重要的是，scoped css！scoped css 可让组件的 css 选择器更加简洁，好比能够直接写 tag selector，若是组件里只有一个 h1 的话。

h1 {
  color: red;
}
复制代码

这个 h1 不会污染组件外部的 h1，也不会污染组件内部的组件的 h1。

来看下 ng。ng 支持四种模式

• 模拟 scope
• shadow dom v0（不推荐，在将来版本去掉）
• 无 scope
• shadow dom v1

这是第一种模式，ng 模拟 scope 生成的 html 结构，每一个元素和子元素都会加上 scope attr。

这是第三种模式，html 结构什么 attr 都不加。

这是第四种模式，也就是 shadow dom 的模式，和 Omi 同样。

Omio 使用的也是 scope attr 模拟 shadow dom，这里在内部实现的时候有两点须要注意：

• scoped attr 须要加到组件内部全部的子元素上，包括组件内部的组件自己
• scoped attr 须要加到组件内部全部的子元素上，不包括组件内部的组件的子元素

有点绕，仔细体会下。即 scoped 到组件为止，包括组件不进入组件。

这是 Omi 和 React 生成的 dom 结构对比。Omi 使用 shadow dom 进行隔离。

来看这张图，很关键。这张图来自 twiter。twiter 有个问题是 web components 能不能替换掉整个框架？stencil 团队 show 出了这张图，给 Omi 团队带来了很大的灵感。Omi 不只仅要自带状态管理、自带组件体系替换掉整个框架，也能输出单一的 custom elements 和任意框架集成。仔细看上图，stencil 在各个框架中使用仍是有一些差别。

Omi 作得更加完全！全部框架使用 custom elements 方式如出一辙！彻底不用记忆差别，只靠肌肉记忆编程！Omi 的组件变动也是彻底基于 setAttribute 和 removeAttribut，这种设计关键，由于其余框架无论 vdom 仍是 real dom，最后都须要操做 dom 的 attribute，操做 attribute 就能进入到 Omi 的元素周期内部，这样就无缝勾住了，在任意框架都能使用 Omi 写的 custom elements。这里有一点须要注意：

• 若是使用 Omi 写的 custom element 想要跨框架使用，必须声明 static propTypes

这个其实也不麻烦，由于若是你使用 typescript 写组件的话，自己就须要声明 props 的类型，改为大写就能用在 propTypes 上。Omi 内部会根据声明的类型，把使用组件时候传入的字符串转化为对应的类型。

来看个实际的例子，这个 m-button 能够在任意框架中使用。须要注意的是，能够传递 json 字符串做为 attr 给 m-button 内部使用。能够看到上面的 icon 的 paths 并非标准的 json，可是没有关系，omi 内部会转成标准 json 再进行 JSON.parse 。并且你能够直接使用 setAttribute 设置 json。

const btn = document.querySelector('m-button')
btn.setAttribute('icon',  {
  path: 'xx',
  color: 'xxx'
})
复制代码

这里须要注意一下，若是你再 react 中使用 Omi 的 element，并且须要传递 json 的话，能够包裹一下 Omi.o，免得手动转成字符串:

class TestOmiElement extends React.Component {
  render() {
    return (
    <div> <m-button icon={Omi.o({ path: 'xxx', color: 'xxxx' })}>omi button</m-button> </div> ); } } 复制代码

这是 Omi 的初始化管线，前面说了 Omi 利用了 HTMLElement 钩子函数 connectedCallback 监听自定义元素插入到 dom 的行为，这个行为多是 Omi 触发的，也能够是 react、vue、ng 或原生 js 触发的，触发以后就进入了 Omi 的内部管线。

• 建立 shadow dom
• 建立 style 并插入到 shadow dom
• 执行 render 建立虚拟 dom 并保存一份方便下次 update 的时候 diff
• 根据虚拟 dom 生成 真实 dom 并插入到 shadow dom

很清晰简明的管线。JSX 生成的虚拟 dom 会挂载在真实 dom 的 __omiattr_ 属性上用于 dfii。 有没有必有使用虚拟 dom？有必要！固然也能够修改 h 函数保存真实 dom 用于 diff，主要区别在于内存开销，速度差异不大。由于虚拟 dom 更轻量，属性更少，都是必要属性，因此用虚拟 dom。

看下 web components 最经常使用的三个生命周期函数。在 connectedCallback 会去执行 Omi 的 install，在 disconnectedCallback 会去执行 Omi 的 uninstall，最后一个 attributeChangedCallback 在 Omi 内部并无使用，由于 Omi 重写了自定义元素的 setAttribute，从源头上已经能够监控到 attr change。

看下这段从 Omi 扒出来的源码，Omi 重写了 removeAttribute 和 setAttribute，这两个方法被调用会自动触发组件的更新，固然 Omi 也保留了原生的 removeAttribute 和 setAttribute，以 pure 开头，用于 Omi 内部使用，由于内部 diff 和 apply diff 的时候并非须要每次都须要调用组件的 update。

看下这张图，很关键。用过 react 的同窗都知道，react 性能优化的关键就是 shouldComponentUpdate，最被诟病的也是这个，不少开发者也吐槽这个钩子函数，shouldComponentUpdate 也能够配合不可变数据类型，直接进行引用地址比较，来决定组件是否须要更新。Omi 团队一直在思考，这个东西可不能够去掉，实时证实是能够的。由于 Omi 自定义元素彻底基于字符串传递 props，不论是 boolean、string、number、json，都经过字符串传递，因此在进行组件更新以前，Omi 会进行一次浅比较，比较的结果决定是否更新，很是机智的作法。

在使用 web components 过程当中，最被你们诟病的就是样式穿透问题。你们有些场景就是须要穿透组件怎么办？穿透不了就只能重写组件了，或者修改组件的源码。这个项目维护会带来巨大的问题。Omi 为了解决这个问题，支持属性 css，用于覆盖组件内部的 css 样式。看上面的代码，h1 是红色的。

在父组件中使用my-element，经过传递 css，把 h1 颜色改为 green 。并且还能够动态修改组件内部的样式，能够 onClick 内部的代码便知。

有的时候，咱们不知道咱们外部注入组件的选择器权重是否足够，咱们能够经过加上 !important 保证必定覆盖掉组件内部的样式。

关于样式，还有一点须要注意，font-fact 不能放在 shadow dom 中，否则不生效。固然这里浏览器有差别，火狐能够放在 shadow dom 中，google chrome 不行。因此咱们通常都放在外面用来兼容全部浏览器。

使用 font-face 的 font-family 的 class 定义必须放在 shadow dom 中，这个是有点割裂，可是仍是很好理解，由于 shadow dom 自己就是隔离的。

除了赋能 web 其余框架，Omi 也提供了替换整个框架的解决方案，且看 store 体系。 store 体系是用于组件树共享数据和逻辑，若是熟悉 react context api 的必定了解，可是 Omi store 不彻底同样，store 上 data 的变动会产生一条 path，path 会去和组件上定义的 path 匹配，匹配上了就会进行更新，全部就达到了 局部 diff，局部更新 的目的。

看这是一个静态声明 path 的例子，固然也可使用 initUse 声明动态 path。看上图，计算属性也能够放在声明里。能够这样理解，store 是一个数据源头，关于数据最后要怎么预处理建议不要放在 store 里，而是放在组件的 use 声明里，好比你要对字符串反转，或者对数字平方什么的，不建议放在 store 里。

在 render 里可使用 this.use 去访问 store 的数据，固然也能够经过 this.store.data.xx 的方式，后者书写起来稍微麻烦一些。

这是命中的规则，第一列是由 proxy 的数据变动产生的 path，后者是组件定义的 path，只要命中一条就会更新组件。store 整个体系设计得很是简单直接方便，没有复杂的概念。

Omi 对 typescript 支持愈来愈好，后面 Omi 生态新增的全部组件、工具后者类库都会使用 typescript 来书写。上图解释了怎么让组件使用者可以在 typescript 或者智能提示。注意 Omi.props & ... 的目的是把 HTML 标准的属性也集成到智能提示上，自己 Omi 写的自定义元素就是标准的 HTMLElement。使用 JSX 写 Omi 元素的时候，在 ts 的检查会更加宽松，好比 tabindex="1"，在 react ts 中必须写成 tabIndex={1}，Omi 顺从 HTML 标签，一段 HTML 直接粘贴到 render 函数中就能够用，固然自闭合的标签必须手动闭合下，好比 img。

在使用原生的 web components 的 customElements.define 的使用，体验很很差。重复定义直接报错，并且从报错信息上也看不出是什么元素重复定义了。

Omi 基于 customElement.define 封装了 define 方法，有了前置的检查逻辑，不报错，只改告警，并且重复的名称也会突出打印出来。

这是即将发布的跨框架组件库，一群优秀的工程师正在加班加点赶进度，若是你感兴趣也能够加入进来，咱们一块儿打造标准化的通用组件库，框架无关、主题任意切换。

看上面这张图，这是一个通用的组件，标准的自定义元素。能够在 jsx 中使用，也能够以标准的 html 的形式在任意框架（omi、react、vue、ng）中使用。将来 omim 提供的组件都会提供这两种形式，方便任意形式的使用。

PPT以及演讲内容以图文的形式还原

待更新...

待更新...