Web Components 在 GitHub 中的應用

使用 Web Components 的人越來越多，有些人可能只是玩一玩，而有些人已經在真實的大項目中使用起來了。

為了推動社區的發展，我們將推出一個專題，採訪一些早期的嘗試者。

這次，我們從訪問 Joshua Peek 開始，他本人是一個開發者，在 GitHub 已經工作了三年。

Q：儘管你們有巨量的來自世界各地的訪問者，GitHhub 還是已經使用了一些 Web Components 在線上的產品上。費了多大了力氣才說服大家使用這一類新技術？

這個月，我們確實非常謹慎地考慮過使用最新的客戶端 MVC 類庫。jQuery 差不多是唯一一個我們還在使用的框架。但是說到標準化的 Web 技術，我們一直都是走在前面的。

為了開始測試 Custom Element API，我們最初的元素擴展是小範圍的。因為如果出了什麼問題，我們可以很容易地使用與原來差不多的時間，重寫代碼。

Q：你們對 time 元素做的擴展只使用了 Custom Elements，那你對其他的規範 HTML Imports、Templates 和 Shadow DOM 有什麼看法？

Template 看起來很贊，我很想現在就用它。不過，目前有很多邊緣情況 polyfill 都無法處理。很簡單的，比如不執行的腳本，table 元素標記和重複的 id 都是痛點，我們目前的解決方案都是使用 div 元素來模擬。但是，如果polyfill 無法實現與原生模板元素一樣的功能，一定會產生很多頭疼的問題。

Shadow DOM 確實很有趣，但是充其量就是規範已經定義好了。謹慎考慮，我可能不會用 polyfill，因為它們需要劫持幾乎所有的 DOM 查詢的 API，來定實現自定義的 Shadow DOM 行為。這可能會產生性能問題。

HTML Imports polyfill 目前依賴於 eval() 來運行內嵌的腳本，於是被我們拒之門外。因為缺乏安全性，且需要很多亟待開發的工具來做內聯和重寫URL。這很複雜，需要大量的工作，有點得不償失。我們現在就是直接把頁面上需要用到的腳本和樣式直接引入就行了，沒啥問題。

我想，我們目前就先使用 Custom Element。polyfill ，原來的老的 JS API 和我們目前有的架構基礎三者可以很好的在一起工作。

Q：針對還在使用過時瀏覽器的用戶，你們有特定的降級策略么？

慶幸的是，Custom Element polyfill 可以支持到 IE 9，它同時是我們支持的最老的瀏覽器。除此之外，我們確實還關心不支持 JavaScript 的瀏覽器該如何降級。對於 time 元素來說，這一點不難，如果 JavaScript 沒有運行，用戶可以看到一個靜態的日期，這是可以接受的。我想我們可以嘗試在 Custom Element 標籤中放一個 noscript 來解決這個問題。假如，你想自定義select 元素，你可以在自定義元素內部放一個原生的 select 元素，JavaScript 運行的話就可以更新之。總之，如果瀏覽器很老，或者不支持 JavaScript，你還是可以做一些功能性的控制。

Q：除了擴展這些標籤，GitHub 還有使用其他 Custom Element 的打算么？

是的，我想我們會朝著這個方向繼續向前。下次可能是一些簡單的控制項，比如 menu 和 modal。我真心希望表單有 XHR 非同步提交的功能。我已經在一個名為 async-form-element 的項目上做實驗了，目前還未成熟，不能用在真實的產品中。但是我希望將來某一天可以加入到 HTML 標準中。

當然，我們不會在任何可能的組件上都是用 Custom Element。我們不會把所有東西揉到一起變成一個謎一般的 <github-app></github-app>。有可能就使用原生的元素和控制項，自定義元素作為補充。

原文：How GitHub is using Web Components in production

推薦閱讀：