Yeefun | Feed

我知道你懂 Event Loop，但你了解到多深？

Fri, 02 Apr 2021 00:00:00 GMT

事件迴圈（Event Loop）是一個我以為我懂了，但直到最近才發現自己什麼都不懂的概念。

會發現這件事，是因為我在研究 React Fiber 的過程中，獲知了一個能提升網頁性能的 API requestIdleCallback，它的回呼（callback）會在瀏覽器空閒（idle）時執行，其中一個時機點是幀尾。

問題來了，什麼是「幀尾」？要回答這個問題，首先當然要知道什麼是「幀」（frame）？原本我以為，幀就等同於網頁畫面更新——每一幀，畫面就更新一次。但若是這樣，哪來的「尾」可以給 requestIdleCallback 執行？或許，一幀除了更新，還做了許多事？

就這樣，我從想瞭解一幀究竟做了哪些事，不小心掉進事件迴圈的漩渦，糾纏了一個多禮拜才爬出來，又花了好幾天才煉成這篇文章。

本文將從官方規範下手，看完它，你便能回答：

事件迴圈的運作流程為何？
「幀」是什麼？
setTimeout、requestAnimationFrame、requestIdleCallback 分別發生在事件迴圈的哪個階段？
宏任務（macrotask）和微任務（microtask）是什麼？它們與事件迴圈的關係是什麼？
每輪事件迴圈都會更新畫面嗎？
JavaScript 是單執行緒（single threaded），但卻能發出 HTTP 請求而不阻塞（non-blocking），這是怎麼辦到的？

JS 單執行緒卻不阻塞的祕密

在開始之前，先來看一張圖：

事件迴圈在瀏覽器的角色。圖片原始來源已不可考

不用看太久，有個概念就好；等你讀完這篇文章，就能看懂這張圖了。

首先要闡明，事件迴圈是與 JS 的運行（runtime）環境相關的機制，它與 JS（引擎）本身無關。常見的運行環境有瀏覽器、Node.js，每種運行環境可能都有自己實現事件迴圈的方式，而本文只探討瀏覽器的事件迴圈（Node.js 的事件迴圈也是一個重要的主題，等哪天我搞懂了再來寫）。

為什麼需要事件迴圈？這與 JS 單執行緒的特性有關。單執行緒意味著 JS 一次只能執行一段程式碼，當 JS 在調用（invoke）一個函式時，沒有任何其它程式碼可以同時運行，除非這個函式結束或被中斷（suspended）（後者可用 generator 達成）。

深入點說，JS 內部有一個呼叫堆疊（call stack），又稱為執行上下文堆疊（execution context stack），這個堆疊是用來追蹤程式所呼叫的函式。每當程式調用一個函式，這個函式所產生的執行上下文便會被壓入（push）堆疊；當這個函式執行完，便會被彈出（pop）。函式的執行順序遵循「後進先出」（LIFO, Last In First Out）的模式。

單執行緒雖簡單易懂，但卻有一個明顯的問題：假如一個函式執行過久，便會卡住之後函式的執行。如果這些函式恰好是做與 UI rendering 相關的事，那畫面便會延遲更新，這對使用者體驗來說是致命的。

現在讓我們來想一下，JS 有什麼操作是相當耗時的？無論你的答案是什麼，我都已經想好了（欸），那就是請求資料。在 AJAX 大行其道的年代，大家都在用 XMLHttpRequest（XHR）請求來請求去。如果使用者網路速度慢，可能一次請求就要花費好幾秒，但為什麼使用者的畫面仍能正常渲染（render），而沒有絲毫延宕？

因為 XHR 並非由 JS 本身，而是由它的運行環境（即瀏覽器）自身的執行緒來處理的，因此不會阻塞呼叫堆疊。由瀏覽器負責處理的函式還有計時器 setTimeout、與動畫緊密相關的 requestAnimationFrame、害我一腳踏入事件迴圈泥淖的 requestIdleCallback⋯⋯它們通通統稱為 Web APIs。

以計時器來舉例，當 JS 引擎執行到 setTimeout(func, 3000)，瀏覽器便接手過計時的操作，等三秒一到，便將它的 func 回呼塞進呼叫堆疊，讓引擎執行。這可說是一種非同步（asynchronous）的機制。

一個複雜的網頁，可能會有許多回呼要執行，現在讓我們來問：是誰不停挑出回呼並將回呼塞進呼叫堆疊的？

那就是今天的主角：事件迴圈。

事件迴圈的基本概念

同樣，在進到事件迴圈的流程前，先來看一張統整圖：

事件迴圈的運作流程。圖片原始來源已不可考

看得懂在幹嘛嗎？看不懂？沒關係，繼續看下去，一切都會豁然開朗。

（喂！有人說看得懂啊！不要假裝沒聽到！喂、喂——）

（消音）

接下來，我們會跟著這份由 WHATWG（Web Hypertext Application Technology Working Group）社群（a.k.a. 瀏覽器大佬）編寫的 HTML 規範文件，來理解事件迴圈詳細的運作流程。

（原文是英文，我會以自己覺得重要且能理解的方式翻，不會嚴格地一個字一個字翻。如果我覺得英文能比中文表達得更清楚，那我就會維持原文）

為什麼需要事件迴圈？開宗明義，規範便說了：

為了協調事件、使用者互動、腳本、渲染和網路活動（networking）等，使用者代理（user agents）必須使用本節所描述的事件迴圈。每個代理都有一個相關聯且唯一的事件循環。

接下來，規範根據不同代理對事件循環做了三種分類：window event loop、worker event loop、worklet event loop。第一個代理是我們最常碰到的 Window 物件；第二個代理告訴我們 service worker 會有自己的事件循環；第三個代理我不知道是什麼，worklet 似乎是一個實驗性的 API。

讓我們往下滑：

一個事件循環會有一到多個任務佇列（task queues）。

每個任務（task）都來自特定的任務源（task source）。每個任務源都必須對應一個特定的任務佇列。

這兩段話出現了三個專有名詞：任務、任務源、任務佇列。

首先，任務就是宏任務，它可以幹的事情相當多，包括發布（dispatch）Event 物件（想想當事件監聽器觸發時，回呼所拿到的第一個參數）、解析（parse）HTML、呼叫回呼、獲取（fetch）資源、響應（reacting）DOM 操作。

任務源也很多，但大都被歸類為以下四種：

DOM 操作：比如以非阻塞的方式將元素插入 document。

使用者互動：比如鍵盤輸入或滑鼠點擊。

網路活動。

歷史紀錄尋訪（history traversal）：比如呼叫 history.back() API。

那任務佇列又是幹嘛的呢？它是拿來分類任務源用的；換言之，不同的任務源可能會被塞進同一個任務佇列。但為什麼要對任務源進一步分類？這個例子說明得很清楚：

例如，使用者代理可以將任務佇列分為給滑鼠和鍵盤事件（即使用者互動任務源）用的，和給其它任務源用的。藉此，使用者代理可以在事件循環的處理模型的初始步驟中，給與使用者互動任務源關聯的任務佇列四分之三的優先處理權，以讓介面保持響應性，但又不會卡死其它任務佇列。

換言之，說到任務的處理順序時，並沒有誰先觸發誰就先執行的道理，這一切都要看你的瀏覽器如何實作。

最後再講一件事：

微任務佇列（microtask queue）不是任務佇列。

微任務是一種通俗的講法，指的是透過 queue a microtask 演算法創建的任務。

微任務雖是一種任務（它們具有相同的結構），但它所形成的佇列與任務佇列不同，而這是因為它們在成為佇列時所使用的演算法不同。

有了這些基本概念後，接下來，讓我們直接進到事件循環的重頭戲吧！

事件迴圈是怎麼運作的？

在 8.1.6.3 處理模型（Processing model）中，規範描述了事件迴圈的運作流程：

只要事件循環存在，便必須一直運行以下步驟：

挑出一個任務佇列，要怎麼挑由使用者代理決定。如果沒有任務佇列，那就直接跳到微任務步驟。

將 oldestTask 設為該任務佇列中第一個任務，並移除。

將當前正在運行的任務設為 oldestTask。

Let taskStartTime be the current high resolution time.

Perform oldestTask's steps.

將當前正在運行的任務設回 null。

前六步都滿好理解的。

1：「由使用者代理決定」符合我們前面所說的，使用者代理可自行決定要給哪個任務佇列較高的優先處理權。

