大家好，我卡頌。

要說React有什么其他框架沒有的、獨(dú)一無二的特性，那一定是「并發(fā)更新」。圍繞并發(fā)更新，存在兩個(gè)很有意思的現(xiàn)象：

• 很多開發(fā)者聽說過他
• 很少開發(fā)者直接使用過他

這兩個(gè)現(xiàn)象看似矛盾，其實(shí)很好解釋 —— React18之后的新特性，主要是面向上層框架的（主要是Next.js）。

換句話說，這些新特性（比如并發(fā)更新）主要是供框架集成，而不是開發(fā)者直接使用。

比如，并發(fā)更新的兩個(gè)核心API —— useTransition和useDeferredValue，都是針對(duì)「視圖切換」的場(chǎng)景。

而在前端交互中，最主要的「視圖切換」場(chǎng)景就是「路由切換」，所以包含路由功能的前端框架就會(huì)集成這兩個(gè)API。

而現(xiàn)在，一個(gè)試驗(yàn)性瀏覽器API —— View Transitions API將原生實(shí)現(xiàn)「視圖切換」功能。

他到底有什么用？如果其他框架使用它，是不是能獲得React同樣的并發(fā)更新能力？

什么是視圖切換？

不管是View Transitions API，還是React的useTransition，都是為了提高「視圖切換」場(chǎng)景下的用戶體驗(yàn)。

什么是「視圖切換」？以view-transitions Demo[1]舉例。這是個(gè)簡單的相冊(cè)Demo，點(diǎn)擊左邊圖片縮略圖，右邊會(huì)顯示大圖：

整個(gè)過程簡單來說包括3個(gè)步驟：

• 點(diǎn)擊縮略圖。
• 請(qǐng)求大圖數(shù)據(jù)。
• 大圖請(qǐng)求成功后，顯示大圖。

從步驟1到3的過程就是個(gè)典型的「視圖切換」。整個(gè)過程有很多可以優(yōu)化體驗(yàn)的地方，比如：

• 從舊圖到新圖的漸變過渡效果。
• 點(diǎn)擊縮略圖發(fā)起圖片請(qǐng)求后，大圖區(qū)域可以先顯示舊圖（而不是立刻顯示loading效果），待新圖請(qǐng)求成功后再過渡到新圖。

這里解釋下第二點(diǎn)，對(duì)于切換類的交互，相比于「當(dāng)視圖切換時(shí)立刻顯示loading效果，待新視圖加載完成后過渡到新視圖」，「當(dāng)視圖切換時(shí)先顯示舊視圖，待新視圖加載完成后過渡到視圖」在延遲不高的情況下體驗(yàn)會(huì)更好。

除了上述這些「體驗(yàn)優(yōu)化的點(diǎn)」，視圖切換的實(shí)現(xiàn)還有很多細(xì)節(jié)需要考慮，比如：

• 如何處理新舊視圖切換時(shí)的過渡效果？
• 如何處理新視圖加載時(shí)的loading效果？
• 當(dāng)正在請(qǐng)求新視圖數(shù)據(jù)時(shí)（此時(shí)視圖處在舊視圖中），用戶又對(duì)舊視圖產(chǎn)生交互怎么辦？
• 視圖切換時(shí)如何處理頁面滾動(dòng)位置、光標(biāo)聚焦（focus）位置？
• 對(duì)于使用屏幕閱讀器的盲人，視圖切換時(shí)閱讀器會(huì)朗讀什么？

除此之外，不同場(chǎng)景下的「視圖切換」實(shí)現(xiàn)細(xì)節(jié)也不同。比如，如何在切換頁面時(shí)優(yōu)化視圖切換效果？

在SPA（單頁應(yīng)用）出現(xiàn)之前，網(wǎng)站通常是由多個(gè)頁面組成。比如下面網(wǎng)站的每個(gè)Tab欄，對(duì)應(yīng)一個(gè)獨(dú)立網(wǎng)頁，其中：

• bramus Tab對(duì)應(yīng) https://http203-playlist.netlify.app/with-bramus/
• cassie Tab對(duì)應(yīng)https://http203-playlist.netlify.app/with-cassie/

在Tab之間切換，瀏覽器會(huì)：

• 卸載之前的頁面
• 請(qǐng)求新頁面數(shù)據(jù)
• 加載新頁面

從「頁面卸載」到「頁面加載」之間的白屏間隙會(huì)造成屏幕閃爍。

要優(yōu)化這種場(chǎng)景下優(yōu)化視圖切換效果，當(dāng)前唯一做法是利用history API接管路由操作，將網(wǎng)頁變成一個(gè)SPA。

既然「視圖切換」是如此常見的需求，且有這么多需要考慮的因素，那瀏覽器為什么不原生實(shí)現(xiàn)呢？

于是，View Transitions API應(yīng)運(yùn)而生。

當(dāng)前View Transitions API不支持跨頁面的視圖切換，但未來會(huì)支持。

View Transitions的使用

View Transitions API[2]的使用很簡單，只需要用document.startViewTransition包裹視圖切換后的回調(diào)函數(shù)即可。

對(duì)于上述相冊(cè)示例，回調(diào)函數(shù)的邏輯是「將img標(biāo)簽src屬性更新為新圖片地址」：

