深入理解 CSS position：五種定位方式的行為與比較

在 CSS 中，position 屬性決定了元素在頁面中的定位方式。雖然語法只有幾種選項，但它們的行為差異很大，掌握這些特性能幫助我們更靈活地控制版面。以下逐一介紹 static、relative、absolute、fixed、sticky 五種模式。

# Demo

已經大概懂理論的可跳過以下內容，直接看 Demo

# static（預設）

• 所有元素的預設值。
• 完全遵循文件流（normal flow）排版。
• top / left / right / bottom 無效。
• z-index 無效。
• 使用情境
• 適合大部分一般排版。

# relative（相對定位）

• 佔位與 static 一樣，仍在文件流中。
• 可以透過 top / left / right / bottom 做「相對原位」的偏移。
• 偏移後，原本的空間依舊保留 → 容易與其他元素重疊。
• 可理解為，佔位依舊，偏移只是渲染的結果，所以其他元素的佔位都跟 static 一樣，不受到影響
• 可作為子元素 absolute 的定位基準。
• 使用情境
• 小幅度調整元素位置。
• 建立「定位上下文」給子元素。

# absolute（絕對定位）

• 脫離文件流，不再佔空間。
• 依附於最近的「非 static 祖先」（relative / absolute / fixed / sticky）。
• 如果找不到，就以整個 <html> 為基準。
• 使用情境
• Tooltip、彈出視窗、容器內的絕對位置元素。
• 需要在容器中「自由擺放」的元件。

# fixed（固定定位）

• 脫離文件流，不再佔空間。
• 參考點為整個 viewport（瀏覽器視窗）。
• 捲動頁面時，位置保持不動。
• 使用情境
• 固定導覽列、浮動按鈕、全螢幕遮罩。

⸻

1. sticky（黏性定位）

• 混合 relative 與 fixed 的特性。
• 一開始跟著文件流排版（像 relative）。
• 當捲動超過指定門檻（如 top: 0），會黏在容器邊界。
• 黏附的範圍只在「最近的可捲動容器」內，不會超出容器。
• 使用情境
• 表格表頭固定。
• 容器內的區域標籤列。

# 比較表

# 一句話速記

• static：乖乖照文件流。
• relative：在隊伍裡，微調位置。
• absolute：脫隊，自由定位，但要找基準。
• fixed：脫隊，永遠固定在螢幕。
• sticky：在 scrollable 容器裡，先跟著走，遇到邊界就黏住。

CSS Position was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

使用 RAF 實作 debounce 功能

# 程式碼

React.useEffect(() => {
    // 在非 mobile 裝置上，不顯示
    if (!isMobile) {
        setShowCooperativeOverlay(false);
        if (overlayHideRafRef.current) {
            // 從 RAF queue 當中移除當前 queue 當中的 task
            cancelAnimationFrame(overlayHideRafRef.current);
            overlayHideRafRef.current = null;
        }
        return;
    }

    const showAndDebounceHide = () => {
        // 這邊是主要顯示 overlay 的開關，當 event 偵測到，就把開關打開
        setShowCooperativeOverlay((prev) => true);
        // 儲存打開的時間點
        lastActivityTsRef.current = performance.now();
        // 這個是要放入 RAF queue 的 callback，它的作用只有一個，那就是在指定的區間過後，關閉 overlay
        const tick = (now) => {
            // 由於 ref 跟 now 都是動態變動的，所以每一個 frame 都會執行該 callback，判斷是否超過指定時間區間
            if (now - lastActivityTsRef.current >= HIDE_DELAY_MS) {
                // 關閉 overlay
                setShowCooperativeOverlay(false);
                // 清理 hide ref，這樣下次又觸發時，又會塞一個進去
                overlayHideRafRef.current = null;
                // 這邊就 return 掉了，相當於 break 遞迴，所以下一個 frame 就不會再執行這個 callback
                return;
            }
            // 這邊是一個遞迴，所以每一個 frame 的 RAF 都會執行這個 callback
            overlayHideRafRef.current = requestAnimationFrame(tick);
        };

        // 如果 hide ref 是 null，那就開始遞迴 callback
        if (!overlayHideRafRef.current) {
            overlayHideRafRef.current = requestAnimationFrame(tick);
        }
    };

    const onWheel = () => showAndDebounceHide();
    const onTouchMove = () => showAndDebounceHide();

    // 監聽兩個事件，並且使用 passive 來做效能優化
    window.addEventListener('wheel', onWheel, { passive: true });
    window.addEventListener('touchmove', onTouchMove, { passive: true });

    return () => {
        window.removeEventListener('wheel', onWheel);
        window.removeEventListener('touchmove', onTouchMove);
        // 如果 hide ref 不為空，代表目前還在遞迴 callback 中，清理 RAF
        if (overlayHideRafRef.current) {
            cancelAnimationFrame(overlayHideRafRef.current);
            overlayHideRafRef.current = null;
        }
    };
}, [isMobile]);