2：由於是任務佇列，資料操作當然是遵循先進先出（FIFO, First-In-First-Out）的原則。

微任務：施行微任務檢查（Perform a microtask checkpoint）。

If the event loop's performing a microtask checkpoint is true, then return.

Set the event loop's performing a microtask checkpoint to true.

只要微任務佇列不為空：

將 oldestMicrotask 設為對微任務佇列出列（dequeue）的結果。

將當前正在運行的任務設為 oldestMicrotask。

運行 oldestMicrotask。

將當前正在運行的任務設回 null。

For each environment settings object whose responsible event loop is this event loop, notify about rejected promises on that environment settings object.

Cleanup Indexed Database transactions.

Perform ClearKeptObjects().

Set the event loop's performing a microtask checkpoint to false.

7：開始處理微任務。首先檢查 performing a microtask checkpoint 這個旗幟（flag）。為什麼需要？因為微任務檢查並不只有在事件循環的這個環節才觸發，其它觸發時機比如調用回呼後；而為了避免在處理微任務佇列時重複施行微任務檢查（這可能在 7.3.3 發生），因此需要一個旗幟來控制（後面會再詳細說明微任務的執行策略）。

7.3：檢查微任務佇列是否為空，若不為空，便執行第一個微任務。重複這個過程，直到所有微任務都執行完畢。

7.4-6：我看不懂在做什麼，知道在幹嘛的人可以留言跟我說。

將 hasARenderingOpportunity 設為 false.

將 now 設為 current high resolution time. [HRT]

Report the task's duration by performing the following steps:

Let top-level browsing contexts be an empty set.

For each environment settings object settings of oldestTask's script evaluation environment settings object set, append setting's top-level browsing context to top-level browsing contexts.

Report long tasks, passing in taskStartTime, now (the end time of the task), top-level browsing contexts, and oldestTask.

8：從字面上理解，hasARenderingOpportunity 便是「是否有渲染機會」，一開始是 false，它將跟等下第 10 步的更新畫面（Update the rendering）有關。

9：這裡的 now 將成為 requestAnimationFrame 回呼的第一個參數。

10：我看不太懂在幹嘛，但 10.3 回報的 long tasks 似乎會出現在 Chrome 開發者工具的 Performance 面板中。

更新畫面：如果是 window event loop，則：

Let docs be all Document objects whose relevant agent's event loop is this event loop, sorted arbitrarily except that the following conditions must be met:

Any Document B whose browsing context's container document is A must be listed after A in the list.

If there are two documents A and B whose browsing contexts are both child browsing contexts whose container documents are another Document C, then the order of A and B in the list must match the shadow-including tree order of their respective browsing context containers in C's node tree.

In the steps below that iterate over docs, each Document must be processed in the order it is found in the list.

渲染機會（Rendering opportunities）：移除瀏覽上下文（browsing context）沒有渲染機會的 docs。

11：這一步做的事情相當多（上面只是一小部分），主要是處理跟畫面渲染相關的事。

11.1：我沒有全部看懂，但大致上就是選出 Document 物件、將它們指定給 docs，並以一定的規則排序。

11.2：你可能會疑惑：要怎麼決定有無渲染機會？

如果使用者代理當前能夠將瀏覽上下文的內容呈現給使用者，那該瀏覽上下文就有渲染機會，這需考慮硬體刷新率的限制，和使用者代理出於性能考量的節流，也需考慮内容的可呈現性（presentable），即使它在視窗（viewport）外。

規範似乎覺得這裡沒說清楚，於是又補上（跟上句很像的）一句：

瀏覽上下文的渲染機會是基於硬體限制（如顯示刷新率（display refresh rates））和其它因素（如頁面性能或頁面是否在背景（background））來確定的。渲染機會通常會定期出現。

好像還是沒說清楚，再給一個註解：

本規範並沒規定任何特定的模式來選擇渲染機會。但舉例來說，若瀏覽器試圖實現 60Hz 的刷新率，那渲染機會最多每 1/60 秒要出現一次（約 16.7ms）。若瀏覽器發現某個瀏覽上下文無法維持這個速率，它可能會將渲染機會降到可持續的每秒 30 次，而不是偶爾掉幀。同樣，如果一個瀏覽上下文不可見，使用者代理可能會決定將該頁面降到每秒 4 次渲染機會，甚至更少。

說了這麼多，我們大致上可以這麼總結：不是每輪事件循環都會更新畫面，其頻率高低，端看瀏覽器怎麼實作。

更新畫面：

如果 docs 不為空，則將 hasARenderingOpportunity 設為 true。

不必要的渲染（Unnecessary rendering）：移除滿足以下條件的 docs：

使用者代理認為更新 Document 的瀏覽上下文的畫面不會有明顯的（visible）效果。

Document 的 map of animation frame callbacks 為空。

移除使用者代理由於其它原因認為最好（preferrable）跳過更新畫面的 docs。

11.3：hasARenderingOpportunity 在第 8 步曾出現過。

11.4-5：與 11.2 做的事類似，再「兩」次篩選掉不需渲染的 docs。

11.4：把篩選條件說得很清楚，值得注意的是，animation frame callback 就是放在 requestAnimationFrame 的回呼。

11.5：有說等於沒說，其目的應是授與瀏覽器決定是否要渲染的權力。不過規範還是舉例了：

比如為確保某些任務緊接著執行，只有微任務檢查交錯其間（而且沒有 animation frame callbacks 參與）。具體來說，使用者代理可能希望合併定時器回呼，中間沒有畫面更新。

同時規範也說明了設立 11.2 和 11.4 的目的：

被標註為「渲染機會」的步驟可防止使用者代理在無法向使用者呈現新内容時更新畫面。

被標註為「不必要的渲染」的步驟可防止使用者代理在没有新内容可繪製時更新畫面。

到這裡，如果 docs 還有充分活躍（fully active）的 Document，那就一一對它們：

更新畫面：

flush autofocus candidates

run the resize steps

run the scroll steps

evaluate media queries and report changes

update animations and send events

run the fullscreen steps

run the animation frame callbacks

run the update intersection observations steps

Invoke the mark paint timing algorithm

更新該 Document 的畫面或使用者介面，及其瀏覽上下文以反映當前狀態。

11.6-13：你可以看到很多熟悉的名字，比如事件類型 resize 和 scroll、與 RWD（Responsive Web Design）息息相關的 media queries、常被拿來做懶加載（lazy load）的 Intersection Observer。

11.12：執行 requestAnimationFrame 的回呼。

11.14：不知道在幹嘛，但似乎跟網頁性能指標 FCP（First Contentful Paint）有關。

到這裡，事件循環的更新畫面結束，接下來：

如果滿足以下條件：

事件循環是 window event loop；

在任務佇列中沒有任何任務；

微任務佇列為空；

hasARenderingOpportunity 為 false；

運行 start an idle period algorithm。

12：若條件都滿足，requestIdleCallback 的回呼將在這步執行（終於找到你啦！我找你找得好苦啊！）。

第 13 步是在講事件循環是 worker event loop 的情況，與本文主題無關，跳過。

一輪事件迴圈到此運作完畢。現在再回去看本節開頭的統整圖，是不是很清楚了呢？

還不清楚？沒關係，讓我們結合呼叫堆疊、Web APIs 和事件迴圈，來實際跑一遍流程吧！

從範例了解事件迴圈

先來看一個簡單的例子：

setTimeout(function onTimeout() {
  console.log('timeout');
}, 0);

Promise.resolve()
  .then(function onFulfill1() {
    console.log('promise1');
  })
  .then(function onFulfill2() {
    console.log('promise2');
  });

console.log('main');

logSomething();

function logSomething() {
  console.log('something');
}

當程式執行，會發生什麼事？

建立一個全局執行上下文（global execution context），壓入呼叫堆疊。
遇到 setTimeout，由 Web API 接管計時器的處理，時間一到便把 onTimeout 排入任務佇列。
遇到 Promise.then()，將 onFulfill1 排入微任務佇列。
在控制台（console）印出 main。
調用 logSomething，將其函式執行上下文壓入呼叫堆疊。
印出 something。
logSomething 執行完畢，彈出。
程式執行完畢，全局執行上下文彈出。
施行微任務檢查：微任務佇列不為空，出列。
調用 onFulfill1，將其函式執行上下文壓入呼叫堆疊。
印出 promise1。
onFulfill1 執行完畢，彈出。
遇到 Promise.then()，將 onFulfill2 排入微任務佇列。
微任務佇列不為空，出列。
調用 onFulfill2，將其函式執行上下文壓入呼叫堆疊。
印出 promise2。
onFulfill2 執行完畢，彈出。
微任務佇列為空，微任務檢查完畢。
呼叫堆疊為空，事件循環從任務佇列取出最舊的任務。
調用 onTimeout，將其函式執行上下文壓入呼叫堆疊。
印出 timeout。
onTimeout 執行完畢，彈出。