const transition = document.startViewTransition(() => {
  galleryImg.src = /* 新圖片地址 */;
});

剩下所有跟過渡相關(guān)的實(shí)現(xiàn)，都由Transitions API解決。

View Transitions實(shí)現(xiàn)原理

在視圖切換時(shí)，存在2個(gè)概念：

• 切換前的舊視圖
• 切換后的新視圖

當(dāng)使用View Transitions后，會(huì)依次做：

• 對(duì)頁面進(jìn)行截圖，作為舊視圖。
• 執(zhí)行傳遞給document.startViewTransition的回調(diào)。
• DOM更新后，對(duì)更新后的頁面進(jìn)行截圖，作為新視圖。

構(gòu)造一棵代表過渡效果的偽元素樹，掛載在根元素（html元素）下，結(jié)構(gòu)類似如下：

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root)
      └─ ::view-transition-new(root)

其中：

• 舊視圖保存在::view-transition-old(root)中。
• 新視圖保存在::view-transition-new(root)中。

對(duì)于上述相冊(cè)示例，掛載的偽元素樹結(jié)構(gòu)如下：

之所以要掛載一棵偽元素樹，主要是因?yàn)閮蓚€(gè)原因：

• 開發(fā)者可以對(duì)微元素應(yīng)用CSS規(guī)則。

比如，上述兩個(gè)「保存了新/舊視圖的截圖」的偽元素，類似于img標(biāo)簽，開發(fā)者可以對(duì)他們應(yīng)用CSS動(dòng)畫，當(dāng)新/舊視圖切換時(shí)，實(shí)現(xiàn)自定義的過渡效果。

• 方便對(duì)整個(gè)頁面中不同「視圖切換」分組。

比如，在上述相冊(cè)示例中，視圖切換的元素包括兩部分：

• 新/舊視圖之間的切換（下圖紅框部分）
• 新/舊圖片名稱的切換（下圖綠框部分）

相冊(cè)對(duì)應(yīng)的HTML結(jié)構(gòu)如下：

• img標(biāo)簽對(duì)應(yīng)視圖部分（下圖紅框部分）。
• figcaption標(biāo)簽對(duì)應(yīng)圖片名稱部分（下圖綠框部分）。

當(dāng)我們?yōu)閒igcaption元素設(shè)置不同的view-transition-name：

figcaption {
  view-transition-name: figure-caption;
}

會(huì)得到一棵新的偽元素樹，其中「視圖部分」和「圖片名稱部分」偽元素是分離開的：

通過給頁面中不同HTML元素定義不同的view-transition-name屬性，就能獨(dú)立控制這個(gè)元素是視圖切換時(shí)的過渡效果。

與 React 的區(qū)別

瀏覽器原生的View Transitions API與React中的useTransition相比，誰更強(qiáng)大呢？

毫無疑問，前者更強(qiáng)大。

這是因?yàn)椋瑢?duì)于View Transitions API，通過操作偽元素樹，開發(fā)者可以自定義過渡效果（就像對(duì)img元素使用CSS過渡動(dòng)畫一樣簡單）。即使不使用CSS Transition，使用JS Transition也完全沒問題。

document.startViewTransition方法會(huì)返回一個(gè)transition對(duì)象實(shí)例：

const transition = document.startViewTransition(() => {
  galleryImg.src = /* 新圖片地址 */;
});

該實(shí)例包含了一系列視圖切換生命周期對(duì)應(yīng)的promise，比如：

• ViewTransition.ready：偽元素樹構(gòu)造完成，準(zhǔn)備開始過渡時(shí)。
• ViewTransition.finished：過渡效果完成后，此時(shí)新視圖已經(jīng)可以響應(yīng)用戶交互。

而在React中，使用useTransition后，與其說完成的是「視圖切換」，不如說完成的是：

• 首先，完成狀態(tài)的切換。
• React內(nèi)部再將狀態(tài)變化映射到視圖變化。

本質(zhì)來說，操作視圖的是React，而不是開發(fā)者。所以，開發(fā)者很難控制過渡效果。

動(dòng)效庫Framer的作者認(rèn)為，由于開發(fā)者很難控制并發(fā)更新的完整生命周期，所以很難在并發(fā)更新時(shí)表達(dá)animation效果：

簡單來說就是，開發(fā)者很難為并發(fā)更新定制過渡效果（用CSS或JS）。

總結(jié)

可以認(rèn)為，View Transitions API是比useTransition抽象程度更高、開發(fā)者可控性更高的API。useTransition能實(shí)現(xiàn)的，他可以。useTransition不能實(shí)現(xiàn)的，他也可以。

要說缺點(diǎn)，View Transitions API是Web平臺(tái)獨(dú)有的，而useTransition依賴React核心的并發(fā)更新能力，是跨端的。

當(dāng)前，View Transitions API的兼容性并不好：

但是，一旦他變成可以大規(guī)模使用的API，那么其他前端框架只要接入他，就能輕松獲得比React耗費(fèi)大量精力實(shí)現(xiàn)的useTransition（以及底層的并發(fā)更新特性）更強(qiáng)大的視圖切換能力。

參考資料

[1]view-transitions Demo:https://mdn.github.io/dom-examples/view-transitions/#。

[2]View Transitions API:https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API。