Gathering detailed insights and metrics for react-uid
Gathering detailed insights and metrics for react-uid
Gathering detailed insights and metrics for react-uid
Gathering detailed insights and metrics for react-uid
Render-less container for generating UID for a11y, consistent react key, and any other good reason 🦄
npm install react-uid
Typescript
Module System
Min. Node Version
Node Version
NPM Version
98.2
Supply Chain
100
Quality
82
Maintenance
100
Vulnerability
100
License
TypeScript (88.82%)
JavaScript (9.91%)
HTML (0.99%)
Shell (0.28%)
Love this project? Help keep it running — sponsor us today! 🚀
Total Downloads
40,725,837
Last Day
50,276
Last Week
223,384
Last Month
987,379
Last Year
11,223,866
304 Stars
73 Commits
13 Forks
4 Watching
328 Branches
7 Contributors
Minified
Minified + Gzipped
Latest Version
2.4.0
Package Id
react-uid@2.4.0
Unpacked Size
45.74 kB
Size
8.84 kB
File Count
39
NPM Version
10.2.4
Node Version
20.11.0
Publised On
11 Jan 2025
Cumulative downloads
Total Downloads
Last day
-7.5%
50,276
Compared to previous day
Last week
-15.7%
223,384
Compared to previous week
Last month
-13.1%
987,379
Compared to previous month
Last year
11.7%
11,223,866
Compared to previous year
1
2
To generate a stable UID/Key for a given item
, consistently between client and server, in 900 bytes.
⚠️ SSR: Not compatible with Strict or Concurent mode. Consider using native useId
(React 18) hook instead.
If your clientside is using StrictMode it will never match SSR-ed Ids due to double invocation
Example - https://codesandbox.io/s/kkmwr6vv47
React UID provides 3 different APIs
uid(item) -> key
<UID>{ id => <><label htmlFor={id}/><input id={id}/></>}</UID>
useUID
uid(item, [index])
- generates UID for an object(array, function and so on), result could be used as React key
.
item
should 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
1import { uid } from 'react-uid'; 2 3// objects 4const data = [{ a: 1 }, { b: 2 }]; 5data.map((item) => <li key={uid(item)}>{item}</li>); 6 7// unique strings 8const data = ['a', 'b']; 9data.map((item) => <li key={uid(item)}>{item}</li>); 10 11// strings 12const data = ['a', 'a']; 13data.map((item, index) => <li key={uid(item, index)}>{item}</li>);
JS API might be NOT (multi-tenant)SSR friendly,
UID
- renderless container for generation IdsUIDConsumer
- renderless container for generation Ids1 import {UID} from 'react-uid'; 2 3 <UID> 4 {id => ( 5 <Fragment> 6 <input id={id} /> 7 <label htmlFor={id} /> 8 </Fragment> 9 )} 10 </UID> 11 12 // you can apply some "naming conventions" to the keys 13 <UID name={ id => `unique-${id}` }> 14 {id => ( 15 <Fragment> 16 <input id={id} /> 17 <label htmlFor={id} /> 18 </Fragment> 19 )} 20 </UID> 21 22 // UID also provide `uid` as a second argument 23 <UID> 24 {(_, uid) => ( 25 data.map( item => <li key={uid(item)}>{item}</li>) 26 )} 27 </UID> 28 29 // in the case `item` is not an object, but number or string - provide and index 30 <UID> 31 {(_, uid) => ( 32 data.map( (item, index) => <li key={uid(item, index)}>{item}</li>) 33 )} 34 </UID>
The difference between uid
and UID
versions are in "nesting" - any UID
used inside another UID
would contain "parent prefix" in the result, scoping uid
to the local tree branch.
UID might be NOT SSR friendly,
useUID()
will generate a "stable" UIDuseUIDSeed()
will generate a seed generator, you can use for multiple fields1import { useUID, useUIDSeed } from 'react-uid'; 2 3const Form = () => { 4 const uid = useUID(); 5 return ( 6 <> 7 <label htmlFor={uid}>Email: </label> 8 <input id={uid} name="email" /> 9 </> 10 ) 11} 12 13const Form = () => { 14 const seed = useUIDSeed(); 15 return ( 16 <> 17 <label htmlFor={seed('email')}>Email: </label> 18 <input id={seed('email')} name="email" /> 19 {data.map(item => <div key={seed(item)}>...</div> 20 </> 21 ) 22}
Hooks API is SSR friendly,
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
1import { UIDReset, UIDConsumer } from 'react-uid'; 2 3<UIDReset> 4 <UIDConsumer> 5 {(id, uid) => ( 6 <Fragment> 7 <input id={id} /> 8 <label htmlFor={id} /> 9 data.map( item => <li key={uid(item)}>{item}</li>) 10 </Fragment> 11 )} 12 </UIDConsumer> 13</UIDReset>;
UID is not 100% SSR friendly - use UIDConsumer.
Codesplitting may affect the order or existence of the components, so alter
the componentDidMount
order, 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 UIDFork
creates a new branch of UIDs untangled from siblings.
1import {UIDReset, UIDFork, UIDConsumer} from 'react-uid'; 2 3 <UIDReset> 4 <UIDFork> 5 <AsyncLoadedCompoent> 6 <UIDConsumer> 7 { uid => <span>{uid} is unique </span>} 8 </UIDConsumer> 9 </UIDFork> 10 <UIDFork> 11 <AsyncLoadedCompoent> 12 <UIDConsumer> 13 { uid => <span>{uid} is unique </span>} 14 </UIDConsumer> 15 </UIDFork> 16 </UIDReset>
The hooks API only needs the <UIDFork>
wrapper.
"Basic API" is not using Context API to keep realization simple, and React tree more flat.
Written in TypeScript
MIT
No vulnerabilities found.
Reason
no vulnerabilities detected
Reason
no dangerous workflow patterns detected
Reason
tokens are read-only in GitHub workflows
Reason
license file detected
Details
Reason
all dependencies are pinned
Details
Reason
no binaries found in the repo
Reason
update tool detected
Details
Reason
GitHub code reviews found for 14 commits out of the last 30 -- score normalized to 4
Details
Reason
1 commit(s) out of 30 and 0 issue activity out of 10 found in the last 90 days -- score normalized to 0
Reason
no badge detected
Reason
security policy file not detected
Reason
project is not fuzzed
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2022-08-15
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More