Render-less container for generating UID for a11y, consistent react key, and any other good reason 🦄
To generate a stable UID/Key for a given
item, consistently between client and server, in 900 bytes.
Example - https://codesandbox.io/s/kkmwr6vv47
React UID provides 3 different APIs - vanilla js API -
uid(item) -> key- React Component, via renderProp based API -
{ id => <>- React Hooks -
useUID
uid(item, [index])- generates UID for an object(array, function and so on), result could be used as React
key.
itemshould be an object, but could be anything. In case it is not an "object", and might have non-unique value - you have to specify second argument -
index```js import {uid} from 'react-uid';
// objects const data = [{a:1}, {b:2}]; data.map( item =>
// unique strings const data = ["a", "b"]; data.map( item =>
// strings const data = ["a", "a"]; data.map( (item, index) =>
JS API might be NOT (multi-tenant)SSR friendly,
UID- renderless container for generation Ids
UIDConsumer- renderless container for generation Ids ```js import {UID} from 'react-uid';
{id => ( )}
// you can apply some "naming conventions" to the keys
unique-${id}}> {id => ( )}
// UID also provide
uidas a second argument {(_, uid) => ( data.map( item =>
// in the case
itemis not an object, but number or string - provide and index {(_, uid) => ( data.map( (item, index) =>
The difference betweenuid
andUID
versions are in "nesting" - anyUID
used inside anotherUID
would contain "parent prefix" in the result, scopinguid` to the local tree branch.
UID might be NOT SSR friendly,
useUID()will generate a "stable" UID
useUIDSeed()will generate a seed generator, you can use for multiple fields ```js import { useUID, useUIDSeed } from 'react-uid';
const Form = () => {
const uid = useUID();
return (
<>
</>
)
}
const Form = () => {
const seed = useUIDSeed();
return (
<>
{data.map(item =>
UIDReset,
UIDConsumer,
UIDFork- SSR friendly UID. Could maintain consistency across renders. They are much more complex than
UID, and provide functionality you might not need.
The key difference - they are not using global "singlentone" to track used IDs, but read it from Context API, thus works without side effects.
Next example will generate the same code, regardless how many time you will render it ```js import {UIDReset, UIDConsumer} from 'react-uid';
{(id,uid) => ( data.map( item =>
UID is not 100% SSR friendly - use UIDConsumer.
Codesplitting may affect the order or existence of the components, so alter the
componentDidMountorder, and change the generated ID as result.
In case of SPA, this is not something you should be bothered about, but for SSR this could be fatal.
Next example will generate consistent keys regardless of component mount order. Each call to
UIDForkcreates a new branch of UIDs untangled from siblings. ```js import {UIDReset, UIDFork, UIDConsumer} from 'react-uid';
{ uid => {uid} is unique }
{ uid => {uid} is unique }
```
The hooks API only needs the
wrapper."Basic API" is not using Context API to keep realization simple, and React tree more flat.
Written in TypeScript
MIT