
在處理一些 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/)


What's News?

瀏覽器的 composition event

談談 Apollo Cache

Stacking Context 和 z-index