# 示意圖

使用 RAF 實作 Debounce was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

有經驗的 MySQL 運維常常會建議 將 innodb_undo_tablespaces 设置成 2, 或更大的值，為什麼？

在 InnoDB 中，innodb_undo_tablespaces 是一個經常被提到的參數，但很多人對它的內涵並不完全清楚。本文會從 Undo Log → Rollback Segment → Undo Tablespace → I/O 機制 的角度來逐層解析，並回答為什麼 MySQL 建議將 innodb_undo_tablespaces 設為 2 或以上。

# Undo Log 的作用

在事務型資料庫中，Undo Log（撤銷日誌） 至關重要，主要功能有三：

• 事務回滾 (Rollback)：當交易失敗或顯式回滾時，Undo Log 能將資料恢復到先前狀態。
• MVCC (多版本並發控制)：查詢需要舊版本資料時，透過 Undo Log 建立一致性快照。
• 一致性保障：確保部分失敗的交易不會破壞資料正確性。

# Undo Tablespace 是什麼？

• Undo Tablespace = 磁碟檔案 (undo_001.ibt, undo_002.ibt …)。
• 這些檔案存放 Undo Pages (16KB)，裡面承載了 rollback segment 與實際的 undo log。
• 從 MySQL 5.7 開始，undo tablespace 可以獨立於系統表空間 (ibdata1) 之外管理。

# Rollback Segment 的角色

為什麼 Undo Tablespace 不直接存放「Undo Slot」？ 因為 InnoDB 引入了 Rollback Segment 這一層來做中介，主要原因有：

• 分組管理 Undo Slot：避免所有 slot 都集中在一個大結構，降低 contention。
• 更細粒度的鎖：分散鎖競爭，提升高併發能力。
• Undo Page 回收：purge thread 能以 rollback segment 為單位清理舊 undo log。
• 相容於 Oracle 的設計：這是業界常見的資料庫架構概念。

👉 可以想像：

• Tablespace = 一棟大樓
• Rollback Segment = 樓層
• Undo Slot = 房間
• Transaction = 住戶

# Undo Slot 與 Transaction

• 每個 Transaction 開始時，會從 rollback segment 取得一個 Undo Slot。
• Transaction 在執行 INSERT / UPDATE / DELETE 時，產生的 undo log 會寫進這個 slot 對應的 undo page。
• 一個 rollback segment 可以同時管理多個 transaction（因為 slot 很多）。

# 每個 Tablespace 有多少 Rollback Segment？

• 固定值：每個 undo tablespace = 128 個 rollback segments。
• 總 rollback segment 數量 = innodb_undo_tablespaces × 128。
• MySQL 5.6 時，rollback segments 全部放在 ibdata1，數量上限就是 128。
• 從 MySQL 5.7 開始，可以分散到多個 undo tablespace。

# 為什麼建議至少 2 個 Tablespace？

• 分散 I/O 壓力
• 即使一個 tablespace 有 128 rollback segments，所有 undo log 最終還是寫到同一個檔案。
• 多個 tablespace = 多個檔案 → I/O 分散，不再成為單一熱點。
• 線上清理 (Truncate) 機制
• Undo tablespace 可以被清理釋放空間，但前提是要至少有 2 個，系統才能在「清理一個」的同時「繼續使用另一個」。
• 降低鎖爭用
• 多個檔案、多組 rollback segments，能讓 transaction 的 undo log 分配更均勻，減少 slot 爭用。

# Undo Tablespace 與 Memory / Disk 的關係

