
如果還沒看過 Part1 的話可以從[這裡](/blog/getinitialprops-and-getserversideprops-part1)連結過去～

## getServerSideProps

上次簡單介紹了 getInitialProps (GIP) 和 getServerSideProps (GSSP) 的差異, 這篇來講講為什麼我覺得 getServerSideProps 不太好的原因。

在 Part1 提到 GSSP 只會在 server side 執行, 當前端 routing 到該頁面時, 會是 next.js 送一個 api request 到 server 去拿 GSSP 的結果,
其實這部份就是我覺得 GSSP 不太好的原因。

或許會覺得既然 GSSP 可以跟 GIP 一樣判斷使用者是否是第一次 landing 到該頁從而避免掉不需要的 await, 為什麼我會覺得比較差呢？
其實重點是在**前端 routing 到該頁面時, 會是 next.js 送一個 api request 到 server 去拿 GSSP 的結果**, 也就說如果當你開啟 devtool 觀察 network,
換頁到使用 GSSP 的頁面時你會發現會多一個 request 像下圖。

<ArticleImage src="https://i.imgur.com/tYW4GUI.png" alt="GSSP request" />

其實這就是問題所在, 也就是說每次換頁前都必須等待該 api response 回來後才會進行換頁, 圖中顯示該 request 花費了 **166ms**,
所以這段時間內使用者其實會感覺頁面卡住了, 更不用說當使用者網路狀況或其他原因導致這段時間更長的時後, 而且這也導致 server 的負擔加重！

而 GIP 在前端換頁時是會在 client side 執行的, 所以並不需要與 server 溝通而是由 js 處理。有興趣的人可以試試看換頁到 GIP 和換頁到 GSSP 體感上的差別,
我自己認為差異能夠明顯的感覺出來，雖說 GSSP 不會被打包進前端的 code 從而讓 bundle size 變小, 但是我個人覺得這樣失去了更多QQ

不過在後續 next.js 的更新中除了 getStaticProps(GSP), 也提出了新的 feature **Incremental Static Regeneration (ISR)**, 可以感覺得出來 next.js team 想要主打 Static Site Generation(SSG),
所以順便簡單介紹下 GSP 以及 ISR 和未來發展 (?)

## getStaticProps

詳細的介紹當然是去看[官方文件](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation),
簡單來說, 當頁面是 GSP 的時候, 會在 build time 時產好 HTML 以及 JSON 檔(執行 GSP 的結果), 當使用者 request 進來時就是會拿這些事先產生好的檔案。

