
在處理一些 input 功能時可能會碰到 [composition event](https://developer.mozilla.org/en-US/docs/Web/API/CompositionEvent),
會在使用者組字的時候觸發, 就像中文是用注音組起來的

其中一個應用場景像是搜尋視窗, 輸入字後會推薦類似的關鍵字, 如果這個 input 支援鍵盤的上下左右選擇推薦關鍵字的話, 我們在選字的時候就會觸發不預期的行為,
這個時候就要判斷 composition event 來避免這個 issue

## Composition Event

可以先用以下的例子玩玩看, 觀察 log 出現的時機, 我在 input 上面分邊加上了 **onChange**, **onCompositionStart**, **onCompositionUpdate**, **onCompositionEnd** 這幾個事件

<IFrame src={`<iframe src="https://codesandbox.io/embed/composition-raw-t8p6t?fontsize=14&hidenavigation=1&theme=dark"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="composition raw"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>`} />

特別想講的是, 可以分別用 Chrome & Firefox & Safari 玩玩看, 會發現事件出現的順序不太一樣, 當輸入**你**時

Chrome
1. compositionstart:  
2. compositionupdate:  
3. onChange value ㄋ 
4. compositionupdate: ㄋ 
5. onChange value ㄋㄧ 
6. compositionupdate: ㄋㄧ 
7. onChange value 你 
8. compositionupdate: 你
9. compositionend: 你 

Firefox
1. compositionstart:  
2. compositionupdate:  
3. onChange value ㄋ 
4. compositionupdate: ㄋ 
5. onChange value ㄋㄧ 
6. compositionupdate: ㄋㄧ 
7. onChange value 你 
8. compositionend: 你 

Safari
1. compositionstart:  
2. compositionupdate:  
3. onChange value ㄋ 
4. compositionupdate: ㄋ 
5. onChange value ㄋㄧ 
6. compositionupdate: ㄋㄧ 
7. onChange value 你 
8. onChange value "" 
9. onChange value 你 
10. compositionend: 你 

會發現這三家瀏覽器對於 composition event 的順序以及數量完全不一樣XD, 稍微簡化一下把前六步省去 (都一樣)

Chrome 
1. onChange value 你 
2. compositionupdate: 你
3. compositionend: 你 

Firefox
1. onChange value 你 
2. compositionend: 你 

Safari
1. onChange value 你 
2. onChange value "" 
3. onChange value 你 
4. compositionend: 你

稍微整理一下
- 最後都是觸發拼字完成事件 **compositionend**
- **Safari** 不知道怎麼回事會多觸發兩次 **onChange** 
- 只有 **Chrome** 會在最後拼字成功時再觸發一次 **compositionupdate** (**onChange** 之前)

其實就算再怎麼怪, 平常實作沒遇到問題應該都不會注意到

那你問我為什麼要研究這個？當然是因為我碰到了某個坑居然跟這些順序事件有關(我的天), 原本是想查相關文件找說為什麼每家瀏覽器不一樣,
但這個事件相關的資料實在太少, 我猜可能是因為只有會需要組字的國家才會碰到的關係QQ, 總之先對這些差異有印象, 讓我來說說我遇到了什麼坑

## 奇怪的 BUG

事件的起因是我需要實作一個 input, 使用者可以輸入數字, 並且會幫 user 自動在千分位上加上逗點 (ex: 1,000), 在需要輸入金額的網站上應該蠻常見的

直覺上先直接在 **onChange** 的事件中把 value 中的 **,** 去掉, 在轉成數字並用 [toLocaleString](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toLocaleString#examples)
加上逗號, 可以直接看以下這份 codesandbox

<IFrame src={`<iframe src="https://codesandbox.io/embed/composition-fail-lfkqr?fontsize=14&hidenavigation=1&theme=dark"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="composition fail"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>`} />

OK, 一切沒問題, 當我非常有信心時, QA 居然發了一個 bug ticket 給我, 內容是當使用 windows 系統且在中文輸入法下使用鍵盤右側數字, 輸入到 1000 時會變成 10,000

蛤, 我當下看到 ticket 時候真的在座位上蛤了一聲XD, 覺得這到底殺小, 我只好起身走到共用的 windows 電腦嘗試 reproduce 這個問題

不試還好, 試了還發現真的會 XDDDD, 大家可以用以上的 codesandbox 試試看, 並觀察 log

**會發現在中文輸入法的狀況下使用鍵盤右側的數字鍵, 雖然實際上沒有組字但卻會觸發 composition event**, 而且順序跟上面提到的不太一樣..

還發現只有在 **Chrome** 才會發生, Firefox 並不會

用 Firefox 從 100 再按下一個 0 時, log 會是這樣 (可能之後補 GIF || VIDEO)

1. compositionstart 100
2. compositionupdate 100
3. compositionend 1000
4. onChange value 1,000

來對照最原本輸入**你**的時候 Firefox 會是怎樣

1. compositionstart:  
2. compositionupdate:  
3. onChange value ㄋ 
4. compositionupdate: ㄋ 
5. onChange value ㄋㄧ 
6. compositionupdate: ㄋㄧ 
7. onChange value 你 
8. compositionend: 你

由於其實不是組字, 所以會直接觸發 compositionend (不用按下 enter) 後才觸發 onChange

Chrome 的話, 在還沒到千分位的時候假設先輸入 **1** log 會是這樣

1. compositionstart
2. compositionupdate
3. onChange value 1
4. compositionupdate 1
5. compositionend: 1

會發現這裡就會跟輸入中文的時候一樣, 會先 onChange -> compositionupdate -> compositionend

那從 100 再輸入一個 0 的話 log 會是如何呢 ?

1. compositionstart 100
2. compositionupdate 100
3. onChange value 1,000
4. onChange value 10,000

會發現 **onChange** 多觸發一次, 且 **compositionupdate** 和 **compositionend** 都沒觸發到

後來我做了一個假設 (以下都是自己的假設, 沒有 spec 可以證明, 也有可能是 chrome 的 bug)

由於事件發生的的順序不同, Firefox 會在最後才觸發 onChange, 但 Chrome 會先觸發 onChange -> compositionupdate -> compositionend

我們在 100 輸入 0 的時候把 **e.target.value(1000)** 變成 1,000 使 input element 的 value 顯示 1,000

我猜 chrome 可能預期 compositionend 的時候 value 應該是 1000, 但其實 input 的 value 已經變成 1,000 了

造成 chrome 的程式碼進入某段 condition 從而沒觸發到 **compositionupdate** 和 **compositionend** 且再次觸發 onChange 才會讓最後多一個 0

所以那個時候我就想說試試看在**組字的途中讓 input 的值都是最原始的**, 這樣 chrome 就不會誤判了, 可以參考以下 codesandbox

<IFrame src={`<iframe src="https://codesandbox.io/embed/composition-succeed-ipvzp9?fontsize=14&hidenavigation=1&theme=dark"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="composition succeed"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>`} />

主要就是偵測使用者當下是不是在組字, 觸發 **compositionend** 就代表組字完成

```js
  const [isComposition, setIsComposition] = useState(false);
  const handleComposition = (e) => {
    console.log(e.type, e.target.value);
    setIsComposition(e.type !== "compositionend");
  };
```

如果在 **isComposition** 的情況下, 讓 input 的 value 不要有逗點

```js
  <input
    value={isComposition ? value.replace(/,/g, "") : value} // 讓 value 保持不要有逗點
    onChange={handleChange}
    onCompositionStart={handleComposition}
    onCompositionUpdate={handleComposition}
    onCompositionEnd={handleComposition}
  />
```

這樣 chrome 在組字的時候就不會發生**預期 compositionend 的時候 value 應該是 1000, 但其實 input 的 value 已經變成 1,000 的情況**, 從而解決這個 bug

而這個 bug 只會在 chrome 發生, 因為只有 chrome 會在**最後的 compositionupdate & compositionend 前再觸發一次 onChange**

以上是我的假設, 要更清楚的話照理來說應該要去翻 Chrome 和 Firefox 的 source code... 但 root cause 應該是這樣沒錯,
當初為了解這個 bug 花了一整天.. 之後有空再去嘗試翻翻看瀏覽器對於這部分的實作








瀏覽器的 composition event


Apollo Client 其中一個功能就是快取, 藉由設定 [fetch policy](https://www.apollographql.com/docs/react/data/queries/#supported-fetch-policies) 來降低發送需求的數量,
之前在專案使用時碰到了一些問題, 在這邊紀錄一下

## Apollo Client 如何快取

要先探討快取問題首先應該要知道的是 Apollo Client 是怎麼進行快取的

```js
[{
  id: 1
  title: hello
  __typename: Article
}, {
  id: 2
  title: hello2
  __typename: Article
}]
```

假設有一隻 API 拉文章, 回傳的格式大概會是上面那樣子, [__typename](https://www.apollographql.com/docs/apollo-server/schema/schema/#the-__typename-field)
是 Apollo 內部自己自動產生的 (根據後端設計 API type 決定)

Apollo 的快取就是根據 **id** 以及 **__typename** 進行, 下次 request 如果發現有相同的 id & __typename 就不會再次發送 request, 而是用前一次的結果

但是有時候在設計後端 schema 的時候不一定會想要把 id 當作 unique primary key, 像是可能會用身分證字號當作 primary key

```js
Member {
  idCardNumber: string;
  name: string;
}
```

像是上面那樣, 可能會是用 **idCardNumber** 來當作 primary key, 但前面提到 Apollo 快取是根據 **id** 以及 **__typename**, 如果後端回傳格式沒有 id,
那麼 Apollo 就無法進行快取了

這時候要馬拜託後端把它改成 id (不太可能XD), 要馬就是在前端建立 Apollo instance 的時候客製化想要的 cache ID,
在建立 **InMemoryCache** 時可以傳入 **typePolicies** 來決定某個 __typename 要的 cache ID 是什麼, 如果是上面的例子就會是這樣

```js
const cache = new InMemoryCache({
  typePolicies: {
    Member: {
      keyFields: ["idCardNumber"],
    },
  },
});
```

這樣 apollo 在遇到 **Member** 這個型別時就會用 **idCardNumber** 當作快取依據了, 更詳細的可以參考[這邊](https://www.apollographql.com/docs/react/caching/cache-configuration/#customizing-cache-ids)

## 多對多的資料庫設計

你可能會納悶說怎麼突然提到這個XD 因為我所碰到的快取問題是從**多對多的資料庫設計**產生的

假設今天要設計資料庫, 規格是產品會有多個顏色, 其中會有一個主要顏色, 而顏色不一定只屬於特定產品, 其他產品可能也會有同個顏色

這個時候應該就會往多對多的方向去設計, 從而產生三張表

```js
Product {
  id: number;
  name: string;
}

Color {
  id: number;
  name: string;
}

ProductColor {
  productId: number;
  colorId: number;
  isPrimary: boolean;
}
```

看起來沒有問題, 拉取資料時再進行 join 的動作就可以了, 前端預期拉資料回來的樣子大概會是這樣

```js
{
  data: {
    products: [
      {
        id: 1,
        name: '產品一',
        colors: [
          {
            id: 1,
            name: 'Red',
            isPrimary: true,
            __typename: 'Color',
          },
          {
            id: 2,
            name: 'Yellow',
            isPrimary: false,
            __typename: 'Color',
          },
        ]
        __typename: 'Product'
      },
      {
        id: 2,
        name: '產品二',
        colors: [
          {
            id: 1,
            name: 'Red',
            isPrimary: false,
            __typename: 'Color',
          },
          {
            id: 3,
            name: 'Blue',
            isPrimary: true,
            __typename: 'Color',
          },
        ]
        __typename: 'Product'
      },
    ],
  } 
}
```

有兩個產品分別是**產品一** 和 **產品二**. **產品一**有兩個顏色分別是紅和黃, 其中主要顏色是紅色,
**產品二**有兩個顏色分別是紅和藍, 其中主要顏色是藍色

那麼 Apollo 會如何進行快取呢?

1. 產品一的 **Product** 和 **Color** 內的 **id** 和 **__typename** 在快取內都不存在, 於是把產品一和兩種顏色 (紅和黃) 丟進快取內
2. 產品二雖然不在快取內, 但是產品二中有紅色的快取(相同 **id** 和 **__typename**), 所以**產品二的紅色會重複利用產品一的紅色 Object**, 至於藍色因為沒出現過所以會把這次結果丟進快取, 也會把產品二丟進快取

看出問題了嗎？**產品二會重複利用產品一出現的紅色造成主要顏色錯誤**, 實際上前端拿到的產品二會是

```js
      {
        id: 2,
        name: '產品二',
        colors: [
          {
            id: 1,
            name: 'Red',
            isPrimary: true, // <-- 這裡重複用了產品一的紅色, 所以 isPrimary 會是 true
            __typename: 'Color',
          },
          {
            id: 3,
            name: 'Blue',
            isPrimary: true,
            __typename: 'Color',
          },
        ]
        __typename: 'Product'
      },
```

由於快取的關係導致回來的資料不符合預期, 產品二有了兩個主要顏色, 不過照理來說同樣的 id 本應得到相同的結果, 不然就不叫做 id 了

在這個問題中最佳的解法應該是後端要更改產品回傳的 schema, 將 isPrimary 移除，回傳的欄位多新增一個 primaryColor

```js
type Color {
  id: number;
  name: string;
}

type Product {
  id: number;
  name: string;
  colors: Color[];
  primary_color: Color;
}
```

但是有可能後端系統的架構很複雜導致更改困難或者有其他難處, 在前端我們可以選擇不要快取 Color, 前面提到我們是利用 id 以及 __typename 進行快取, 那麼我們只要把 id 或者 __typename 移除就可以了

```js
// alias id as something else
{
  products {
    id
    name
    colors {
      colorId: id
      name
      isPrimary
    }
  }
}

// exclude __typename field
{
  products {
    id
    name
    colors {
      id
      name
      isPrimary
      __typename @skip(if: true)
    }
  }
}
```

## Reference

- [Elusive Bugs with GraphQL Object Caching in Apollo Client](https://kamranicus.com/graphql-apollo-object-caching/)


談談 Apollo Cache


## Stacking without z-index

首先提一下在正常狀態下 (沒有 z-index) 的情況, 元件會怎麼堆疊, 從下到上的規則是

1. 根元素 (root element)
2. 根元素裡 **non-positioned** 的元素, 並按照 html 中出現的順序
3. 根元素裡 **positioned** 的元素, 並按照 html 中出現的順序

只要元素 css **position** 屬性的值不是 **static** (預設值), 就是 **positioned** 元素 (relative, fixed, sticky, absolute)

以下是我從 [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/Stacking_without_z-index) 拿的範例, 可以發現 Element 5 在 html 順序中雖然是在最後面, 但因為它是 **non-positioned** 元素, 所以會被蓋過去

<IFrame src={`<iframe height="500" style="width: 100%;" scrolling="no" title="Stacking without the z-index MDN" src="https://codepen.io/anymore0505/embed/popKYoP?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/anymore0505/pen/popKYoP">
  Stacking without the z-index MDN</a> by Chen Yu Wang (<a href="https://codepen.io/anymore0505">@anymore0505</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>`} />

## Stacking with z-index

如果想要自己另外決定堆疊順序的話, 就可以使用 **z-index** 來決定順序, 特別注意的是 z-index 只對 **positioned** 的元素有用

數字越大就會在越上面, 如果數字相同的話就依照沒有 z-index 時的堆疊規則

以下也是從 [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/Adding_z-index) 來的

<IFrame src={`<iframe height="500" style="width: 100%;" scrolling="no" title="Stacking with z-index (from MDN)" src="https://codepen.io/anymore0505/embed/YzYvgBw?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/anymore0505/pen/YzYvgBw">
  Stacking with z-index (from MDN)</a> by Chen Yu Wang (<a href="https://codepen.io/anymore0505">@anymore0505</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>`} />

## The Stacking Context

那什麼是 **Stacking Context** ? 在前面我們已經知道如果對 positioned 的元素加上 z-index 會對堆疊順序有所影響, 這都是因為其實他們在背後形成了 stacking context

我們先來看看什麼情形會建立 stacking context

1. 當元素是網頁根元素 (其實就是 html)
2. 當元素被設定 position **absolute** 或 **relative**, 然後 z-index 設定為除了 auto 以外的值
3. 當元素被設定 position **fixed** 或 **sticky**
4. 當父元素是 **flex container** 或 **grid container**, 然後 z-index 設定為除了 auto 以外的值
5. 當元素設定了 opacity 且值小於 1

其他還有比較少見到的情況這裡就先不筆記了, 有興趣可以去查閱 MDN

只要產生了 stacking context, 那麼堆疊的順序就會由前面所解釋的方式去進行, 總結來說會是這個順序

1. 執行堆疊的根元素
2. **positioned** 的元素, 且 z-index 為負數
3. **non-positioned** 的元素
4. **positioned** 的元素, 且 z-index 為 **auto**
5. **positioned** 的元素, 且 z-index 為 正數

只要搞懂 stacking context 如何產生以及排序的規則, 我們在排版的時候腦內就會有更清楚的架構,
或是當設定 z-index 時的結果不符合預期時, 大概可以猜測在上層元素中說不定有元素已經產生了 stacking context 了

來看看幾個例子, 下面這個也是從 MDN 來的

<IFrame src={`<iframe height="500" style="width: 100%;" scrolling="no" title="Stacking context from mdn" src="https://codepen.io/anymore0505/embed/popKBVB?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/anymore0505/pen/popKBVB">
  Stacking context from mdn</a> by Chen Yu Wang (<a href="https://codepen.io/anymore0505">@anymore0505</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>`} />

可以發現 DIV3 自己產生了 stacking context, 所以 DIV4, DIV5, DIV6 就會在 DIV3 內根據規則排序,
DIV3 內的元素排序完成後, 整個 DIV3 才會跟 DIV1, DIV2 去做相對應的排序

如果將 DIV3 的 **z-index** 移除, 也就是說不符合形成 stacking context 的規則的話, 就會變成以下這樣

<IFrame src={`<iframe height="500" style="width: 100%;" scrolling="no" title="Stacking context 2" src="https://codepen.io/anymore0505/embed/xxpzeQE?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/anymore0505/pen/xxpzeQE">
  Stacking context 2</a> by Chen Yu Wang (<a href="https://codepen.io/anymore0505">@anymore0505</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>`} />

因為 DIV3 沒有形成 stacking context, 所以這幾個元素都隸屬於同個 stacking context (html)

再來看相關的例子, 我是從 andyou 的 [blog](https://andyyou.github.io/2016/03/03/z-index/) 中看到的

<IFrame src={`<iframe height="300" style="width: 100%;" scrolling="no" title="Untitled" src="https://codepen.io/andyyou/embed/ZWGvwV?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/andyyou/pen/ZWGvwV">
  Untitled</a> by andyyou (<a href="https://codepen.io/andyyou">@andyyou</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>`} />

html 的結構是以下這樣

```js
div
  span class="red" RED
div
  span class="green" GREEN
div
  span class="blue" BLUE

.red, .green, .blue {
  width: 100px;
  color: white;
  line-height: 100px;
  text-align: center;
  position: absolute;
}

.red {
  z-index: 1;
  background: red;
  top: 20px;
  left: 20px;
}

.green {
  background: green;
  top: 40px;
  left: 40px;
}

.blue {
  background: blue;
  top: 60px;
  left: 60px;
}
```

把第一個 span 的 z-index 設定成1, 讓它顯示在最上面

作者給了一個挑戰是試看看能不能把紅色區塊的 span 排到藍色和綠色 span 的後面，但要遵循下面的規則。

- 不能修改 HTML 結構
- 不能加入或修改任何元素的 z-index
- 不能加入或修改任何 position 屬性

最後解答是加入一個小於 1 的 opacity 到紅色 span 的爸爸元素即 div, 相信到這裡大家也應該能馬上明白為什麼,
**opacity < 1** 正是建立 stacking context 中的一個條件

<IFrame src={`<iframe height="300" style="width: 100%;" scrolling="no" title="Untitled" src="https://codepen.io/andyyou/embed/oxXEvx?default-tab=result" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href="https://codepen.io/andyyou/pen/oxXEvx">
  Untitled</a> by andyyou (<a href="https://codepen.io/andyyou">@andyyou</a>)
  on <a href="https://codepen.io">CodePen</a>.
</iframe>`} />

## Reference

- [Stacking Context](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context)
- [深入 css z-index 屬性](https://andyyou.github.io/2016/03/03/z-index/)


Stacking Context 和 z-index


Next.js 終於在 [12.1](https://nextjs.org/blog/next-12-1#on-demand-incremental-static-regeneration-beta) 推出 on demand ISR 的功能, 讓 developer 可以主動去觸發更新 static page,
而不是設定 revalidate time 去觸發, 簡單筆記一下這個功能到底在幹嘛吧~~

再繼續看之前可以先把下面兩篇複習一下

- [淺談 getInitialProps, getServerSideProps Part1](/blog/getinitialprops-and-getserversideprops-part1)
- [淺談 getInitialProps, getServerSideProps Part2](/blog/getinitialprops-and-getserversideprops-part2)

## ISR 

ISR - Incremental Static Regeneration

當初 Next.js 為了解決 SSG 的內容 (getStaticProps) 需要改動時, 整個網站就必須重新上版的缺點, 讓開發者可以設定 **revalidate time**,
表明一但超過這個時間, 下一次使用者再次進來該頁面, next.js 會在背景重 build 這頁面, 當這個頁面重新 build 完後, 下次使用者進來就會看到新的頁面！

這個功能很棒, 但還是有一些缺點

1. 只能設定 revalidate time 來決定 re-build 的時機
2. 沒辦法知道何時 re-build 完成
3. 只有使用者第一次直接到該頁面才會觸發 revalidate, next/link next/router routing 過去的不會觸發

實際上的情況有很多, 該捨棄 SEO 用 CSR 去 render 頁面, 讓使用者總是可以看到最新的資料?
還是捨棄一點效能用 getServerSideProps 讓使用者可以看到最新內容又有益於 SEO? 又或者用 getStaticProps 加上 revalidate time?
如果用這個方法, 那 revalidate time 該設定多久? 縱使設定成 1 秒還需要擔心第 3 點, 如果沒有使用者直接用網址到達該頁, 這頁也永遠不會 re-build,
而且說不定資料也沒更新, 從而浪費 server 的資源

這個時後 on demand ISR 出現了, 現在我們可以利用 Next.js 原先就支援的 [API Routes](https://nextjs.org/docs/api-routes/introduction),
來創建出一隻 API 去觸發 revalidate, Next.js 將這個方法新增到 **res** obj 底下, 目前可以利用 **res.unstable_revalidate** 去觸發想要 revalidate 的頁面

[leerob](https://github.com/leerob) 也建立了一個 [demo](https://on-demand-isr.vercel.app/) 來展示這個強大的功能

在這個 demo 中, leerob 結合了 github webhook 的功能, 一但創建一個 issue 或者是留言, github 會打一個我們自己寫好的 api, 在這個範例中就是事先寫好的 [api route](https://github.com/leerob/on-demand-isr/blob/main/pages/api/webhook.js)

而這個 api 的內容正是去調用 **res.unstable_revalidate** 去更新首頁

```js
export default async function handleWebhook(req, res) {
  // verify the webhook signature request against the
  // unmodified, unparsed body
  const body = await getRawBody(req);
  if (!body) {
    res.status(400).send('Bad request (no body)');
    return;
  }

  const jsonBody = JSON.parse(body);

  // compute our signature from the raw body
  const secret = process.env.GITHUB_WEBHOOK_SECRET;
  const signature = req.headers['x-hub-signature-256'];
  const computedSignature =
    'sha256=' + createHmac('sha256', secret).update(body).digest('hex');

  if (computedSignature === signature) {
    console.log(
      'event',
      req.headers['x-github-event'],
      'action',
      jsonBody.action,
      'issue',
      jsonBody.issue?.title,
      jsonBody.issue?.number
    );

    const issueNumber = jsonBody.issue?.number;

    // issue opened or edited
    // comment created or edited
    console.log('[Next.js] Revalidating /');
    await res.unstable_revalidate('/');
    if (issueNumber) {
      console.log(`[Next.js] Revalidating /${issueNumber}`);
      await res.unstable_revalidate(`/${issueNumber}`);
    }

    return res.status(200).send('Success!');
  } else {
    return res.status(403).send('Forbidden');
  }
}
```

相信也不難理解, 非常直觀, 驗證成功後就去執行 **await res.unstable_revalidate('/');**, 也就是去更新首頁, 如此一來下次進來就會是更新過後的頁面.

這樣開發者就可以自己決定什麼時候該去 revalidate page, 也可以配合一些 CMS 在文章新增或更新後去觸發, 增加了許多可能性

又或者也可以自己寫一個 customize server 去定期觸發 revalidate, 避免以前設定 revalidate time 時, 只有第一次 landing 到頁面才會觸發的窘境

當初我自己特別關注這功能的原因是, 目前工作中的專案 deploy 流程會是由 SRE team 負責, 專案中的環境變數會是由 k8s 啟動 server 時暴露出來

這個時候就出現了一個問題, 如果某個頁面採用 getStaticProps strategy, 我們在 build time 的時候是**無法知道由 SRE 控管的環境變數**

這件事情造成我們只能讓每個頁面都使用 getServerSideProps (因為每次 request 都會讓 server 產生 html, 這個時候是拿得到環境變數的)

這就對我們的專案造成效能上的影響, 但 on demand ISR 出現後, 我就可以想一個 workflow 像是在第一次 build 完啟動 server 後, 再去 revalidate page 一次,
這個時候 build 出來的頁面就會有正確的環境變數！, 這當然還牽涉到一些狀況處理, 像是如果該頁面還沒 build 完時, user 該導到哪裡之類的,
我們會在這個功能 stable 後去進行 implement

總而言之 on demand ISR 的出現, 讓開發者可以更彈性的去決定何時 revalidate page, 之後就期待 stable 的那一天XD

## Reference

- [Ｎext.js 12.1](https://nextjs.org/blog/next-12-1#on-demand-incremental-static-regeneration-beta)


On Demand ISR 終於 beta 了！！


正如敘述所提到, react 在 re-render 的過程中如何決定哪些元件可以重複利用,
哪些又是需要移除新增? key 在 react 中扮演什麼角色, 有什麼使用情境?
整理一下之前看到的文章和自己的想法寫下這篇筆記

要了解這個問題我們要先知道 react 是怎麼產生 element 的

## React Element

```js
// <div className="paul" />
{
  type: 'div',
  props: { className: 'paul' }
}
```

如上面所示, 我們會用 **JSX** 來撰寫 html 元件, 實際上 react 會幫我們轉譯成 javascript 的 obj, 再透過 DOM 的 API 像是 **appendChild** 去產生 html 元件

```js
let node = document.createElement('div');
node.className = 'paul';
domContainer.appendChild(node);
```

接下來如果 re-render 的話 react 要怎麼知道什麼地方不一樣, 什麼地方可以重用, 哪些地方需要 unmount,
從而去更新 dom node, 這個動作叫做 Reconciliation

## Reconciliation

假設今天 className 從 **paul** -> **wang**, 最簡單的方法就是把原本的元件移除, 然後新增一個新的元件

```js
let domContainer = document.getElementById('container');
domContainer.innerHTML = '';
let domNode = document.createElement('div');
domNode.className = 'wang';
domContainer.appendChild(domNode);
```

但這樣一看就知道很沒效率, 明明是同個類型的元件 (div), 卻把它清掉再去新增一個, 怎麼想都怪怪的

而且清掉的話這個元件上的一些狀態也會遺失, 像是反白, focus, 或者 scroll 的狀態

所以最好的方式應該是直接更新既有的元件

```js
paulDivNode.className = 'red';
```

但這個時候就會有一個問題, react 要怎麼知道這個元件是可以重複利用的？如果可以, 那麼就直接更新他,
如果不行, 就清掉再新增一個

結論是 react 會根據兩次 render 中**元件的出現順序**和**元件類型**去做決定

```js
// let domNode = document.createElement('div');
// domNode.className = 'paul';
// domContainer.appendChild(domNode);
ReactDOM.render(
  <div className="paul" />,
  document.getElementById('container')
);

// 第二次 render className paul -> wang
// 類型一樣且位置一樣嗎? 都是 div 所以可以重用
// domNode.className = wang';
ReactDOM.render(
  <div className="wang" />,
  document.getElementById('container')
);

// 第三次 render, 原本的位置變成 p, div !== p 所以不能重用
// domContainer.removeChild(domNode);
// domNode = document.createElement('p');
// domNode.textContent = 'Paul Wang';
// domContainer.appendChild(domNode);
ReactDOM.render(
  <p>Paul Wang</p>,
  document.getElementById('container')
);

// 第四次把 p 的內容改掉 (p -> p)
// domNode.textContent = 'Hey!!';
ReactDOM.render(
  <p>Hey!!</p>,
  document.getElementById('container')
);
```

有條件的時候也是這樣運作的, 我們可能會根據 state 要不要 render 元件

```js
ReactDOM.render(
  <p>hello</p>,
  document.getElementById('container')
);

ReactDOM.render(
  <h1>hihihi</h1> // 第二次 render 中才出現
  <p>hello</p>,
  document.getElementById('container')
);
```

這樣 p 的位置不一樣是不是只能移除再新增? 不是的, 上面的例子可以看成這樣

```js
function Component({ flag }) {
  let content = null;
  if (flag) {
    content = <h1>hihihi</h1>;
  }
  return (
    <>
      {content}
      <p>hello</p>
    </>
  );
}
```

```js
ReactDOM.render(
  null,
  <p>hello</p>,
  document.getElementById('container')
);

ReactDOM.render(
  <h1>hihihi</h1>
  <p>hello</p>,
  document.getElementById('container')
);
```

p 的位置一樣, 所以可以重複利用原本的元件


## Array

再來講 array, 上面講了 react 是根據元件類型和位置去判斷是否可以重複利用原本的 instance

但當如果是 render array 時情況就有點不同了, 因為列表的順序可能會有改動

```js
function List({ list }) {
  return (
    <div>
      {list.map(item => (
        <p>
          name: {item.name}
          <br />
          <input />
        </p>
      ))}
    </div>
  )
}
```

在這個情況下如果列表裡面的順序移動了, react 會發現元件的類型都一樣 (p & input), 也不知道我們有移動 array 的順序,
所以會把每組元件做更新

仔細想一想, 我只是移動位置, 其實還是原本的元件啊, 根本不必去做更新, 應該是用原本的元件換個位置而已

所以這時候 **key** 就出現了, key 是用來告訴 react 説, 在每次 render 之間, 縱使你的位置在 parent element 內不同
他在概念上還是一樣的

```js
function List({ list }) {
  return (
    <div>
      {list.map(item => (
        <p key={item.id}>
          name: {item.name}
          <br />
          <input />
        </p>
      ))}
    </div>
  )
}
```

這樣一來在每次 render 中, react 會比較 div 標籤內的 p 和 key attribute,
假設有一樣的 key 的話 react 會直接重複用原本的 instance

要特別注意的是 react 只會比較 parent 底下(div)的 key, 如果有兩個 key 相同, 但是被包在不同 parent 的話是不會有影響的

也就是說如果 key 不一樣的時候, 縱使元件的位置和類別一樣, react 還是會 unmount 它重新 create 一個新的元件
, 我們可以利用這個機制做一些方便的事情

像是假設你現在需要根據 props 來決定要 render 不同圖片, 並且要有淡入的效果

```js
const imgObj = {
  a: 'source1',
  b: 'source2',
}

// 假設 flag 會是 a || b
function Component({ flag }) {
  return <Image src={imgObj[flag]} />
}
```

你的 css 可能會這樣寫

```js
animation-name: FadeIn;
animation-duration: 0.8s;
animation-timing-function: ease-in-out;
animation-fill-mode: forwards;
```

但是這樣你會發現只有第一次 render 時才有淡入效果, flag 改變時 react 知道 **Image** 可以重複利用,
所以只更新了 src 這個 attribute

除了改成直接 render 兩個圖片, 根據 flag 去改變該圖片的 opacity, 其實也可以用 key 讓 react 強迫他更新

```js
function Component({ flag }) {
  return <Image key={flag} src={imgObj[flag]} />
}
```

以上就是這次的筆記, 基本上是參考 Dan 的文章, 在這邊做個紀錄

## Reference

- [React as a UI Runtime](https://overreacted.io/react-as-a-ui-runtime/)


Blog

瀏覽器的 composition event

談談 Apollo Cache

Stacking Context 和 z-index

On Demand ISR 終於 beta 了！！

React 如何決定元件是 update 還是 unmount & mount ?