JavaScript Weekly #468 (下)

批歪

更新於 2024/12/22發佈於 2019/12/22閱讀時間約 12 分鐘

本系列文為節選第 468 期 JavaScript Weekly 文章的讀後整理心得。

本文為「下」，收錄內容：

Vue 3.0 的設計概念
TypeScript 的 const assertion
Preact 華麗復活
阿 Svelte 不是很邱？

Vue 3.0 的設計概念

作者現身說法 Vue 3.0 本著什麼樣的理念在設計的。

基本出發點就是先考慮「誰在用」、「怎麼用」，於是衍伸出了需要同時兼顧「好上手」又具有「可延展性」。

好上手 vs 可延展性

簡單的概括有提到的例子：

CDN build -> 菜雞
Vue CLI -> 狠角色

😅

Options API -> 菜雞
Composition API -> 狠角色

😅

JavaScript -> 菜雞
TypeScript -> 狠角色
cons: learning cost
cons: slower initial development

這邊說到 Vue 3.0 用 TypeScript 寫只是為了有效提供強力的 IDE hint，因為希望保持好上手、容易維護的本質。3.0 用 JavaScript 或是 TypeScript 寫出來的 Vue component code 會長得差不多。

😅

Template -> 菜雞
JSX -> 狠角色

Templates allows us to get better performance

由於使用 template 寫法可以給 compiler 更好的 diffing 捷徑，不需要走過整個 tree，Vue 3.0 使用 template 的寫法可以得到更好的效能。

力量越大、包越大

其實這 part 也是延續上一 part 的概念，但切入的角度不同，所以我就把它們分開來寫了。

用不上的功能就不要包近來：

ES module export + tree shaking
連 template 寫法裡用上的內建 component，也是透過 complier 自動 import

接著就提到了有點接近於 library vs framework 的議題，這段整理的不錯，所以我打算寫詳細一點。

舉 React 當作 low-level 的範例：

優點

起始概念少
選擇很多 -> 生態蓬勃/造成困擾
從維護角度看，React 開發團隊只需要專注於 library 本體

缺點

需要自己想辦法解決較複雜的問題
約定成俗的規矩沒有寫在官方文件 (e.g. Redux)
生態系動得太快，third-party library 容易被丟包 (open source 萬歲)

接著舉 Ember.js, Angular 做為 framework 範例：

優點

大部分問題的解法都內建
整個生態系不太會有丟包的問題，大家是一起動的

缺點

起手門檻高
內建的問題解法不適用的時候，做得不夠有彈性的話，會無法解決特殊問題
因為包太多東西，想要做大改動比較困難 (e.g. 像 Angular 1 想要大改就掛了)

Vue 想要走的道路是 Progressive。

(秀出那張圖，你知道哪張)

分層的功能設計
低起手門檻
官方(文件)有提供常見問題解法

Vue 3 也會保持這個理念，你有需要，在學/用就好。

開放 low-level API 帶來更多彈性

官方提供詳細的 low-level API 用法：

自定 renderer
開放 compiler 使用

TypeScript 的 const assertion

沒在用 TypeScript 也可以大概了解它的作用。

TypeScript 在判斷型別的時候是相當嚴謹的。

一般情況下你用 const 來宣告 literal Object 或是 literal Array 的時候，就算你本意沒有要改變它們內容的意思，對 TypeScript 來說它們的型別沒有辦法被推定到接近 enum 那種的定值。

文中用的例子是 HTTP request 的 method，這邊寫精簡一點只留下四大天王：

const HTTPRequestMethod = {
  DELETE: "DELETE",  // type: string
  GET: "GET",
  POST: "POST",
  PUT: "PUT"
};

// 此動作不會有 type error
HTTPRequestMethod.DELETE = "TIMON";  // type: string

// 正因為可以進行這個操作，
// HTTPRequestMethod.DELETE 才沒有被推定為 "DELETE" type

那麼使用新的 const assertion，就可以達到接近 enum 的效果：