• Undo tablespace 是 磁碟檔案，但實際讀寫會經過 InnoDB Buffer Pool。
• 流程如下：
• Transaction 產生 undo log → 先寫進 buffer pool 的 undo page。
• Buffer pool 定期 flush → 把修改後的 undo page 寫回 tablespace 檔案。
• 所以：
• 大部分操作在記憶體完成（接近記憶體速度）。
• 只有 flush / purge / truncate 時會實際觸發磁碟 I/O。

# Tablespace 數量 vs 高併發效能

• 更多 tablespace → 更多 rollback segments → 更多檔案 I/O 通道。
• 從 1 → 2，效益最大；從 2 → 4，仍然有幫助；再往上效益遞減。
• 官方建議：
• MySQL 5.7：innodb_undo_tablespaces=2（預設值也是 2）。
• MySQL 8.0.14+：系統自動管理，一般保留 2~4 個就足夠。

# 示意圖

# 整體結構

# 單個/多個 Tablespace 比較

# 總結

• Undo Tablespace = 磁碟檔案，裡面有 128 rollback segments，每個 segment 管理多個 undo slot。
• Transaction → Undo Slot → Rollback Segment → Tablespace → 檔案，這是完整的分層。
• 多個 tablespace 的好處：
• 分散 I/O 壓力
• 支援線上清理
• 減少鎖競爭
• 建議設定：2~4 個 tablespace，足以應付高併發，大於這個數通常沒有額外效益。

MySQL Tablespace was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

index 筆記

# index 四大原則

index 的運作有四大原則

• Fast Lookup
• Scan in One Direction
• From Left To Right
• Scan on Range Conditions

# Fast Lookup

index 最基本的動作，就是可以快速的從 index 當中找到目標，假如條件為 release_year = 2019，如果 release_year 有 index，那就是使用二分法快速尋找，如下圖

如果 index 運作正常，從百萬行甚至上億行中找資料，跟從幾千行中找資料，速度是不會差很多的

# Scan In One Direction

當 index 中的目標起始點被找到時，會由那個點開始往一個方向掃，可以是 Asc or Desc，但不可兩者共存

比方說，條件為 WHERE age >= 35 ORDER BY age ASC LIMIT 3，那執行流程如下：

• 先找到 age >= 35 的第一行
• 依照 ASC 的方向開始往下掃描
• 掃 3 行後停下

如下圖

# From Left To Right

single column index 很好理解，但通常使用 multi-column index 能更有機會達成 performance improvement

而 multi-column index 的規則就是 From Left To Right Without Skipping a Column

假如 index 為 (firstname, lastname, country)，那他只適用於以下的 query

• SELECT * FROM contacts WHERE firstname = 'James'
• SELECT * FROM contacts WHERE firstname = 'James' AND lastname = 'Walker'
• SELECT * FROM contacts WHERE firstname = 'James' AND lastname = 'Walker' AND country = 'US'

# 篩子模式

整個查詢的步驟，就像個篩子一樣，將範圍逐步地縮小。步驟可拆分如下：

• 首先，以 Fast Lookup 的方式找到最左 index firstname = ‘James’
• 篩子範圍縮小，選擇中段的 lastname = ‘Walker’ condition
• 最終再次將篩子範圍縮小 country = ‘US’ 的範圍
• 具體的步驟，如下圖

儘管 index 的 column 組成變了，但這個步驟是不會變的，比如我們將 index 改成 (firstname, lastname, country)，雖然順序變了，但篩子還是篩子

然而，如果 query 使用到 index 當中所有的 column 的話，那 multi-column index 的順序可能不重要，但大部分的情況，都是某個 query 使用到 multi-column index 當中的部分 column，這時順序就很重要

# 順序很重要

假如 condition 是 WHERE country = 'US'，那不管是 index (firstname, lastname, country)，或是 index (lastname, firstname, country) 都不適用，multi-column index 的原則是 From Left To Right，所以 country column 必須位於最左側

比方說，index (country, lastname, firstname) 就完美適用於以下的 query

• SELECT * FROM contacts WHERE country = ‘US’
• SELECT * FROM contacts WHERE country = ‘US’ AND lastname = ‘Walker’
• SELECT * FROM contacts WHERE country = ‘US’ AND lastname = ‘Walker’ AND firstname = ‘James’

# 情境列舉

當使用 multi-column index 時，大概歸納一下情境，會有以下幾種：