你可能會疑惑：為什麼微任務是在程式執行完畢後便執行？微任務檢查不是應該在調用一個任務後（在此例即是 onTimeout）才觸發嗎？

別忘記我提醒過你的：微任務檢查的觸發時機相當多。下一節我會詳述微任務的執行策略。

再來看一個比較複雜的例子：

HTML：

<button id="btn" type="button">Click me!</button>

JS：

var btn = document.getElementById('btn');

btn.addEventListener('click', function onClick() {
  setTimeout(function onTimeout() {
    console.log('timeout');

    requestIdleCallback(function onIdle2() {
      console.log('idle2');
    });
  }, 0);

  Promise.resolve().then(function onFulfill1() {
    console.log('promise1');
  });

  requestAnimationFrame(function onAf() {
    console.log('raf');

    Promise.resolve().then(function onFulfill2() {
      console.log('promise2');
    });
  });

  requestIdleCallback(function onIdle1() {
    console.log('idle1');
  });
});

當你點擊按鈕，控制台會印出什麼？

答案不只一種，在不同瀏覽器或同一瀏覽器的不同時間，可能會出現不同結果。若只看最常出現的結果，Chrome 89.0.4389.90 是：

promise1
raf
promise2
timeout
idle1
idle2

Firefox 87.0 是：

promise1
timeout
raf
promise2
idle1
idle2

或是：

promise1
timeout
idle1
raf
promise2
idle2

但無論是哪種結果，都能被事件循環的處理模型解釋；換言之，差異並不來自規範失效，而來自規範賦予瀏覽器的彈性。

讓我們一步步來：

click 事件已由 Web API 接手處理，將其回呼排入任務佇列。
調用 onClick，將其函式執行上下文壓入呼叫堆疊。
遇到 setTimeout，由 Web API 接管計時器的處理，時間一到便把 onTimeout 排入任務佇列。
遇到 Promise.then()，將 onFulfill1 排入微任務佇列。
遇到 requestAnimationFrame，將其回呼 onAf 放入 map of animation frame callbacks。
遇到 requestIdleCallback，將其回呼 onIdle1 放入 list of idle request callbacks。
onClick 執行完畢，彈出。
施行微任務檢查：微任務佇列不為空，出列。
調用 onFulfill1，將其函式執行上下文壓入呼叫堆疊。
印出 promise1。
onFulfill1 執行完畢，彈出。

接下來，分歧產生了：究竟是會先執行計時器的回呼 onTimeout，還是 requestAnimationFrame 的回呼 onAf？端看此時 onTimeout 有沒有被排入任務佇列。你可能會說，setTimeout 的等待時間既是 0，其回呼應該就要被馬上排入任務佇列吧？

不一定，因為規範在計時器初始化步驟中其實有授與瀏覽器延長時間的權力：

可選擇再等待一個由使用者代理決定的時間長度。

目的是：

為了最佳化（optimize）裝置的電力使用（power usage）。例如，一些處理器具有低電量模式，其中定時器的粒度（granularity）會降低。在這種平台上，使用者代理可減慢定時器，而非要求處理器使用更精確的模式、消耗較高的電力。

雖然我不知道 Chrome 為何要對我這台 2017 年出廠的 MacBook Pro 13 做這件事，但反正理由百百款，我們只要知道有這個可能性就好。

所以，Chrome 的情況應該是：

呼叫堆疊為空，由於無合格的任務佇列，且微任務佇列為空，事件循環進到更新畫面步驟。
運行 animation frame callbacks。
調用 onAf，將其函式執行上下文壓入呼叫堆疊。
印出 raf。
遇到 Promise.then()，將 onFulfill2 排入微任務佇列。
onAf 執行完畢，彈出。
施行微任務檢查：微任務佇列不為空，出列。
調用 onFulfill2，將其函式執行上下文壓入呼叫堆疊。
印出 promise2。
onFulfill2 執行完畢，彈出。
由於 hasARenderingOpportunity 為 true，或任務佇列中有任務，跳過 start an idle period algorithm。
呼叫堆疊為空，事件循環從任務佇列取出最舊的任務。
調用 onTimeout，將其函式執行上下文壓入呼叫堆疊。
印出 timeout。
遇到 requestIdleCallback，將其回呼 onIdle2 放入 list of idle request callbacks。
onTimeout 執行完畢，彈出。
start an idle period algorithm，調用 onIdle1，將其函式執行上下文壓入呼叫堆疊。
印出 idle1。
onIdle1 執行完畢，彈出。
調用 onIdle2，將其函式執行上下文壓入呼叫堆疊。
印出 idle2。
onIdle2 執行完畢，彈出。

Firefox 的狀況呢，我有點累了（我相信你也累了），有空時可自行推導。

我只講 Firefox 的第二種結果——onIdle1 怎麼會緊接在 onTimeout 之後執行？一個合理的猜測是：在這輪事件循環，用戶代理跳過了更新畫面，而且是在 Rendering opportunities 這步就把本來要被更新畫面的 Document 移除了，這樣 hasARenderingOpportunity 才不會被設為 true，requestIdleCallback 的回呼也才有辦法被執行。

現在，你應該對事件循環的運作流程有很清楚的認識了，但本文還沒有要結束⋯⋯因為我還要講前面一直說會講的微任務的執行策略。

微任務的執行策略

微任務的觸發時機既簡單又複雜。先講複雜的：前面說過，執行微任務前會先施行微任務檢查，而微任務檢查的觸發時機可參考這張圖：

規範中有引用到 perform a microtask checkpoint 關鍵字的段落。圖擷自 WHATWG 規範文件

點擊這個連結，再點擊 perform a microtask checkpoint 粗體字，你也可以看到引用這個關鍵字的其它段落（當然不只這些，比如還有 update animations and send events 的第 3 步）。

比較常見的觸發點是 8.1.4.4 的 Calling scripts，它在 clean up after running script 的最後，當呼叫堆疊為空，會施行微任務檢查。

我沒有很了解 script 在規範中的意義為何，只知道有很多地方都會執行 clean up after running script，最常見的便是調用回呼的 Return 階段的第 2 步，而這就是為什麼在上一節第二個例子中的 onAf 會在執行完畢後，馬上施行微任務檢查。

「太瑣碎了吧！我怎麼可能記得住？」在你喊出這句話之前，我要來講一個簡單的判斷方法：只要當前呼叫堆疊為空，微任務檢查便會立即施行；易言之，微任務的執行策略是：見縫插針、盡可能早。

這個判斷方法並沒在規範中明確表述（至少我沒找到），但它應能適用 99.9% 的情境，剩下 0.1% 還有待你分享給我。

只講一個證據：現代瀏覽器已把 Promise.then() 看作是一種微任務（至少在 2015 年前不是如此，詳情可見這篇文章），而在 ECMAScript 規範裡，有一個與微任務相似的概念，叫作 job，而 Promise.then() 便是一種 job。因此，微任務的執行策略理論上要跟 job 相容。對於 job 的執行時機，你會發現它跟我前述的判斷方法是一樣的：

在未來的某個時間點，當沒有正在運行的執行上下文，且執行上下文堆疊為空時。

（除了 Promise，MutationObserver、queueMicrotask 也是微任務。有很多文章把 postMessage 也當作微任務，但它其實是宏任務，來自 posted message 任務源）

回答開頭的問題

本文到這裡已經快 7000 字了，原本還想寫事件迴圈可以怎麼應用，但讀者可能已經跑光了（其實是我手痠啦哈哈），加上我還沒有很了解微任務的使用時機，只好作罷。

在結束之前，看看我開頭提的問題，有什麼是還沒回答的嗎？有！

「幀」是什麼？

幀是組成瀏覽器畫面的基本元素；每個時刻的畫面，都是由一個相同或不同的幀所組成的。想更了解這句話的具體涵義，可查看 Chrome 開發者工具 Performance 面板的 Frames 斷面圖。

