來看一下內文的 HTTP/2 Prioritization1.
然後直接擺各家的頁面速度還蠻直接的w
用這個 logo 沒問題嗎？
IE 11 和 migration 版大概要年底，router/vuex 也還在 beta，所以真的要升級也是年底的事了。
我猜 IE 11 加回去，下載大小又會變回來 = =
基本上新設計的 date API 多半都有 Java8 time API 的影子 -- 分為機器產生的絕對時間和人使用的曆法時間
Absolute -- Java 8 Instant
DateTime -- Java 8 LocalDateTime
不過沒看到相對應的 ZonedDateTime 或是 OffsetDateTime，只有轉 string 時才會出現。
這個嘛... 我猜未來 proposal 會加上去吧，而且 Absolute 這個字大概會被改掉，因為明明文件裡就一直出現 instant 這個字。
TDD 很好；但寫 React 怎麼做開發者測試(乃至於 TDD)又是一回事...我會覺得目前沒有好答案啦。
現在常見的做法大概分成兩種：
用 enzyme 的 shallow 測單個 component 的 render、不執行下層 component 的 render。 類似 mockist 的做法，寫起來很快，但問題是重構、改寫 component 的時候，整個測試會爛掉、或是發生「明明下層 component props 改了，但是這一層的測試卻依然通過」的事情(因為 shallow 只能測是否傳入特定的 props 給下一層)。 另外 React 官方已經棄用 shallow 了，useEffect/useContext 的 hooks 在 shallow 不起作用。只能等待 enzyme 把 shallow renderer 收進去跟改寫： issue1
用真正的 React mount component 測輸出的 DOM。也是這篇文章提到的 Kent C. Dodds 倡導的。屬於測結果而非狀態的做法。理論上重構會比 shallow 穩定。 但是被測的 component tree 大起來的時候(例如要測上層 component 的邏輯)，比較難 trace code。 需要做 api mock。一旦底層有 component 增加了 api 呼叫，測試也是整組壞掉。 更別說 apollo 的 mock provider 有多難用，一定要跑非同步，就只能 wait DOM 出現正確的狀態。
長期來看可能還是整串拿起來測比較穩定啦，但是就是很花時間...然後設計一改又要全部洗牌 XD