• query 皆為 equality check：
  - query condition 使用到的 column 都有被包含在 index 當中，且 index columns 為 condition columns 的 superset，此時是 best match。比如 index 為 (country, firstname, lastname)
  - query 為 country = ‘a’ AND firstname = ‘b’
  - country = ‘a’
  - country = ‘a’ AND firstname = ‘b’ AND lastname = ‘c’，
• query condition 使用到的 column 都有被包含在 index 當中，但 index columns 不算 condition columns 的 perfect superset，則前面符合的部分會採用 fast lookup，即二分法 log(N)，而剩餘的部分會 scan every loaded index entries。此情境不算 best match，但速度也會比沒有使用 index 來得快，因為前頭有用到 fast lookup，以及後面的 scan 此需 scan loaded index entries，如果沒有 index，則是 scan full table rows。假設 index 為 (country, firstname, lastname, age)，則以下 query 符合此情境
  - country = ‘a’ AND firstname = ‘b’ AND age = ‘c’
  - country = ‘a’ AND lastname = ‘b’ AND age = ‘c’
  - country = ‘a’ AND age = ‘c’
• query condition 使用到的 column 都有被包含在 index 當中，但 index 當中的第一個 column 不在 query condition columns 當中。index 是有順序性的，比如在 tree 中的結構像是 column1 -> column2 -> column3，所以如果知道 first column 要找的目標，那在 first column node 就可以使用二分法直接快速定位。而如果沒有使用到 first index column 的話，效能依然會比沒有使用 index 來得好，但比不上 best match。假設 index 為 **(firstname, lastname, country)**以下的 query 都可以使用到部分 index，但不是 best match
  - lastname = ‘b’ AND country = ‘c’
  - country = ‘c’ AND lastname = ‘b’
  - query 含有 range condition，假設 index 為 (country, firstname, lastname, age)
• 從 range condition 的那一個 index 開始往後的 index 都無法被使用，因為 range condition 無法預測數量，所以只能一行一行掃
• country = ‘a’ AND firstname = ‘b’ AND lastname >= ‘b’ AND age = ‘c’，此 query 當中，index country & firstname 可以被使用且快速定位縮小 lastname 須掃描的行數，而 age index 無法被使用

# 參考出處

• Index Beyond the Basics

Index — Basic Principles was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

瀏覽器事件流完整解析：Capturing、Target、Bubbling

在 JavaScript 中，DOM 事件並不是只在目標元素觸發就結束，而是會經過一個完整的 事件流 (Event Flow)。理解事件流有助於我們正確地處理事件、避免衝突，甚至做出高效的事件委派。

# 事件流的三個階段

• Capturing Phase（捕獲階段）
  事件從 window 出發
  沿著 DOM tree 從外層往內層傳遞
  直到目標元素的父層
  只有註冊了 { capture: true } 的 listener 會在這裡觸發
• Target Phase（目標階段）
  事件抵達目標元素
  觸發該元素上所有監聽器
• Bubbling Phase（冒泡階段）
  事件從目標元素往外層冒泡
  依序經過父層、祖先節點 → body → document → window
  預設的 addEventListener（不加 capture）就是在這個階段觸發

# 哪些事件不會冒泡？

• 不是所有事件都有 bubbling phase，例如：
  ❌ focus / blur → 不冒泡，但有 focusin / focusout 會冒泡
  ❌ mouseenter / mouseleave → 不冒泡，但對應的 mouseover / mouseout 會冒泡
  ❌ scroll、resize、load、error → 不冒泡
• 這些事件依然有捕獲和目標階段，只是冒泡結束在目標元素。

# Input 與 Change 事件

• input：輸入框內容一變就立刻觸發，並且會冒泡。
• change：只有在元素失去焦點（blur）且值有變化時才觸發。
• 在子 input 打字時，父層 也能透過事件冒泡捕捉到 input 事件。

# Void Elements 限制

• 某些元素屬於 void elements，不能包含子元素，因此不可能成為 parent。
• 常見的有：<input>、<img>、<br>、<meta>、<link>…
• 子 input 不會觸發父 input 的事件 listener，因為結構上就不可能出現「input 包 input」。
• 事件只會冒泡到合法的父容器（如 <div>、form、body）。

# Modal 的冒泡

• 如果是一般容器元素（如 modal <div>），子 modal 的事件會冒泡到 parent modal。
• 如果希望父 modal 接手事件 → 直接監聽父元素。
• 如果不希望父 modal 介入 → 在子元素呼叫 event.stopPropagation()。

