摘要：用過的同學都知道，性能優化的關鍵就是，最被詬病的也是這個，很多開發者也吐槽這個鉤子函數，也可以配合不可變數據類型，直接進行引用地址比較，來決定組件是否需要更新。

大家好，這次給大家講下 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 (
    

      omi button
    
    );
  }
}

這是 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 樣式?？瓷厦娴拇a，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以及演講內容以圖文的形式還原

待更新...

待更新...