幀與更新畫面相關，但並不等同於更新畫面。幀包括了事件迴圈、佈局（layout）、繪製（paint）等等。一幀就代表一次畫面更新，但不代表只有一輪事件迴圈，因為瀏覽器能根據各種原因跳過更新畫面。

形象化地說，若瀏覽器畫面是「人」，那幀就像是「一天」這個時間單位——人的一生是由一天又一天所組成的，就像瀏覽器畫面是由一幀又一幀所組成的；人每天都會有固定的行程，且會有一定的順序，比如睡覺、吃飯、上廁所、洗澡等等，就像瀏覽器每一幀都會有函式呼叫、事件迴圈、繪製等等；當然，人有時會因為太累而不洗澡直接睡覺，瀏覽器也能有限度地調整一幀內所發生的事情的順序。

本文到此（終於）結束，不知道你是否跟我一樣也體驗到了事件迴圈的魅力？

喂？喂？還有人在嗎⋯⋯？

初學者學 KMP 演算法

Tue, 22 Dec 2020 00:00:00 GMT

第一次碰 KMP，被搞得暈頭轉向，花了兩天才搞定。只好趕緊寫下來，以免半小時後就忘記。

要怎麼在主串裡找到某個子串（模式）呢？

比如 abcabcabe 是主串，要怎麼找到 abcabe 這個子串？

最簡單的想法，就是從主串的第一個字跟子串的第一個字開始比，如果第一個字相同，再接著比第二個字，若第二個字也相同，再接著比第三個字⋯⋯如果不同，則主串回到第二個字、子串回到第一個字，接著主串的第二個字跟子串的第一個字比，如果相同，則主串的第三個字跟子串的第二個字比；如果不同，則主串回到第三個字，子串回到第一個字⋯⋯以此類推。

用程式碼表示就是這樣：

function indexOfByBf(s, p) {
  let sI = 0;
  let pI = 0;

  while (sI < s.length && pI < p.length) {
    if (s[sI] === p[pI]) {
      sI += 1;
      pI += 1;
    } else {
      sI = sI - pI + 1;
      pI = 0;
    }
  }

  if (pI >= p.length) {
    return sI - p.length;
  } else {
    return -1;
  }
}

這個算法直觀，又叫暴力（Brute Force）算法。暴力儘管好用，但當主串一長，便顯得沒效率。它的時間複雜度最好和最壞分別是 O(n + m) 和 O(n * m)（假設主串的長度為 n，子串的長度為 m）。

KMP 算法

要怎麼提高效率呢？首先，我們可以把匹配的時間複雜度分成兩個部分，一個是比較的趟（次）數，另一個是比較的字數。在暴力算法中，前者在最壞情況下為主串的長度，後者則為子串的長度。我們無法降低比較的字數（要找 abc，就只能 abc 一一比對，不然呢？），但可以減少比較的趟數。

要怎麼減少呢？這要看我們手上握有什麼資訊。當我們知道這一次比較找不到子串、準備回頭的那一刻，我們究竟獲得了什麼？這些資訊有辦法降低我們接下來比較的趟數嗎？

讓我們看看一個範例，主串是 abcabcabcabe、子串是 abcabe。第一次比較：

✔✔✔✔✔✗
abcabcabcabe
abcabe
✔✔✔✔✔✗

我們可以看到子串的第六個字 e 比較失敗了，這時暴力算法的第二次比較會這麼做：

 ↓
abcabcabcabe
 abcabe
 ↑

將子串向右移一格，也就是從主串的第二個字開始跟子串的第一個字比。不用一秒，你就知道這次比較不會成功（b 跟 a 不一樣）；再將子串向右移（從主串的第三個字開始跟子串的第一個字比），也不會成功⋯⋯我們有沒有辦法直接移到可能會成功的位置？

回到第一次比較失敗的那刻，滿足「可能成功」的主串位置的條件是什麼？至少那個位置開始的第一個字要與子串的第一個字相同吧！當然，第二個字相同也很好，第三個字相同更好⋯⋯依此邏輯，我們可以把我們要找的東西描述為：主串中的某個位置，這個位置開始的字符能最多地與子串的字符相同。

不過，還未比較的主串字符（即主串的倒數六個字符 abcabe），由於我們不知道它們的長相，因此也無從得知它們哪個位置能最多地與子串的字符相同。我們只能從已比較過且確認相符的字符去尋找正確的位置，即主串的前五個字符 abcab，而這五個字符，其實也就是子串的前五個字符。

單用眼睛看，我們可以很快地發現這個位置：

   ↓
abcabcabcabe
   abcabe
   ↑

但程式沒辦法這樣「看」，它需要方法去推導出來。這個方法就是，拿子串匹配成功的部分（即 abcab）的前綴去對準自己的後綴，而且這個對準的字符數要最多；換句話說，我們在找的是 abcab 的次長共同前後綴（Longest Proper Prefix Which Is Also Suffix，以下簡稱為 LPS。會說次長，是因為這個前後綴不能等於字串本身）。

一樣，先用簡單的方法來找：abcab 的（真）前綴有 a、ab、abc、abca；（真）後綴有 b、ab、cab、bcab。LPS 顯然是 ab，它的長度為 2。

得到這個數字後，我們就可以知道要從哪個位置開始比了。回到第一次比較失敗的那一刻：

     ✗
abcabcabcabe
abcabe
     ✗

現在，我們不要動主串指針的位置，只要將子串向右移三位：

     ↓
abcabcabcabe
   abcabe
     ↑

我們便可以從 c 開始比了。省去了跟主串的第二個字和第三個字比較的功（即減少比較的趟數），也跳過了從主串的第四個字開始比較時的頭兩個字 ab 的比較——是不是比暴力算法有效率多了？

到此，我們可以把 KMP 算法的程式寫出來了：

function indexOfByKmp(s, p) {
  let sI = 0;
  let pI = 0;
  const next = getNext(s);
  while (sI < s.length && pI < p.length) {
    if (s[sI] === p[pI]) {
      sI += 1;
      pI += 1;
    } else if (pI <= 0) {
      sI += 1;
    } else {
      // 主串指針不動，只動子串指針
      pI = next[pI - 1];
    }
  }

  if (pI >= p.length) {
    return sI - p.length;
  } else {
    return -1;
  }
}

等等，getNext 是什麼東西？它回傳的是一個陣列，這個陣列含有一系列部分子串的 LPS 長，它是讓 KMP 算法得以運行的關鍵，接下來就讓我們來看看怎麼求得這個陣列。

Next 表

以子串 abcabe 為例：

abcabe
000120

這張表的意思是：a 的 LPS 長為 0，ab 為 0、abc 也為 0、abca 則為 1、abcab 為 2、abcabe 為 0。

要怎麼求得這張表呢？先看最簡單的方法：

function getNext(p) {
  const next = [];

  for (let i = 0; i < p.length; i += 1) {
    const pSub = p.slice(0, i + 1);

    for (let j = pSub.length - 1; j >= 1; j -= 1) {
      if (pSub.slice(0, j) === pSub.slice(-j)) {
        next[i] = j;

        break;
      }
    }

    if (next[i] === undefined) {
      next[i] = 0;
    }
  }

  return next;
}

裡頭有兩個迴圈，時間複雜度為 O(m^2)，效率顯然不佳，會拖累 KMP 算法的整體速度。

要怎麼提高建造這張表的效率呢？思路是這樣的：拿完整字串的前綴去對準部分字串的後綴。假設有一個字串 p，值為 abcabffabcabc，現在我們要求前兩個字符的 LPS 長（第一個字的 LPS 長無論如何都是 0，須先補上）：

0↓
ab
 abcabffabcabc
 ↑

讓完整字串的前綴去跟 ab 的後綴比，若相同，則 LPS 長加一；若不同，且完整字串正在被比較的前綴為第一個前綴（即第一個字符 a），那 LPS 長便為 0。接著繼續拿完整字串的前綴去跟 abc 的後綴比：

00↓
abc
  abcabffabcabc
  ↑

LPS 長也為 0，再繼續往下：

000↓
abca
   abcabffabcabc
   ↑

喔！現在 abca 的後綴與完整字串的第一個前綴相同了，LPS 長加一。再繼續往下，拿完整字串的第二個前綴跟 abcab 的第二個後綴比：

0001↓
abcab
   abcabffabcabc
    ↑

一樣！LPS 長再加一！

00012↓
abcabf
   abcabffabcabc
     ↑