# 兄弟元素不會互相觸發

• 事件冒泡方向是「子 → 父 → 祖先」，不會橫向傳遞到兄弟元素。
• 點擊一個 ，不會觸發另一個兄弟 的事件。

# 為什麼要 stopPropagation？

• 有些情境下，我們需要確保事件只由自己處理，不讓其他 listener 攔走，例如：
  - 全域 ESC handler
  - 表單驗證失敗時阻止後續送出
  - 避免不同 library 的衝突
• 常見的控制方法：
  - preventDefault() → 阻止瀏覽器預設行為
  - stopPropagation() → 阻止事件繼續冒泡
  - stopImmediatePropagation() → 阻止冒泡，並且阻止同一元素的後續 listener

# stopImmediatePropagation 的特殊情境

• 當同一個元素有多個 listener 時：
  - stopPropagation() 只會阻止冒泡，後續 listener 仍然執行。
  - stopImmediatePropagation() 會立刻中斷，讓同一元素的後續 listener 不再執行。
• 範例

btn.addEventListener("click", () => console.log("A"));
btn.addEventListener("click", (e) => {
  console.log("B stopImmediatePropagation");
  e.stopImmediatePropagation();
});
btn.addEventListener("click", () => console.log("C")); // ❌ 不會執行

# Listener 的執行順序

1. 先註冊 → 先執行
   - 同一元素、同一事件類型、同一階段下，listener 按 addEventListener 的註冊順序執行。
2. 捕獲 vs 冒泡
   - 捕獲階段的 listener（capture: true）先於冒泡 listener。
3. 中斷控制
   - stopPropagation()：事件仍會執行同一元素的後續 listener，但不再冒泡。
   - stopImmediatePropagation()：事件立即停止，不執行後續 listener。

# 總結

• 事件流分為 捕獲 → 目標 → 冒泡 三個階段。
• 大多數事件會冒泡，但有些事件是例外（focus、mouseenter、scroll 等）。
• input 與 change 的差異在觸發時機，且 input 會冒泡。
• void elements 不能有子元素，因此不會成為 parent。
• modal 等容器元素會接收子元素的冒泡事件。
• sibling 元素之間不會互相觸發事件。
• stopPropagation 與 stopImmediatePropagation 可用來控制事件流，避免衝突。
• listener 執行順序取決於註冊順序與階段。

Browser — Event Flow was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

寫前端時常常會調用到 window，所以這是什麼呢？

# 解釋

在瀏覽器（Browser）的語境中，window 是一個全域物件（global object）。它代表瀏覽器中開啟的一個視窗或標籤頁。

簡單來說：

• 在 JavaScript 裡，window 就是瀏覽器給你操作「當前視窗／頁面」的介面。
• 幾乎所有瀏覽器提供的 API（例如 alert()、setTimeout()、document 等）都是 window 物件的屬性。

# window 的角色

• 全域命名空間
  - 在瀏覽器裡宣告的全域變數或函式（var foo = 123;）其實會掛載到 window.foo 上。
  - window.alert(“hi”) 與 alert(“hi”) 等效。
• 控制視窗
  - 包含當前視窗的大小與位置：window.innerWidth, window.innerHeight。
  - 可以開新視窗或操作現有的（受瀏覽器安全性限制）：window.open(…)。
• 事件與生命週期
  - 載入事件：window.onload = function () {…}。
  - 卷動事件：window.onscroll = …。
• 存取其他物件
  - window.document：代表 DOM 文件（HTML）。
  - window.localStorage, window.sessionStorage：儲存資料。
  - window.location：存取網址資訊。

# 架構圖

# 總結

在瀏覽器中，window 就是 JavaScript 的全域物件，提供操作「瀏覽器視窗 / 標籤頁」以及「頁面 DOM」的入口。

Browser — window was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

在前端中常常會調用到 Document，所以它到底是什麼？

# document 的定位

• 來源：由瀏覽器在載入 HTML 時自動建立。
• 性質：一個 物件，是 瀏覽器提供給 JavaScript 的 API。
• 用途：代表目前載入的整份 HTML 文件（DOM 樹），讓 JS 可以讀寫它。

# 為什麼需要 document

• JavaScript 自己不認識 HTML，它只是一門程式語言。
• 瀏覽器透過 document 把 HTML DOM 揭露出來，讓 JS 能這樣操作：
• 找元素
  const root = document.getElementById("root");