好處當然就是使用者拿到的 html 已經事先產好了, 而且可以藉由 CDN 將檔案 cache 起來, 速度上會比 GSP 快上許多, 而且還能夠 [prefetch](https://nextjs.org/docs/api-reference/next/link) 後續可能需要的 JSON 檔案,
但缺點也顯而易見, 由於在 build time 時就產好這些檔案, 所以如果該頁面需要顯示的資料需要即時更新, 內容改動後下次 request 就要看到變化的話就不適合這條路線。

而要更新內容時必須重新 build 好再次上版, 可以想像得出來這樣的做法蠻不切實際的, 只更新了一個頁面卻要整個網站重 build 和上版越想越不對勁, 所以出現了 **Incremental Static Regeneration (ISR)**。

## Incremental Static Regeneration

為了解決 SSG 內容需要改動時整個網站重 build 這個缺點, next.js team 提供了 ISR 來解決這個問題, 先來看看官方的範例。

```
function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  )
}

// This function gets called at build time on server-side.
// It may be called again, on a serverless function, if
// revalidation is enabled and a new request comes in
export async function getStaticProps() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
    // Next.js will attempt to re-generate the page:
    // - When a request comes in
    // - At most once every 10 seconds
    revalidate: 10, // In seconds
  }
}
```

可以發現 getStaticProps 除了回傳 component 需要的 props 之外, 還多了 revalidate 這個 key,
這個 key 是拿來做什麼的呢？ 從程式碼上的註解應該也看得出來, 有點像是 response header 裡 cache-control max-age,
當使用者進來該頁面時, 如果該頁面產生好的時間沒超過 10 秒鐘, 該使用者就會看到當初 build time 時產生好的頁面。

一但超過 10 秒後, 下次使用者進來這個頁面時仍然會是看到當初 build time 時產生好的頁面, 但 next.js 會在背景重 build 這頁面,
當這個頁面重新 build 完後, 下次使用者進來就會看到新的頁面！

這真的是一個非常棒的 feature, 但還是有些缺點

1. 目前只能設定 revalidate time 來進行 re-build
2. 沒辦法知道何時 re-build 完成 (雖然 [getStaitcPaths 有 fallback 的 option](https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation))
3. 只有使用者第一次直接到該頁面才會觸發 revalidate, next/link next/router routing 過去的不會觸發

關於這些缺點其實社群也有[討論](https://github.com/vercel/next.js/discussions/11552#discussioncomment-2655)到, 主要是沒辦法主動觸發 re-build 只能設定 revalidate time 這點,
不過值得高興的是, next.js team 也打算提供 on-demand 的方式去觸發 re-build, 這樣讓未來多了許多可能性, 像是可能在後台更新文章內容後主動去觸發 re-build, 這樣就更有可能讓使用者看到最新的資料！

最後, 不管要用哪種策略去進行開發, 還是要根據公司產品走向, 行銷團隊的溝通來決定出一個最好的方式, 不過我還是覺得 getInitialProps 很可惜, 雖然 next.js 有提到並不打算 depreciated,
但是 tutorial 內都拔掉了很難想像未來還會有 getInitialProps XD

## Reference

- [Next.js official doc](https://nextjs.org/docs/getting-started)
- [RFC: Incremental Static Regeneration](https://github.com/vercel/next.js/discussions/11552)


淺談 getInitialProps, getServerSideProps Part2


應該有蠻多人不知道, 其實 Next.js 最一開始是沒有 [getServerSideProps](https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering) 的,
對剛熟悉 Next.js 的人來說, 應該只會在 [Custom Document](https://nextjs.org/docs/advanced-features/custom-document)
以及 [Custom App](https://nextjs.org/docs/advanced-features/custom-app) 裡看過 getInitialProps, 官方的 tutorial 並不會提到
, 除非特意去[搜尋](https://nextjs.org/docs/api-reference/data-fetching/getInitialProps)才會發現在 9.3 版本以前, 主要的 data fetching method 就是 getInitialProps, 這讓人覺得 getInitialProps 將在不久後 depreciated,
目前看起來也是這樣沒錯XD

最近在工作上因為某些套件有 bug, 所以必須升級, 但這些套件的最新版本有些已經不再支援 getInitialProps 了, 像是跟多國語系相關的 [next-i18next](https://github.com/isaachinman/next-i18next),
所以我必須做出抉擇, 要馬就是用相對舊的版本, 要馬就是把專案內的 getInitialProps 全部重構成 getServerSideProps 和 [getStaticProps](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation)。

因為有一段時間可以好好的將專案重構, 所以最後選擇了將所有 getInitialProps 改掉的大工程(所以才有這篇XD)。在一番努力下成功地完成了, 但在這過程中讓我覺得 Next.js 採用 getServerSideProps 是個不太好的決定,
所以想寫下這篇文章記錄一下我的感想, 不過這是我個人主觀的意見就是了。

這篇是 Part1, 會有幾個 part 我不知道(蛤?), 在這個 part 我想先簡單整理介紹下 getInitialProps 和 getServerSideProps,
之後才會提到為什麼我覺得 getServerSideProps 不太好, 如果是完全沒接觸過 Next.js 的人可以先跳過這系列了, 你應該先去看看官方的 tutorial XD

## getInitialProps

先附上官方[範例](https://nextjs.org/docs/api-reference/data-fetching/getInitialProps)程式碼

```
function Page({ stars }) {
  return <div>Next stars: {stars}</div>
}

Page.getInitialProps = async (ctx) => {
  const res = await fetch('https://api.github.com/repos/vercel/next.js')
  const json = await res.json()
  return { stars: json.stargazers_count }
}

export default Page
```

有用過的人應該不陌生, 為了 SEO 我們會想要讓使用者第一次拿到的 html 有資料, 而不是像 SPA 一樣拿到一個幾乎空白的 html。

所以可以利用這個方式讓使用者拿到有資料的 html, getInitialProps 所回傳的物件將會變成 Page Component 的 props,
在這裡就是 **stars**, 頁面在 render 前會先執行這個 function 來拿所需要的資料 render 到頁面上。

**也就是說頁面必須要等 API 完成才會進行頁面 render**, 想當然的這對使用者是一個非常差的體驗, 但是想要產生動態的 html, 勢必就要等待 API 完成,
所以最後做了一個取捨, 我們只需要在使用者第一次 landing 網頁時才需要等待 API 完成, 而在使用者換頁的時候我們不必等待 API response, 因為沒有意義！
這也是為什麼 Next.js 出現的原因, SPA + SSR 的解決方案。

那麼 getInitialProps 怎麼達成這件事呢？getInitialProps 可以在 client、server side 執行, 在使用者第一次 landing 該頁面會是在 server side 執行,
如果是換頁到該頁面時就會是在 client side 執行, 可以用 **ctx.req (http request obj)** 這個物件來判斷是否為 server side, 所以上面那段程式碼可以改成這樣

```
function Page({ stars }) {
  // if stars not exist (null) do something...
  return <div>Next stars: {stars}</div>
}

Page.getInitialProps = async (ctx) => {
  let stars = null;

  if (ctx.req) {
    const res = await fetch('https://api.github.com/repos/vercel/next.js')
    const json = await res.json()
    stars = json.stargazers_count;
  }

  return { stars }
}

export default Page
```

只要 **ctx.req** 存在就是在 server side 執行, 也就是使用者第一次 landing 到該頁面,
我們只有在這種情況下才需要等待 API response 讓使用者拿到有資料的 html。

如果使用者是換頁進到該頁面, 則我們必須自己在 component 內寫取得資料, loading 狀態的邏輯從而達到 SSR + SPA 的效果。

最後整理一下幾個小重點, 詳細的就請到[官方文件](https://nextjs.org/docs/api-reference/data-fetching/getInitialProps)去看囉～

- 會在 client side 執行, 所以會被打包進前端的 bundle。
- 可以利用 **ctx.req** 判斷是否為 server side。
- 不能隨意使用只有 client 或 server 的東西, 要做好判斷像是 window 物件。
- 利用 await 讓畫面 render 前就有資料。

## getServerSideProps

ok, 再來簡單講一下 getServerSideProps, 一樣也看一下官方的[範例](https://nextjs.org/docs/basic-features/data-fetching#simple-example-1)

```
function Page({ data }) {
  // Render data...
}

// This gets called on every request
export async function getServerSideProps(ctx) {
  // Fetch data from external API
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // Pass data to the page via props
  return { props: { data } }
}

export default Page
```

其實大同小異, 目的也是為了讓頁面 render 前將資料拿好再產生 html 來改善 SEO,
但是不同的是, **getServerSideProps 只會在 server side 執行**, 什麼意思呢？

**ctx.req** 這個物件不管是在第一次 landing, 或者換頁都會存在, 前端換頁時 next.js 會幫我們打一隻 api 到 server 執行 getServerSideProps 去拿結果。

到這裡可能就有人會想到, 咦！既然 **ctx.req** 永遠都會存在, 那我們怎麼判斷使用者是換頁還是第一次 landing 呢？

目前其實可以從 **ctx.req.url** 來判斷, 如果是前端換頁的話 **ctx.req.url** 的開頭會是 **/_next**, 所以可以這樣寫

```
export async function getServerSideProps(ctx) {
  const isClientSideNavigate = ctx.req.url.startsWith('/_next');
  let data = null;

  if (!isClientSideNavigate) {
    const res = await fetch(`https://.../data`)
    data = await res.json()
  }

  return { props: { data } }
}
```

實際在使用的時候可以想想怎麼寫比較乾淨, 避免去重複寫一樣的邏輯, 不過這不是這篇的重點就不贅述了。

一樣稍微整理幾個重點, 但詳細的還是請去看官方文件

- **ctx.req** 永遠存在
- 只會在 server side 執行
- 如果是 client side navigate, next.js 會送 api 到 server 執行 getServerSideProps
- code 不會被打包進前端的 bundle
- 要注意不能隨意使用只有 client 的東西
- 利用 await 讓畫面 render 前就有資料

差不多就是這樣, [Part2](/blog/getinitialprops-and-getserversideprops-part2) 再提為什麼我會覺得 getServerSideProps 不太好的原因

## Reference

- [Next.js official doc](https://nextjs.org/docs/getting-started)
- [Defer getServerSideProps on client-side navigation](https://github.com/vercel/next.js/issues/13910)


淺談 getInitialProps, getServerSideProps Part1


隨著現在越來越注重使用者體驗, 網頁的優化越來越重要, 其中一個切入點就是資源的加載。

在 HTML 中 **link** 標籤的 **rel** 屬性能夠幫助我們提示瀏覽器提前下載資源來達到優化的效果,
接下來就來看看這三種的差別。

## Preload

**preload** 會告訴瀏覽器說該資源對於使用者是必要的, 請優先下載該資源。

```js
<link rel="preload" href="B.png" as="image" />
```

如果頁面上有個圖片動畫效果原本是 **A.png** hover 的話會替換成 **B.png**, 這時上面這行就會很有效果, 讓使用者的動畫體驗更佳。

另外也可以使用 **media** 屬性, 在特定情況下才進行 preload。

```js
<link rel="preload" href="B.png" as="image" media="(max-width: 600px)" />
```

[as](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attributes) 屬性對於 **preload** 和 **prefetch** 是必要的屬性, 用來指定資源類別, request matching 和 request prioritization。

雖然瀏覽器會先掃一遍 html 提早發現資源進行下載, 但有字體資源會隱藏在 **.css** 中, 這個時候 preload 就會非常有幫助

<ArticleImage src="https://i.imgur.com/XoiiZlY.png" alt="google font css" remark="google font css" />

在現今網頁以 SPA 為主流的時代, JS bundle size 較大造成使用者第一次造訪網頁時有可能會有一陣子看到空白, 等到載入完成後才能跟使用者互動，
縱使使用 SSR + CSR 的方式來解決, 我們也應該要盡快優先下載互動所需的 **.js** 檔案。

<ArticleImage src="https://i.imgur.com/tI296oQ.png" alt="preload script" remark="preload script" />

## Prefetch

prefetch 是告訴瀏覽器說我**可能**之後會用到該資源, 在空閒時可以先幫我下載, 所以優先程度會比較低

常見的案例是**分頁**, 當使用者到 A 頁面時, 可能下一步會到 B 頁面, 這個時候就可以先 prefetch B 頁面所需的檔案, 這樣使用者到 B 頁面時就可以很快速地看到畫面！

Next.js 就有自動支援這個[功能](https://nextjs.org/docs/api-reference/next/link), 只要連結出現在 viewport 且有用 **NextLink** 包住和該頁面是 **Static Generation** 的話, 就會自動 prefetch！

<ArticleImage src="https://i.imgur.com/vGoEb5w.png" alt="prefetch script" remark="prefetch script" />

## Preconnect

preconnect 告訴瀏覽器這個網頁在之後會需要對某個 domain 進行連線, 請先幫我建立好連線.

這篇[文章](https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/)對於 preconnect 的解釋非常清楚, 我在這邊整理一下重點.

當我們想要使用 google font 的字體時, 通常都會到[這裡](https://fonts.google.com/)找我們要的字體, 選好後會出現以下畫面

<ArticleImage src="https://i.imgur.com/EYuDuyn.png" alt="google font" />

會發現除了下載 css 之外還對 **https://fonts.gstatic.com** 進行了 preconnect

查看下載回來的 css 後會發現裡面的字體會是由這個 domain 來 host

<ArticleImage src="https://i.imgur.com/XoiiZlY.png" alt="google font css" />

那麼先進行 preconnect 會有什麼好處呢? 在瀏覽器傳輸資料前會有幾個步驟需要做

1. 向 DNS 請求解析域名
2. TCP握手
3. 如果是 https, 則還需要 SSL Negotiation
4. 完成, 等待資料拿到第一個 byte

以上每個步驟都會花費一個 [RTT](https://www.cloudflare.com/zh-tw/learning/cdn/glossary/round-trip-time-rtt/),
再延遲很高的情況下會拖慢取得資源的速度

<ArticleImage src="https://www.igvita.com/posts/15/xfont-preconnect.png.pagespeed.ic.ALPEs7sMxi.webp" alt="preconnect request" remark="source: https://www.igvita.com" />

上面那張圖下半部使用了 **preconnect**, 而上半部沒有

首先來看上半部

1. 和 **font.googleapis.com** 建立連線
2. 下載 css
3. 發現步驟2下載回來的 css 裡有包含字體檔案, 於是和 **fonts.gstatic.com** 建立連線
4. 下載字體

而下半部會是

1. 和 **font.googleapis.com**、**fonts.gstatic.com** 建立連線
2. 下載 css
3. 發現步驟2下載回來的 css 裡有包含字體檔案, => 下載字體

由此可以看出我們省下了和 **fonts.gstatic.com** 建立連線的時間！真是可喜可賀

## Reference

- [深入淺出 Preload, Prefetch 和 Preconnect](https://shubo.io/preload-prefetch-preconnect/)
- [Eliminating Roundtrips with Preconnect](https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/)


一起來看 Preload、Prefetch、Preconnect


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


Archives