又遇到不同了，這邊也是直接設為 0 嗎？其實不能，中間還需要經過一些計算，但這邊先不細講，因為這次結果的確是 0，計算的效果不明顯。再繼續往下吧！會告訴你答案的！

讓我們把求 LPS 長度的過程加快，直接到最後一個字符：

000120012345↓
abcabffabcabc
       abcabffabcabc
            ↑

現在我們又遇到比較失敗的字了，也是直接設為 0 嗎？不能！在這之前，我們還要做一些掙扎——也許我們可以試看看將完整字串向右移幾位（亦即將其指針向左移），再繼續比。但該移多少呢？

不覺得這個問題有點熟悉嗎？似乎在前面講 KMP 時說過。你可以把現在遇到的問題想像成也是在做字串匹配：abcabffabcabc 是主串，abcabf 是子串，當比較失敗時，我們要做什麼？

求 abcab 的 LPS 長度！那我們還要再建一個 Next 表嗎？不用！早就建好了！不就是 2 嗎？

    ↓
000120012345
abcabffabcabc
    ↑  abcabffabcabc

現在，將完整字串的指針移到索引 2：

000120012345↓
abcabffabcabc
          abcabffabcabc
            ↑

太棒了！再度配對成功！LPS 長為 3（注意，不是 6 喔）。

（前面沒說明的第六個字符設為 0，其實也要經過同樣的過程，只是因為再次比較時仍失敗，而此時完整字串正在被比較的前綴是第一個前綴，因此才會結果看起來都一樣）

把上述過程轉換成程式碼，便是這樣：

function getNext(p) {
  const next = [0];
  
  // 部分字串的指針
  let iPartial = 1;
  
  // 完整字串的指針
  let iWhole = iPartial - 1;

  while (iPartial < p.length) {
    if (p[iPartial] === p[iWhole]) {
      iPartial += 1;
      iWhole += 1;

      next[iPartial - 1] = iWhole;
    } else if (iWhole <= 0) { // 當完整字串正在被比較的前綴是第一個前綴
      iPartial += 1;

      next[iPartial - 1] = 0;
    } else {
      iWhole = next[iWhole - 1];
    }
  }

  return next;
}

時間複雜度從 O(m^2) 降到 O(m)，與前述 KMP 的主體 O(n) 加起來，時間複雜度共為 O(n + m)。

那些長得不太一樣的 Next 表

你如果看過其它講 KMP 算法的文章，可能會發現它們的 Next 表長得跟這裡的 Next 表不太一樣：

 abcabe
 000120 <- 這裡的
-100012 <- 別人的

不同之處不過是後者將前者的數字都往右移了一位，並在第一個位置補上 -1。為什麼要這麼做呢？其實只是為了計算上的方便。

仔細看前面寫的 indexOfByKmp 和 getNext 兩個函數，裡面都有這個處理：

function indexOfByKmp(s, p) {
  let sI = 0;
  let pI = 0;

  const next = getNext(s);

  while (sI < s.length && pI < p.length) {
    if (s[sI] === p[pI]) {
      sI += 1;
      pI += 1;
    } else if (pI <= 0) {      sI += 1;    } else {
      pI = next[pI - 1];
    }
  }

  if (pI >= p.length) {
    return sI - p.length;
  } else {
    return -1;
  }
}

function getNext(p) {
  const next = [0];
  let iPartial = 1;
  let iWhole = iPartial - 1;

  while (iPartial < p.length) {
    if (p[iPartial] === p[iWhole]) {
      iPartial += 1;
      iWhole += 1;

      next[iPartial - 1] = iWhole;
    } else if (iWhole <= 0) {      iPartial += 1;      next[iPartial - 1] = 0;    } else {
      iWhole = next[iWhole - 1];
    }
  }

  return next;
}

這是為了防止當 pI 或 iWhole 等於 0 的時候會出的問題。有人覺得這樣額外開一個分支處理很麻煩，於是就做了上述移位補 -1 的動作，並把算法改寫如下：

function indexOfByKmp(s, p) {
  let sI = 0;
  let pI = 0;
  const next = getNext(s);

  while (sI < s.length && pI < p.length) {
    if (pI === -1 || s[sI] === p[pI]) {      sI += 1;
      pI += 1;
    } else {
      pI = next[pI];    }
  }

  if (pI >= p.length) {
    return sI - p.length;
  } else {
    return -1;
  }
}

function getNext(p) {
  const next = [-1];  let iPartial = 0;  let iWhole = iPartial - 1;
  while (iPartial < p.length) {
    if (iWhole === -1 || p[iPartial] === p[iWhole]) {      iPartial += 1;
      iWhole += 1;

      next[iPartial] = iWhole;    } else {
      iWhole = next[iWhole];    }
  }

  return next;
}

自己實際拿筆跟紙跑過一遍，會發現原理是相同的，答案當然也是一樣的噢。

關掉 no-var——決定變數宣告關鍵字的良好方法

Sun, 11 Oct 2020 00:00:00 GMT

大家平時都是怎麼決定該用哪個關鍵字（var、let、const）宣告變數的呢？受到 ESlint 建議規範的影響，我猜很多人跟我一樣，決定方式很簡單：會被再賦值（reassign）的就用 let，不會的就用 const。var 完全不在我們的選項，畢竟，var 有很多缺點，它的好處完全可以由 let 來代替，是吧？

我承認我並沒有很認真探討過這個問題，只是照著 ESlint 規範走，直到在讀書會看了頗知名的 You Don't Know JS Yet: Scope & Closures（是的，它出第二版了），發現作者 Kyle Simpson 並不派斥 var，甚至認為 var 的好處無法取代，這才讓我重新思考並質疑自己不使用 var 的理由。

`var` 很有用

Simpson 認為，var 跟 let 都很有用（他沒有很喜歡 const，後面會說原因），前者為函數作用域（function scope），後者為區塊作用域（block scope），因此，當一個變數在整個函數中都會用到，那就該用 var，並宣告在函數最外層（top-level，也可以說是頂層）；反之，如果一個變數只會在函數中的某個區塊用到，那就該用 let，並宣告在這個區塊內，讓外層的作用域取用不到。

比方說，假如我現在要寫一個能判斷使用者網頁捲動方向的函數，按照 ESlint 建議的寫法，會是這樣：

function logScrollDirection() {
  let beforeScrollY = window.pageYOffset;
  
  window.addEventListener('scroll', () => {
    const currentScrollY = window.pageYOffset;
    const delta = currentScrollY - beforeScrollY;

    if (delta > 0) {
      console.log('scroll down!');
    } else {
      console.log('scroll up!');
    }

    beforeScrollY = currentScrollY;
  });
}

但 Simpson 會建議這樣：

function logScrollDirection() {
  // 變成 `var` 了
  var beforeScrollY = window.pageYOffset;
  
  window.addEventListener('scroll', () => {
    // 變成 `var` 了
    var currentScrollY = window.pageYOffset;
    
    // 多了大括號
    {      // 變成 `let` 了
      let delta = currentScrollY - beforeScrollY;

      if (delta > 0) {
        console.log('scroll down!');
      } else {
        console.log('scroll up!');
      }
    }
    beforeScrollY = currentScrollY;
  });
}

你可能會想說，let 其實也是函數作用域，為什麼不乾脆把上面的 var 都改成 let 呢？

理由有兩個：第一，就語義上來說，var 比 let 更適合扮演「這個變數是作用在整個函數中」的角色，畢竟在 let 出現前的 20 幾年，var 就一直都是如此。

第二，如果你在任何地方都使用 let，那你可能會不好判斷這個 let 所宣告的變數是作用在整個函數中，還是只在某個區塊內。

你可能還會注意到，在黃線處有個奇怪的大括號 {..}。這個括號能確保 delta 不被函數內的其它地方取用到，讓它成為名副其實的區塊變數。

一般來說，我們在函數內創建區塊變數，是在遇到 if..else 或 for 迴圈的時候。但其實你可以不靠這些陳述語句（statement）來創建區塊變數，那就是直接用單獨的 {..} 大括號。

這個大括號看來有點奇怪又累贅，但它事實上是讓 var 與 let 的搭配發揮最大效用的關鍵，而且它還體現了軟體工程的一個原則：最小暴露原則（The Principle of Least Exposure, POLE）。

最小暴露原則

最小暴露原則與最小權限原則（The Principle of Least Privilege, POLP）有關，但它關注的層次較低。就變數而言，它想最小化暴露的是變數的作用域。