const HTTPRequestMethod = {
  DELETE: "DELETE",  // type: "DELETE"
  GET: "GET",
  POST: "POST",
  PUT: "PUT"
} as const;  // <- 加在這邊

// Error: Cannot assign to 'GET'
// because it is a read-only property.
HTTPRequestMethod.DELETE = "TIMON";

同樣在 literal Array 上也適用，有把 Array 變成 Tuple 的效果：

const ORIGIN = [0, 0] as const;
// 等於 const ORIGIN: readonly [0, 0] = [0, 0]

至於為什麼不乾脆用 enum 就好了？因為 enum 就是 TypeScript 額外帶來的東西，有些工程師會希望雖然寫的是 TypeScript，在可能的範圍還是盡量接近 JavaScript。

實際上 TypeScript 的 enum 在 compile 過後也就是 JavaScript Object 這樣。

var HTTPRequestMethod;
(function (HTTPRequestMethod) {
    HTTPRequestMethod["DELETE"] = "DELETE";
    HTTPRequestMethod["GET"] = "GET";
    HTTPRequestMethod["POST"] = "POST";
    HTTPRequestMethod["PUT"] = "PUT";
})(HTTPRequestMethod || (HTTPRequestMethod = {}));

Preact 華麗復活

Preact 初心主打做為短小精悍版的 React 其實相當成功，畢竟容量實在省下太多了…

Fast 3kB alternative to React with the same modern API.

React 會這麼大當然是有原因。React 建立了一套自己的 SyntheticEvent 系統，它把瀏覽器的事件系統打包並經過正規化，提供給了 React 及 React 使用者一些彈性。而 Preact 會小是因為它直接使用瀏覽器的 Event 系統，整整少了一大包。

但從一個 React 使用者的角度，Preact 要吸引你過去當然還是要更大的誘因，畢竟 Preact 小包的前提是它能使用的 API 有限，並且不完全與 React 相容。於是，Preact 團隊推出了 preact-compact，做為銜接 React 使用者的橋樑，只要引入它就可以相容幾乎全部的 React 語法與各種現成的 React component。

前言講完了(挖靠講這麼多才講完前言)，可以進入正題啦！

Preact 的這套做法有成功吸引到一群使用者，當年 Addy Osmani 君在講 PWA 的時候也有推過，畢竟容量小 94 屌。

但 React 在進入了版號開放年代(就是 0.15.x -> 16.x)之後，功能爆炸性成長，加上 Fiber 架構的改動，Preact 在功能追趕上面漸漸顯露出疲態。

其實我一度覺得 Preact 要涼了。

現在 PreactX (版號10.x) 推出就是 Preact 回歸的一劑強心針：

Fragments
Hooks
componentDidCatch
createContext

然後他們也認清了 Preact 終究是離不開 preact-compact 這個 package，於是直接把它併入 preact package 裡面去了，之後只要 import React from 'preact/compact'; 就可以使用囉！

React 近年的爆炸性發展真的是很難跟上… Preact 真是辛苦你了。但如果每每都需要等 Preact 跟上才能使用 React 新功能的話，我想 Preact 使用者大概會漸漸跳回來吧…

之前我光等 react-apollo 官方支援 hooks 就望眼欲穿了 😫

阿 Svelte 不是很邱？

這是一篇超長的 React vs Svelte 戰文，本文作者是支持 React 那邊的。

他在看完 Svelte 官網跟 Svelte 社群發的文章之後，忍無可忍(?)跳下來開戰。

主因是 Svelte 太愛帶風向了 😆

列舉了兩個帶風向的大分類，作者都用自己的角度給予反擊。這邊我建議大家對 Svlete 跟 React 有些瞭解之後再來詳細看作者的論述。

React 最愛重繪了
根本不需要什麼 vDOM

接著提了 Svelte 隨著時間可能可以解決的弱點：

TypeScript 支援
還不夠成熟，相關 package 太少

最後收尾直接嘴爆：

Despite above described limitations, I think Svelte actually brings up an invaluable idea. Yes, you cannot fully express a modern app through templates without sacrificing flexibility and code reusability.