React18中useId

时间：2023-03-28 15:12:41 HTML

的语法是constid=useId();简介useId是一个新的hook，用于生成唯一的ID值，主要用于客户端和服务端使用，同时避免dehydrate时数据不匹配的问题。在服务器端，我们将React组件渲染成字符串，这个过程称为脱水。该字符串以html的形式发送给客户端，作为首屏直接显示的内容。到达客户端后，React还需要重新激活组件参与新的渲染更新过程。这个过程称为“水合物”。它主要用于与需要唯一ID的可访问性API集成的组件库。这解决了React17及以下版本中已经存在的问题，但在React18中更为重要，因为新的流式服务器渲染器如何无序地交付HTML。但是不建议作为List中的key使用，list中的唯一key应该使用List中的数据。问题React渲染有客户端渲染（CSR）和服务器端渲染（SSR）。假设有如下代码片段：//App.tsxconstid=Math.random();exportdefaultfunctionApp(){returnHello

}如果应用是CSR（客户端渲染），id稳定，App组件没有问题。但是如果应用是SSR（服务器端渲染），那么App.tsx会分为以下几个步骤：React在服务器端渲染，生成一个随机id（假设为0.1234）。这一步叫做脱水；Hello

作为首屏内容以HTML形式传递给客户端；React在客户端渲染生成一个随机id（假设为0.6789），这一步称为hydrate（注水）。客户端和服务端生成的id不匹配！原解：//globalgeneralcountvariableletglobalIdIndex=0;exportdefaultfunctionApp(){constid=useState(()=>globalIdIndex++);returnHello

}只要React在服务端和客户端的运行过程是一致的，那么两端生成的id就是对应的。然而，随着ReactFizz（React的新服务器端流式渲染器）的到来，渲染顺序不再是必需的。例如，有一个名为SelectiveHydration的功能，它可以根据用户交互改变水合物的顺序。下图左边部分水合时，用户点击右下部分：React此时会优先水合右下部分：因此，使用自增的全局count变量作为id，即不再准确！！那么，有没有迹象表明服务器和客户端都稳定了呢？答案是：组件的层次结构。useId的原理假设应用的组件树如下图所示：无论谁先水化B或C，它们的层级结构都保持不变，因此“层级”本身可以作为一个不变的标识在服务器和客户端。例如，B可以使用2-1作为id，C可以使用2-2作为id：functionB(){//idis"2-1"constid=useId();returnB