為什麼？想想一個極端的問題：為什麼我們不把所有變數都宣告在全局作用域（global scope）？命名衝突、被他人非預期或惡意修改、非意圖依賴導致重構困難（詳細說明可見這裡）——當我們把區域（local）變數非必要地暴露給程式其它部分使用，這三個危險便會浮現，在日後絆你一跤。

因此，我們應遵守最小暴露原則，這意味著我們應盡可能地保持變數私有（private），也就是將變數宣告在盡可能深的嵌套作用域內。

說來容易，但這其實並不是一個很直覺的作法。我常需要在寫完函數的內容後，再回過頭來重新檢視程式碼，以找出哪些變數是函數中的區域變數（或甚至是區塊中的區域變數），再用 {..} 括起。

聽來有點麻煩，但這種作法不僅能避免上述危險，還意外地擁有兩個好處。

第一個是當你不小心寫出一個肥大的函數，{..} 有助於你判斷哪些程式碼是彼此相關，從而讓你更容易理解整個函數在幹嘛。

當然，我們應盡可能避免寫出這樣的函數，但即使寫出來了，當我們在重構（refactoring），也可以相對容易判斷出哪些區塊可以提取成函數，以提升可讀性（readability）。

同時，提取函數的過程也變得容易，因為你可以很快地判斷出變數的來源，知道現在要提取的區塊裡有哪些全局變數和區域變數。比如下面這段程式碼（請想像它是一個內容很長的函數）：

/**
 * 此處範例借用自 Martin Fowler 的著作 Refactoring: Improving the Design of Existing Code (2nd Edition)
 * 第六章 Extract Fucntion 一節的程式碼
 */
function printOwing(invoice) {
  let outstanding = 0;
  const today = new Date();
  
  printBanner();
  
  // ...
  
  for (const order of invoice.orders) {
    outstanding += order.amount;
  }

  invoice.dueDate = new Date(today.getFullYear(), today.getMonth(), today.getDate() + 30);  
  // ...
  
  printDetails(invoice, outstanding);
  
  function printBanner() {
    // ...
  }
  
  function printDetails() {
    // ...
  }
}

假設你想重構被黃線劃起來的區塊，把它提取成一個名為 recordDueDate 的函數，但由於你不知道 today 這個變數還有在這個函數中的哪些地方用到，因此你必須一行一行檢查，還必須進到內嵌函數去看有無使用到 today，相當麻煩。

如果現在程式碼變成這樣：

function printOwing(invoice) {
  let outstanding = 0;
  
  printBanner();
  
  // ...
  
  for (const order of invoice.orders) {
    outstanding += order.amount;
  }

  {    let today = new Date();    invoice.dueDate = new Date(today.getFullYear(), today.getMonth(), today.getDate() + 30);  }  
  // ...
  
  printDetails(invoice, outstanding);
  
  function printBanner() {
    // ...
  }
  
  function printDetails() {
    // ...
  }
}

清楚多了吧！現在你可以很篤定 today 絕對不會被這個區塊以外的地方用到，可以放心又快速地把這兩行程式碼提取成 recordDueDate 函數了。

取捨：評估 `var` 的缺點

前面說了 var 的優點以及它該怎麼跟 let 搭配，這裡來談談 var 的缺點。

先從建議禁用 var 的 ESlint 看起。為什麼不用 var？ESlint 文件說，因為在區塊中宣告 var 可能會意外地改變其外同名的變數。注意「區塊中」這三個字。沒錯，這點與我們前面說的一樣，var 的確不應該宣告在區塊內，那是 let 發揮作用的地方。因此，前述原則已避免掉了這個缺點（Simpson 在這篇講述了他覺得可以在區塊內宣告 var 的狀況，雖然我仍覺得宣告在外頭比較好，但值得看看）。

再來，應該就是所謂重新宣告（redeclare）的問題。let 跟 const 將重新宣告的問題澈底消除。但，重新宣告真的是一個嚴重的問題嗎？更確切地問，這個缺點有辦法抵銷甚至壓過前述 var 的優點嗎？

至少我自己是幾乎沒有碰過重新宣告的問題。即便你的函數都寫得很長，但當你很有意識地在區分變數的作用域範圍，要出錯的機率可說是微乎其微。如果你真的很擔心程式壞掉，那你可以將所有用 var 宣告的變數都寫在函數開始處，總不會在這短短幾行中也有同名的問題吧？

function doBigThing() {
  var first = 'watch movies';
  var second = 'shopping';
  var third = 'sleep';
  var first = ''; // <-- 哦哦抓到了，太明顯了吧！

  // ..
}

同樣地，重新賦值的問題也是如此。想想看，你會在什麼情況下，不小心將一個不該被重新賦值的變數重新賦值？想不太到吧！大多數情況下，都是你想重新賦值，但卻發現這個變數被宣告成 const，於是你只好回過頭把它改成 let，再重新賦值。而且，即便你真的不小心犯錯了，會很難察覺嗎？會很難追蹤嗎？會很難改回來嗎？

我認為這兩個缺點並不足以說服我放棄前面所說的宣告方法。而且相對地，這兩個缺點也給予開發者更大的彈性，只要你謹慎使用（同樣地在這篇，Simpson 簡單示範了重新宣告作為一種註解的功用，雖然我不怎麼喜歡）。

什麼時候該用 `const`？

你可能會發現，在上面範例中，即使我是在區塊內宣告不會再被賦值的變數，我也是用 let。為什麼不用 const？這樣語義上不是更清晰嗎？

好吧，其實我也是傾向用 const，但因為我介紹的是 Simpson 的論點，所以在宣告變數的寫法上就把他對 const 的意見也一併納入了。

Simpson 認為，const 是一個有點讓人困惑的關鍵字：你不是說這個變數是常數（constant）嗎？那為什麼它又可以被修改（mutate）呢？這個誤解的確常在 JS 新手身上發生（至少我在公司面試前端的經驗是如此）。

那該在什麼時候用 const 呢？只有當你宣告的變數已經是個不可變（immutable）的值（即基本型別值，詳情可見這篇），而且它在語義上顯然是個常數時，才該用 const：

const POSTS_PAGE_SIZE = 3; // 每次要從資料庫取得的文章數量
const DEGREE_TO_PI = Math.PI / 180;
const DEFAULT_THEME = 'dark';

// 其內容之後能被修改，不建議用 `const`
const SHARE_LINK_NAMES = ['fb', 'line'];

那重新賦值的問題呢？如同上一節所說，這個錯誤很難出現，即使出現也很好察覺並修復。而且當你會用 {..} 把區塊變數包起來，這個代碼塊通常不會太長，在這短短的十幾行中要出錯實在是不太可能。

以上是 Simpson 的論點。對我來說，我認同重新賦值的問題並不大，但考量到非 JS 新手應該都能明白 const 的「不變」意指為何，我還是會繼續照一般規範走，只是要稍微忍受當看到一個由 const 宣告的變數，其內容在之後被修改時所引發的不適感。

總結：一個原則，兩個問題

當我在與別人協作，我會採用由團隊討論出來的代碼規範，或直接引入主流規範（如 Airbnb 或 Standard）。畢竟，我所喜愛的宣告方式，它的好處還無法勝過降低團隊溝通成本所帶來的優勢。但我仍會在程式碼中盡可能地用 {..} 縮小變數的作用域。

如果是我獨立開發的專案，當我碰到要宣告變數，我會問自己兩個問題。第一個：

這是整個函數內都會使用到的變數嗎？

是，就用 var 宣告在函數開始處；不是，遵循最小暴露原則，先用 {..} 括起，再問：

這個變數會被重新賦值嗎？

會，就用 let；不會，就用 const。

整個決策過程並不複雜，至少我最近在開發瀏覽器擴充套件 Notion+ 標記管理器，是使用得挺愉快的，除了程式碼變得更易讀，修改起來也較容易。

你是怎麼決定該用哪個關鍵字宣告變數的呢？你對我上面所說的一切，有什麼看法？歡迎留言給我！

（有讀者回饋，覺得將作用於整個函數的變數都用 let 宣告在函數開頭，並記得將區塊變數都用 {..} 括起來，也能達到同樣的效果，並能避免掉 var 的缺點。我同意這個看法，如果你真的覺得 var 的缺陷不容忽視，那可以這麼做。總之，本篇最重要的觀念是最小暴露原則，遵守這個原則，其它差異都非大事，只要你有深思熟慮過自己這麼做的原因就好）

在 Nuxt.js 共用 GraphQL Fragments