• 改變內容
  root.textContent = "Hello World";
• 新增節點

const btn = document.createElement("button");
btn.textContent = "Click me";
root.appendChild(btn);

# 和 DOM 的關係

• DOM (Document Object Model) 是 HTML 文件的結構化表示（像樹狀結構）。
• document 是這個 DOM 的入口點。
• 所以我們說：
  DOM = 資料結構（整棵樹）。
  document = 瀏覽器提供的 API，用來讀寫 DOM。

# 示意圖

# 小結

是的，document 就是瀏覽器提供的 API，讓 JS 可以操作 DOM（新增、刪除、修改、監聽事件）。

瀏覽器中的 Document was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

• 請 AI 幫我寫了一個 判斷是否為 mobile browser 的 hook，現在回頭理解這段程式碼
• 本篇的主題在於理解下面的 React 程式碼
• 學習重點為
• RAF (Request Animation Frame)
• CAF (Request Animation Frame)
• MQL (Media Query List)

# RAF

• RAF 方法通知瀏覽器我們想要產生動畫，並且要求瀏覽器在下次重繪畫面前呼叫特定函數更新動畫。這個方法接受一個引數作為下次重繪前調用的回呼函數，簡單理解就是，我告訴瀏覽器，下次重繪畫面前，執行我指定的 callback
• 何時是下次重繪前？ 這取決於 FPS (Frame Per Second)，如果 FPS 為 60，那就是每秒執行 60 次，所以大概就是 1/60 秒約 160 ms
• 所以是每 160 ms 都會跑一次嗎？ 不是的，每次呼叫 RAF，它只會執行一次，執行的時機點為 下次重繪前
• 可以理解為有一個 RAF Queue，在 160 ms 內呼叫多次 RAF 時，就相當於往這個 queue 裡面塞了多個 callback，而 160 ms 一到，瀏覽器就會執行這個 queue 內的所有 callback，然後清除 queue
• 當執行 RAF 時，瀏覽器會往 RAF queue 當中塞進指定的 callback，然後給該 callback 一個 ID 並且回傳該 ID

# CAF

• CAF 其實就是從 RAF Queue 當中把指定的 callback 移除，所以要帶 ID 進去

# 程式碼

export const useResponsive = () => {
    // detectIsMobile() 的文章位置，上面有提到
    const [isMobile, setIsMobile] = useState(() => detectIsMobile());
    const frame = useRef(0);

    useEffect(() => {
        // RAF & CAF 的邏輯，上面有解釋。所以這段的邏輯，就是建立一個 callback，這個 callback 每次執行時，會先檢查
        // frame 是否已經被佔用了，這個 frame 會放 RAF 的回傳，也就是 RAF Queue 當中的 callback ID
        // 如果已經被佔用了，我們就使用 CAF，把它從 RAF Queue 當中移除，避免重繪前一次執行多個 callback
        // 所以可以將 frame 理解為一個 slot，它每次只允許一個 RAF Queue callback ID 存在，進而確保 
        // RAF Queue 在每一個 frame 的週期內，不會出現多個 callback
        const update = () => {
            // rAF coalescing to avoid update storms
            if (frame.current) cancelAnimationFrame(frame.current);
            frame.current = requestAnimationFrame(() => setIsMobile(detectIsMobile()));
        };

        // 這邊從 Window 當中取得這兩種 Media Query List 的物件
        // 如果瀏覽器不支援，那會有 error，就把值設為 null
        // filter 會濾掉 value 為 null 的物件
        const mqls = [
            '(any-pointer: coarse)',
            '(any-hover: none)',
        ].map(q => {
            try {
                return window.matchMedia(q);
            } catch {
                return null;
            }
        }).filter(Boolean);

        // 只要觸發 resize event，就執行 update callback，來重新偵測是否 mobile 裝置
        window.addEventListener('resize', update);
        // 只要這兩個 Media Query List 物件有變化，那也執行 update callback 來重新偵測是否 mobile 裝置
        mqls.forEach(mql => mql.addEventListener?.('change', update));

        // cleanup
        return () => {
            window.removeEventListener('resize', update);
            mqls.forEach(mql => mql.removeEventListener?.('change', update));
            if (frame.current) cancelAnimationFrame(frame.current);
        };
    }, []);

    return isMobile;
};

# 總結

