在 Vue3.5 這個版本中，新增了 useId 這一個 API，它的功能是用來生成一個 唯一的ID，為什么說它生成的 ID 是唯一的呢？我們可以來看看 useID 的源碼，你就知道了。

其實原理很簡單，就是調(diào)用 getCurrentInstance 這個，這個 API 會返回當前 Vue 實例的信息對象，而這個信息對象身上有一個 ids 的數(shù)組，而 useId 就是根據(jù)這個數(shù)組去生成唯一 ID 的。

圖片

• appContext.config.idPrefix： 這是可全局配置的 ID 前綴，如果你不配置，那就默認是 v。
• ids[0] + ids[1]++： 由唯一的 ids[0] 和遞增的 ids[1] 來實現(xiàn)同實例內(nèi)與不同實例時間的唯一性。

想要設(shè)置 appContext.config.idPrefix 可以在 main.ts 中去設(shè)置。

圖片

接下來講一下 useId 都有哪些比較實用且常用的場景吧！

表單對應(yīng)標識

表單中，我們會使用 label 來做表單項的展示文本，我們想要點擊這個展示文本，能自動聚焦到表單項上，那么我們可以同時給 label、表單項標簽 設(shè)置上一個一樣的 ID。

圖片

圖片

v-for 唯一 key

大家都知道，在 Vue 中使用 v-for 去循環(huán)遍歷一個列表的時候，需要給每一個遍歷項加上一個唯一 key ，確保 DOM 更新的時候能得到一定的性能提升，我們可以使用 useID 來生成一個唯一 key。

圖片

圖片

服務(wù)端渲染保持唯一性

使用 服務(wù)端渲染（SSR） 的應(yīng)用里，頁面的 HTML 是由服務(wù)器生成的，隨后被傳送到客戶端的瀏覽器。當瀏覽器接收到這些 HTML 內(nèi)容后，會將其轉(zhuǎn)變?yōu)橐粋€可交互的頁面。然而，倘若服務(wù)器端與客戶端生成的 HTML 中具有相同的 ID，在客戶端進行 激活（hydrate） 操作時，就有可能出現(xiàn)問題。因為客戶端可能會試圖對一個已經(jīng)被服務(wù)器端渲染好的 DOM元 素進行操作，這樣就會引發(fā)潛在的沖突或者錯誤。

可以通過一個小例子來說明這個問題。

服務(wù)端代碼

圖片

客戶端代碼

圖片

在這個案例中，無論是服務(wù)端還是客戶端，我們都使用了 createSSRApp(App) 來創(chuàng)建應(yīng)用實例。如果我們在 App.vue 中使用了 useId 來生成 ID，那么這些 ID 將在服務(wù)端渲染時生成一次，并在客戶端激活時再次使用相同的 ID。

App.vue

圖片

在 App.vue 組件里，我們借助 useId為 <input> 元素創(chuàng)建了一個獨一無二的 ID。此 ID 在服務(wù)端渲染階段生成，并被納入發(fā)送至客戶端的HTML之中。當客戶端接收到該HTML并展開激活流程時，鑒于useId所生成的ID在服務(wù)端和客戶端保持一致，客戶端便能準確地把 <label> 元素與 <input> 元素相關(guān)聯(lián)，從而避免出現(xiàn) ID 沖突的情況。

倘若不使用 useId，而是采用 Math.random() 或者 Date.now() 來生成 ID，那么服務(wù)端和客戶端有可能生成不一樣的ID。這就會致使客戶端在激活時無法正確地將 <label> 與 <input> 關(guān)聯(lián)起來，因為二者的 ID 存在差異。這種情況或許會致使表單元素出現(xiàn)行為異常，比如點擊 <label> 時，<input> 卻不能獲取焦點。

組件庫中 ID 的生成

在運用 Element Plus 等組件庫開展 SSR 開發(fā)的過程中，為防止出現(xiàn) hydration 錯誤，務(wù)必要保證服務(wù)器端和客戶端所生成的 ID 是一致的。向 Vue 中注入 ID_injection_key 這一操作，能夠確保 Element Plus 所生成的 ID 在 SSR 里具備唯一性。

圖片