Thu, 01 Oct 2020 00:00:00 GMT

最近公司打 API 的方式換成 GraphQL，這邊紀錄一下怎麼在 Nuxt.js 用 GraphQL 的 fragments 特性，來達到重複使用程式碼查詢（query）的效果。

Fragments 是什麼

fragments 是什麼？簡單來說，就是一個可重用的欄位（fields）片段，你可以在裡頭放好幾個查詢欄位，接著就可以拿這個片段放到不同的查詢物件中。

最簡單的範例長這樣：

query posts {
  rightPosts: allPosts {
    ...postFields
  }
  
  leftPosts: allPosts {
    ...postFields
  }
}

fragment postFields on Post {
  id
  title
  heroImage {
    title
    urlMobileSized
  }
}

以 JavaScript 來類比，你可以想像 postFields 就是物件，而 ...postFields 就像是把物件展開（spread）一樣，能將 postFields 內聯到 rightPosts 和 leftPosts 物件中，所以最後 rightPosts 實際上是長這樣：

query posts {
  rightPosts: allPosts {
    id
    title
    heroImage {
      title
      urlMobileSized
    }
  }
}

情境闡述

這是我在專案碰到的情況：我需要在網站的不同頁面去取得最新文章，它們的查詢欄位大致相同，但仍有些欄位不是每個查詢都需要的。

最簡單的做法當然就是每個查詢都寫好自己的欄位。這個方法很快，但缺點就是重複，之後修改共同欄位需要一次改好幾個地方。

另一個方法是使用指令（directives），藉由變數（variables）來動態地更改欄位，比如這樣：

query posts($shouldQueryTitle: Boolean!) {
  allPosts {
    id
    title @include(if: $shouldQueryTitle)
  }
}

若 shouldQueryTitle 為 true，就會查詢 title 這個欄位，反之則不會。這個方法可行，但若需要客製化的欄位不少，實作起來會相當麻煩。

fragments 能怎麼解決這個問題呢？很簡單，看共用欄位有哪些，把它們抽取成 fragment，再用 ... 內聯。

這個方法還有一個好處，就是它能內聯嵌套查詢，而非在第一層就整個覆蓋。比方說，下面這塊程式碼，allPosts 有兩個 heroImage 欄位，但裡頭查詢的欄位並不同：

query posts {
  allPosts {
    ...postFields
    heroImage {      urlTabletSized
    }
  }
}

fragment postFields on Post {
  id
  title
  heroImage {    title
    urlMobileSized
  }
}

最後，heroImage 實際上是長這樣：

heroImage {
  title
  urlMobileSized
  urlTabletSized
}

這可以讓我們在享受共用欄位的同時，還能客製化出不同的查詢內容。很方便吧！

在多個檔案間共用 Fragments

如果你是在 Nuxt 中使用 GraphQL，可以參考 @nuxtjs/apollo 這個套件，它裡頭包著 vue-apollo。

要創建一個查詢，可以利用 gql 標籤直接寫在 apollo 物件裡，也可以另開一個 .graphql 或 .gql 檔。我偏好後者，因為比較好管理。

回到 fragments。若是用檔案管理的方法，fragments 一般來說會放在使用它的檔案中。但如果我要在多個檔案間共用一個 fragment，那該怎麼做？

具體情境是這樣的：我有好幾個不同的查詢物件，它們都會去查詢 heroImage 和 ogImage，而這兩個欄位也都是物件，會去查詢 tiny、mobile、tablet、desktop、original 這五種尺寸的圖片。每次查詢都要寫這 5 * 2 個欄位，實在是有點麻煩——有沒有辦法把它們抽取成一個 fragment 呢？

在單一檔案中很簡單，就直接放在下面：

query latestPosts {
  latestPosts: allPosts {
    id
    title
    heroImage {
      ...urls
    }
    ogImage {
      ...urls
    }
  }
}

fragment urls on Image {
  urlTinySized
  urlMobileSized
  urlTabletSized
  urlDesktopSized
  urlOriginal
}

但若要在多個檔案間共用，可以把這個 fragment 移入一個獨立的檔案。假設檔案結構長這樣：

apollo
├─fragments
   └─image-urls.gql <-- `urls` fragment is here!
└─queries
   ├─editor-choices.gql
   ├─collaborations.gql
   └─posts.gql

要怎麼把 image-urls.gql 導入到查詢檔案中使用呢？你可能會想說直接 import，但電腦會噴錯，因為 import 是 JS 語法，GraphQL 無法辨識。

那該怎麼辦？經過我一番搜索，其實你可以這麼做：

#import '../fragments/image-urls.gql'
query latestPosts {
  latestPosts: allPosts {
    id
    title
    heroImage {
      ...urls
    }
    ogImage {
      ...urls
    }
  }
}

只要在 import 前加上 # 變成註解，就能成功把 fragments 導進來囉（我猜這應該是 graphql-loader 的功勞，但詳細怎麼做的就不清楚了）。

區塊鏈溯源能否打擊假照片？紐約時報架了一個社群網站來驗證這件事

Tue, 04 Feb 2020 00:00:00 GMT

向假新聞宣戰早已不是什麼新鮮事了。獨立檢證、協力查核、智能辨識⋯⋯無論手段新穎或傳統，在假訊息竄增的速度面前，似乎都顯得蒼白無力，一不小心還會惹禍上身。這不禁讓人想問：還有什麼辦法？難道真理終究戰不勝謊言？人類還有救嗎？

如果你已經對於當今所有防堵假訊息的手法都感到失望，準備當個極端的懷疑論者（這也不失為一個辦法），那你也許可以稍停一下，看看我底下將要介紹的計畫，也許它能帶給你一絲希望。

去年 7 月，媒體界龍頭紐約時報（The New York Times，以下簡稱紐時）發起「新聞溯源計畫」（The News Provenance Project），期待透過區塊鏈技術揭露新聞更動源流，來讓大眾更好地區辨訊息真假或好壞。其矛頭第一個對準的就是假照片。

為什麼是假照片？區塊鏈在這整個計畫中的作用是什麼？「揭露新聞更動源流」是什麼意思？它能怎樣幫助我們辨別資訊？要達成這個目標，需要完成哪些事？以下將一一回答。

假照片破壞力強

為什麼選擇假照片？理由似乎很直觀：照片比文字更容易傳播，且具有更高的可信度，因此破壞力也就愈強。據美國獨立智庫研究顯示，相較於其它形式的假訊息，美國人民對於大眾辨識假圖片或影片的信心和責任都更少。換言之，他們既覺得大眾沒有能力辨識，也沒有義務辨識。

低落的防衛意識，使得假照片有大行其道的空間。隨著「深假」（deepfake）技術的進步，製造出高水準視覺效果的成本愈來愈低。如何在資訊生態系統崩壞之前，從結構上防制假照片的危害，顯然是當務之急。

區塊鏈如何溯源

從結構上防制？紐時究竟想怎麼做？最初的想法，是為照片加上一些元數據（metadata）及編輯紀錄。前者如拍攝時間、地點、發布者等；後者則可想像有一條時間軸，上面記錄著誰在何時取用、發布，並做了哪些更動。

舉例來說，假設阿帆今天在巴西拍到一張火噬雨林的照片，公布到臉書，並寫下：「天啊，地球之肺在燃燒！貪婪的人類終自食惡果！」阿昱看到了，順手把它載入自己的電腦。四個月後，澳洲森林發生大火，阿昱上傳這張照片，文字卻改為：「極端氣候正在吞噬澳洲！人類何時才要醒悟！」

此時悠遊於臉書河道的你，猝不及防地滑到這則貼文。怵目驚心的照片使你的手指停了下來，各種情緒頓時湧上心頭——擔憂、憤怒、恐懼、羞愧——「這麼嚴重的事情，大家應該要知道啊」，你一邊想著，一邊按下分享。

「欸？這是什麼？」你看到浮在照片下方的訊息區塊，裡頭有一行被黃色標起的文字：「四個月前拍攝」。

「四個月前？什麼鬼？這不是現在正在發生的事嗎？」你點開區塊，看見這張照片最初拍攝的時間、地點，以及發布者（阿帆）當時的貼文內容。

「殺小，該不會這是假照片吧？」你愈想愈不對勁，決定先將剛才分享貼文的隱私權限設為「只限本人」，並上網搜尋「澳洲大火」。最終你也許會發現：澳洲是真的有發生大火，但那張照片也是錯的。你不願做假訊息的幫兇，於是刪了貼文。