上面的程式碼主要可以分成兩個部分的邏輯

• update 邏輯主要在於優化，他的效果相似於 Debounce 概念，都是避免 當 event 大量觸發時，大量地觸發 detectIsMobile callback
• RAF & CAF 的搭配使用，確保 detectIsMobile() 在每 160 ms 內只會被執行 1 次
• 也可以用 setTimeout 來實作，在極短時間內其實不會有區別，但 RAF & CAF 是瀏覽器原生的功能，可以確保 在每一個 frame 都會被執行
• 另一個部分，就是將 update 作為事件觸發的 listener
• CAF 的使用至關重要，否則會造成每一個 frame 週期內的 RAF Queue 都塞入了大量的 callback
• 下面提供有無使用 CAF 的差異圖

# 有 CAF 優化

# 無 CAF 優化

# Reference

• AI
• Documentation

藉由實戰理解 Request Animation Frame was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

身為一個後端工程師，如果把自己侷限於後端，那格局就小了

學習 Prevent Default 基礎知識

# 概念解析

# 瀏覽器的預設行為

• 表單送出，點擊預設會送出表單

<form>
  <button type="submit">送出</button>
</form>

• 連結跳轉，點擊會預設跳轉

<a href="https://example.com">Example</a>

• 按 ESC → 瀏覽器可能會退出全螢幕
• 按 Space → 預設會滾動頁面
• 按 Ctrl+S → 預設會觸發瀏覽器的「儲存網頁」

# 阻擋瀏覽器行為

event.preventDefault() 的用途，就是阻止瀏覽器對某些 HTML 元素或操作的「預設行為」。

• 表單送出，點下按鈕時，瀏覽器會預設送出表單並重新載入頁面

<form>
  <button type="submit">送出</button>
</form>

• 用 e.preventDefault() 可以攔截掉，改成用 JavaScript 處理。

form.addEventListener('submit', (e) => {
  e.preventDefault();
  console.log('攔截送出，自己處理 AJAX');
});

• 連結跳轉，點擊會預設跳轉。

<a href="https://example.com">Example</a>

• 用 preventDefault() 可以阻止跳轉：

link.addEventListener('click', (e) => {
  e.preventDefault();
  console.log('不跳轉，改成彈窗');
});

• 按 ESC → 瀏覽器可能會退出全螢幕
• 按 Space → 預設會滾動頁面
• 按 Ctrl+S → 預設會觸發瀏覽器的「儲存網頁」
• preventDefault() 就能攔截，交給你自己的程式處理。

# 參考

• 文件
• AI

理解 Prevent Default was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.

產品使用了複數的第三方的 API key 以達到 API key rotation，目的在於提高 rate limit，事先跟第三方確認過這是合乎他們規範的，而且他們只認 key 且不會鎖 IP。 但從 log 上可以看到第三方的 API 偶有 error，想進一步判斷這個 error 是否是因為第三方的 rate limit 所造成

# 解決方式

• 使用 Vegeta 來併發 request，並根據結果來判斷
• 使用了 3 把 key，每把的 rate limit 是 30 / second
• 建立 3 個 txt file，分別為
  key1.txt
  key2.txt
  key3.txt
• 內容都很單純，如下
  GET https://apiUrl?apiKey=key1&otherQuery=query
• 開三個 terminal tabs，分別執行 3 個 Vegeta command with different txt file
  vegeta attack -rate=29 -duration=120s -targets=key1.txt | vegeta report
• 然後就可以根據書出來判斷 有沒有被 429 or 其他 error

Requests      [total, rate, throughput]         3480, 29.01, 28.60
Duration      [total, attack, wait]             2m2s, 2m0s, 1.697s
Latencies     [min, mean, 50, 90, 95, 99, max]  219.419ms, 1.031s, 356.828ms, 955.369ms, 2.013s, 20.493s, 28.371s
Bytes In      [total, mean]                     31010849, 8911.16
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:3480  
Error Set:

• 資料顯示，2 m 2s 發出 & 收到 3480 個 request with 200 status，平均每秒 29 個 request。3 個 tabs 的結果都沒有 error，代表 起碼在 2 分鐘的時間間隔，第三方服務不會根據總 request 的數量來封鎖 IP

Rate Limit 測試 with Vegeta was originally published in Learn or Die on Medium, where people are continuing the conversation by highlighting and responding to this story.