前言
工程師平常除了開發系統之外，另外一項很重要的活動就是參加研討會，可以在幾十分鐘內吸收到他人鑽研許久的知識，是提升自己能力好的機會，因此，就想說可以找找看有沒有不錯的 React 相關國外的研討會。
大家都知道 ReactConf 是 react 開發社群一個非常大的年會，除了在美國舉辦的之外，也有另一場在澳洲舉辦的年會，在看過這場 Conf 以後覺得非常不錯，所以整理一些重點跟大家分享。
這次分享的場次有 4 場（總共有 23 場），之後有機會再陸續跟大家分享 。
CSS-in-JS — Max Stoiber
Max Stoiber 是 styled-components 的作者，之前在 GitHub 工作，現在則是在 Gatsby 工作。他參與這場演講的最主要的目的是推廣開源，開源可以讓整個專案的生態系變得更好，讓專案有更好的 API 可以使用。
他先從 CSS-in-JS 的歷史開始說起，從 2014 年開始 (React.js 誕生的隔年)，每一年都有許多不可思議的 CSS-in-JS 開源專案，而到了 2016 年時 styled-component 誕生了，到了隔年，2017 年 v2 也隨之誕生。那時有一個在 Africa 的工程師 thysultan 開源了 stylis.js 這個 CSS parser，stylis 的檔案非常小，而且更快，甚至讓 styled-component 的 bundle size 足足減少了 90%，現在幾乎所有的 CSS-in-JS 專案都是用 stylis。
而在 2017 同一年，emotion 誕生了，號稱比在場的各位更強、速度更快，各位至今為止都在做什麼呢？ (這是講者在演講時說的笑話 😆)
作者提到了近 20 個 CSS-in-JS 的解決方案，但是在 2017 之後幾年，都沒有非常獨特，像是 2017 年以前每年都有新穎的 CSS-in-JS 解決方案，而講者邀請所有人可以一同參與開源，如果你有什麼新奇的點子，歡迎大家去找他。
最後是講者提到如何開源的步驟，他說道「document all the things」 是最需要被注意的部分，如果文件僅僅只是說這是一個 node.js 的開源專案，沒有人想用你的東西，你必須寫出這個專案究竟在做什麼，為什麼要用你的開源專案，這樣才是做好開源專案的第一步。
How to create an open source project ?
✔️ Make it work, make it right, then make it fast
✔️ ️Share early, share often
✔️ Document all the things
他提到在寫 styled-component 的文件甚至比開發多了將近 2 倍的時間，因為如果你只是開源一個 JS 專案，README 上面什麼都沒有，那麼根本沒有人會想 trace 原始碼，甚至使用你的開源專案。
Themeability is the path to dark mode — Diana Mounter
Diana Mounter 現在在 GitHub 工作，是 Design Infrastructure 的 Director。她在這場演講中介紹了過去 GitHub 在 Themeability 上留下的許多關於 CSS 的技術債，他們曾經使用 sass 建立龐大的樣式系統，但是其實容易發生許多問題，例如 class 名稱衝突的問題。
後來他們嘗試使用 React + CSS-in-JS 的解決方案，把原本不易掌控的 sass 用 styled-system 與 styled-component 取代，最後建立了一套 GitHub 的 Design System 稱作 Primer。
演講中有許多關於顏色設計的部分，有興趣的人可以看看～
(Proto)typing innovation in BBC News — James Dooley
James Dooley 在 BBC 的 News Lab 工作，他們主要為 BBC 開發許多方便的工具，讓撰寫新聞能夠更加快速與便利。
其中有一款是 BBC — OCTO 是一個 web-based 的工具，它的功能很簡單，你可以上傳一個影音檔案，然後系統會分析影片中的影音，並解析出說話的文字內容，然後發送文字至你的 email。
實際上它的功能已經不能滿足 BBC 的需求，所以他們又開發了另一款工具 — react-transcript-editor，同樣是解析影片中的說話內容，但是它提供了更完善的功能，使用者可以於線上校正逐字稿，在完成校正後，甚至能夠匯入其它影音軟體中更進一步的編修。
這一款工具主要是使用 Draft.js 開發的，因為它需要 Draft.js 豐富的功能，讓編修逐字稿更便利。
可是 James 有點疑惑為什麼 Draft 停止更新了，雖然他們有在思考其他的 React Text Editor 的解決方案，像是 slate.js 或是 quill.js，但是他們仍然需要像是 Draft.js 豐富的功能，因為 Draft.js 提供的功能正是 BBC 所需要的。
The first two seconds: Faster page loads with React — Josh Duck
Josh Duck 現在在 Clipchamp 工作，過去在 Facebook 管理 JavaScript 優化的團隊，並且協助建立 Draft.js，只是後來他就沒在維護這個套件，當下順便對 James Dooley 道歉 (引來全場一陣歡笑)。
我們在建立 React APP 的一開始，都會決定應用程式要採用什麼架構，Josh 就提到了以下 5 種不同的方法。在圖中的上面兩種想必大家都很熟悉，如果沒有 SSR 的需求就會使用 CRA (create-react-app)，有的話則使用 Next.js，它們已經幫我們鋪好一大半的路。
最後一項 「server render with no client JS」指的可能是像只使用 express 這種框架建立應用程式，沒有 React 前端框架輔助渲染網頁。也可以單純用 node.js 內建的 web server，但如果在專案一開始沒有規劃好程式碼架構，將有可能會導致技術債越堆越多。
其中比較新奇的是 progressive hydration，這是一個在 Google I/O 2019 被發表一項技術，它解決了一個龐大的 JavaScript 程式碼在第一時間載入時造成畫面卡住的問題。這項技術讓瀏覽器中的 React Component 與事件的 JS 程式碼可以部分載入，在使用者觸發事件後，才透過漸進式載入 JS 程式碼的方法，讓整個與使用者互動完成。
這是 React 的實驗性功能 — Concurrent mode
ClipChamp 的軟體架構
- Server side rendering
- Client hydration (like Next.js)
- Caching via CDN
- CSS media queries (RWD)
ClipChamp 之前所使用的架構大概跟大家想像中差不多，使用 Next.js 可以使用 SSR 解決 SEO 以及部分 UX 的問題；使用 CDN 能夠讓網站的體驗更好，如果不使用 CDN 的情況下，沒有特別優化後端的伺服器，每一次請求都會造成伺服器的負擔，也會佔用較多的網路頻寬。至於 media queries，應該是大多數人會採用的 RWD 解決方案 (我也沒用過其他種就是 😅)。
講者提到 lighthouse 這個工具，大家應該都不陌生，它提供了豐富的指標，可以用來評估網頁性能的分數。
講者也快速提到以下幾個評估網頁性能的重要指標：
- FCP (First Content Paint): 從網頁是空白的，到任何一個 DOM 被繪製到網頁中。
- FMP (First Meaningful Paint)：繪製使用者想看的內容。 (在 lighthouse 6.0 已經被移除，google 推薦轉移看 LCP 這個指標)
- LCP (Largest Contentful Paint) ：繪製大量的文字內容或是圖片至網頁上。
- TTI (Time to Interactive)：網頁載入後至可以跟使用者開始互動的時間，也就是 JavaScript 已經載入完畢，使用可以觸發點擊之類的事件。
Improving performance
講者提到他們公司如何優化他們的網頁，包含以下幾點。
👉 Fix our cache headers
講者說第一個可以優化網站的事情就是對「靜態資源」優化，像是使用 HTTP caching 的方式讓一些資源可以被 cache 住，或是壓縮網頁使用的靜態資源，這兩件事情都很簡單，如果還沒做的話可以考慮做一下。
👉 Font swapping
這個優化方式應該是用 font-display 優化 FMP，講者說他們讓網頁首先載入系統的預設字體，然後等到 @font-face 成功載入完畢後，再替換掉系統的預設字體。
講者說透過 font swapping 優化了網站的 45% 的 FMP，將時間從原本的 4.0 秒降低至 2.2 秒。
👉 Preloading resources
你可以設定 <link> 的 rel 為 preload，這樣就可以告訴瀏覽器有些資源可以儘早被載入，而透過 as 這個關鍵字，能夠設定預先載入的資源其優先等級。
但是要注意的是 preload 的瀏覽器支援度不太好，從 🔗 Caniuse 中看到 Firefox 的預設是關閉的，這意味著我們在一般的情況下不能使用 preload 事先載入資源。
firefox: Not supported by default, but can be enabled.
👉 Lazy loading images
Lazy loading images 是很多網站都會做的一項優化，講者提他們用 Intersection Observer 的方式實作 React component，以及有一些圖片是會事先顯示在網頁上，因為並不是所有的圖片都需要 lazy loading。
講者提到他們使用這個技術後將網頁的 first image 這個指標提升了 44%，將時間從 7.8 秒降低至 4.3 秒。
不幸的是我找不到 first image 這個指標，如果有在哪裡看到的話，再麻煩好心的大大留言告訴我 😅。
🎉 原生瀏覽器支援圖片的 lazy loading
目前使用 Chromium 的瀏覽器 Chrome、Edge、Opera，以及 Firefox 都支援 圖片的 lazy loading，只要在 <img /> 上加上 loading="lazy" 的屬性就可以原生支援圖片的 lazy loading。
👉 nomodule
如果你開發的 React APP 必須要支援像是 IE 這種舊時代的瀏覽器，可以在載入 JavaScript 的 tag 上加入 nomodule 這個屬性，這個屬性代表只有在遇到舊瀏覽器時才會載入這個 JavaScript 檔案，而舊的瀏覽器指的是不支援 type="module" 的瀏覽器。
講者說到這個優化讓他們的網站加快了 22% 的 First Content Paint (FCP)，將時間從 1.8 秒降低至 1.4 秒。
👉 lite-youtube-embbed
如果你需要在網頁中嵌入 YouTube 的影片，可以考慮不要使用 <iframe> ，而是使用另一個替代的解決方案 lite-youtube-embed ，根據這個套件的 README 說明，使用 lite-youtube-embed 可以讓整體的載入速度快上大約 224 倍 (這真是一個非常可怕的速度 😅)。
結論
這次跟大家分享了 4 場 ReactConf AU 2020 的演講，包括 Styled-components 的作者 — Josh Duck、GitHub 的 design director — Diana Mounter、BBN News Lab 的 James Dooley，以及前 Facebook JavaScript 優化部門的 Josh Duck。
這幾場演講都讓我吸收了些新的知識，真的很幸運可以看到國外許多公司的大神演講，覺得在這個世界上有一群人除了開發之外，也樂於奉獻自己所學於開源社群，或是在研討會上分享自己的知識，感謝這些無私奉獻的大神。
分享就到這邊，如果喜歡我的文章可以幫我拍個幾下手，在閱讀文章時如果有遇到什麼問題，或是有什麼建議，都歡迎留言告訴我，謝謝。 😃Referenece
- CSS-in-JS — Max Stoiber
- Themeability is the path to dark mode — Diana Mounter
- (Proto)typing innovation in BBC News — James Dooley
- The first two seconds: Faster page loads with React — Josh Duck
- primer
- react-transcript-editor
- Draft.js
- Progressive Hydration — A Faster React Approach on Client Side
- Lighthouse
- User-centric performance metrics
- Serve static assets with an efficient cache policy
- Controlling Font Performance with font-display
- Preloading responsive images
- Lazy-loading images
- Intersection Observer API
- Browser-level image lazy-loading for the web
- lite-youtube-embed