去年 8 月亞馬遜森林大火，便有許多錯誤照片在網路上瘋傳，連法國總統馬克宏都搞錯：他所分享的照片至少攝於 16 年前。圖擷自馬克宏推特

謝天謝地！一場錯誤內容被轉發上萬次的災難被阻止了。它靠的不是事後通知，也非事前審查，而是在訊息產生（或發布）當下，便在某處烙下一條不可更改的紀錄。它不做判斷，只呈現每次編輯的事實，讓讀者根據這些紀錄，自行決定要多相信這則訊息。

「聽起來真是不錯，」你可能會問：「但我要怎麼知道這些紀錄沒有被惡意更改過？」這就是區塊鏈發揮作用的地方了。區塊鏈是一種記錄資料的技術，一旦資料「上鏈」，便難以被竄改；同時它也是透明的，任何更改都會被記錄，且可被看見。它能確保照片元數據和編輯紀錄的真實性。

概念驗證

一個看似簡單的概念，實作起來往往有許多複雜微妙之處。

比方說，我們知道這個計畫要在照片旁邊附上一些資訊，但要放哪些資訊？更深入點問：平常人們在社群媒體上是如何決定一張照片可不可信的？不同背景的人，在判斷資訊方面又有什麼差異？我們所設想的方案，是否真的能幫助民眾更好地辨識新聞品質？

為了回答上述關鍵問題，紐時找了 34 位政治傾向、媒體偏好各異的成年人進行深度訪談和原型測試，從中歸納出了幾個值得參考的洞見。

首先，關於民眾在社群平台上如何接收、判斷新聞資訊，紐時從「對於貼文脈絡的意識程度」（只看最顯眼的照片和標題？還是也會看發文日期、來源或網友反應？）和「對於主流媒體的信任程度」這兩條軸線，將民眾分成四種類型（來看看你比較偏向哪一種類型吧）：

高意識、低信任——不信任媒體的懷疑者（Distrustful news skeptic）：認為主流媒體都是有偏見的，並會試圖從一些線索去證明，很難與特定媒體建立信任關係。值得注意的是，這些人多半是質疑媒體的報導方式，而非事實細節。
高意識、高信任——充滿自信的數位訂戶（Confident digital news subscriber）：悠游於網路世界，樂意辨識自己信任的媒體所提供的訊息真假。他們不想與時事脫節或遭到誤導。
低意識、低信任——討厭媒體的庶民（Media-jaded localist）：覺得自己的聲音遭到主流媒體所排擠，毫不遲疑地接受非正式的激昂評論（hot takes）。他們希望新聞能夠既真實又接地氣。當自己信任的非正式來源提供錯誤訊息時，他們需要更清晰的線索才能判定。
低意識、高信任——傳統的數位移民（Late-adopter media traditionalist）：相較於網路媒體的喧囂，他們更喜歡透過電視、報紙等舊媒體來接收資訊。這類人需要學習更多的判斷技巧及明確的提示，才有辦法自己區辨訊息是否可信。

紐時認為，照片溯源計畫至少能讓信任媒體的人受益（即 2、4 類人）。接著，他們測試多種能表示照片來源的設計，發現：

認證標章（如臉書或 Instagram 的藍勾勾）並不足以讓照片變得可信。
關於標示術語，讀者喜愛「附有來源」（sourced）更勝於「已驗證」（verified）。這代表大眾不只想知道照片已被他人驗證，也希望有可讓自己探索的資訊。
陳列同一個事件的多張照片，能使讀者相信事件確實發生了。
強調為人熟知的照片元數據（如圖說、發布歷史），而非會造成混亂的術語（如加密、存儲於不可更動的資料庫）。
展示監督與問責的機制，有助於提升讀者信心。
只需清楚呈現照片的編輯歷史，避免使用可能會失準的詞彙，如「真實」、「假」，因為只要出錯一次，讀者就不會再完全信任這套機制。

紐時將這些發現整合進一個模擬社群網站的原型，經過兩輪測試，確認了來源資訊確實有效，而且即使是質疑新聞立場的讀者，也沒有懷疑來源資訊的真實性。

不過仍有要改善的地方，包括有許多人根本沒注意到錯誤訊息、讀者很難理解為什麼來源訊息與照片描述不符。最有趣的是，對於照片編輯的歷史紀錄，讀者並不怎麼感興趣；反之，他們想瞭解照片所描述事件的相關新聞。這引出了一個洞見：

民眾上社群網站不是為了查核事實，而是為了娛樂和建立聯繫。他們之所以願意停下來考察更多資訊，不是因為他們想證明這張照片是錯的，而是因為他們被與照片相連的故事引起了興趣。

紐時認知到，這種傾向雖造成民眾容易為網路圖片所騙，但他們也能利用這點，讓溯源的過程不只有驗證的功能，還可以幫助讀者對自己關心的事情形成更準確、細緻的認識。

吸取以上教訓，最終紐時建出了這個概念原型：

來源資訊區塊變大了，裡頭增加了一些可引人注意的細節（如照片拍攝距今已多久）。
展開資訊區塊，你可以看見上面有一塊醒目的提示，它能喚起讀者對於假照片的警戒。
區塊下方列出關於同一事件的其它照片與文章連結，供讀者進一步探索。

概念原型：展開前。圖擷自新聞溯源概念原型網頁

概念原型：照片概觀。圖擷自新聞溯源概念原型網頁

概念原型：照片歷史紀錄。圖擷自新聞溯源概念原型網頁

大家可以自己點進網頁玩玩，看這樣的來源標示是否有助於你判斷貼文內容的真假或好壞。

這是個令人振奮的開始——但也只是開始。目前的原型僅僅是最末端的呈現，要達到預期中的效果，紐時需要跨界合作，建立一套從拍攝到發布的體系，且其運作流程還要好上手，以免排擠較小的新聞機構。這顯然是一項極為艱難的任務。

「當前的工作是確保大家以一致的方式來紀錄元數據，並讓這些資料能被其它組織（如社群平台）負責任地使用。」紐時研發團隊執行長 Marc Lavallee 說。他們在官網公開徵求三種合作夥伴——社群平台、新聞編輯室、事實查核組織——來一起把計畫推展到下一階段：執行。

一個更好的網際網路會是什麼樣子？這是紐時對於這個大哉問的初步回答。即使它最終失敗了，整個設計過程——從問題定義、用戶研究、概念發想到原型測試——仍有許多值得我們深思和借鏡的地方。

Yeefun | Feed

我知道你懂 Event Loop，但你了解到多深？

JS 單執行緒卻不阻塞的祕密

事件迴圈的基本概念

事件迴圈是怎麼運作的？

從範例了解事件迴圈

微任務的執行策略

回答開頭的問題

相關資料

初學者學 KMP 演算法

KMP 算法

Next 表

那些長得不太一樣的 Next 表

相關資料

關掉 no-var——決定變數宣告關鍵字的良好方法

`var` 很有用

最小暴露原則

取捨：評估 `var` 的缺點

什麼時候該用 `const`？

總結：一個原則，兩個問題

相關資料

在 Nuxt.js 共用 GraphQL Fragments

Fragments 是什麼

情境闡述

在多個檔案間共用 Fragments

區塊鏈溯源能否打擊假照片？紐約時報架了一個社群網站來驗證這件事

假照片破壞力強

區塊鏈如何溯源

概念驗證

相關資料

Yeefun | Feed

我知道你懂 Event Loop，但你了解到多深？

JS 單執行緒卻不阻塞的祕密

事件迴圈的基本概念

事件迴圈是怎麼運作的？

從範例了解事件迴圈

微任務的執行策略

回答開頭的問題

相關資料

初學者學 KMP 演算法

KMP 算法

Next 表

那些長得不太一樣的 Next 表

相關資料

關掉 no-var——決定變數宣告關鍵字的良好方法

var 很有用

最小暴露原則

取捨：評估 var 的缺點

什麼時候該用 const？

總結：一個原則，兩個問題

相關資料

在 Nuxt.js 共用 GraphQL Fragments

Fragments 是什麼

情境闡述

在多個檔案間共用 Fragments

區塊鏈溯源能否打擊假照片？紐約時報架了一個社群網站來驗證這件事

假照片破壞力強

區塊鏈如何溯源

概念驗證

相關資料

`var` 很有用

取捨：評估 `var` 的缺點

什麼時候該用 `const`？