npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

react-uid

v2.3.3

Published

Render-less container for ID generation

Downloads

792,194

Readme

UID

Build Status coverage-badge NPM version Greenkeeper badge bundle size downloads

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

API

React UID provides 3 different APIs

  • vanilla js API - uid(item) -> key
  • React Component, via renderProp based API - <UID>{ id => <><label htmlFor={id}/><input id={id}/></>}</UID>
  • React Hooks - useUID

Javascript

  • 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
import { uid } from 'react-uid';

// objects
const data = [{ a: 1 }, { b: 2 }];
data.map((item) => <li key={uid(item)}>{item}</li>);

// unique strings
const data = ['a', 'b'];
data.map((item) => <li key={uid(item)}>{item}</li>);

// strings
const data = ['a', 'a'];
data.map((item, index) => <li key={uid(item, index)}>{item}</li>);

JS API might be NOT (multi-tenant)SSR friendly,

React Components

  • (deprecated)UID - renderless container for generation Ids
  • UIDConsumer - renderless container for generation Ids
 import {UID} from 'react-uid';

 <UID>
     {id => (
       <Fragment>
         <input id={id} />
         <label htmlFor={id} />
       </Fragment>
     )}
 </UID>

 // you can apply some "naming conventions" to the keys
  <UID name={ id => `unique-${id}` }>
      {id => (
        <Fragment>
          <input id={id} />
          <label htmlFor={id} />
        </Fragment>
      )}
  </UID>

  // UID also provide `uid` as a second argument
  <UID>
       {(_, uid) => (
         data.map( item => <li key={uid(item)}>{item}</li>)
       )}
  </UID>

  // in the case `item` is not an object, but number or string - provide and index
  <UID>
       {(_, uid) => (
         data.map( (item, index) => <li key={uid(item, index)}>{item}</li>)
       )}
  </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,

Hooks (16.8+)

  • useUID() will generate a "stable" UID
  • useUIDSeed() will generate a seed generator, you can use for multiple fields
import { useUID, useUIDSeed } from 'react-uid';

const Form = () => {
  const uid = useUID();
  return (
    <>
     <label htmlFor={uid}>Email: </label>
     <input id={uid} name="email" />
    </>
  )
}

const Form = () => {
  const seed = useUIDSeed();
  return (
    <>
     <label htmlFor={seed('email')}>Email: </label>
     <input id={seed('email')} name="email" />
     {data.map(item => <div key={seed(item)}>...</div>
    </>
  )
}

Hooks API is SSR friendly,

Server-side friendly UID

  • 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

import { UIDReset, UIDConsumer } from 'react-uid';

<UIDReset>
  <UIDConsumer>
    {(id, uid) => (
      <Fragment>
        <input id={id} />
        <label htmlFor={id} />
        data.map( item => <li key={uid(item)}>{item}</li>)
      </Fragment>
    )}
  </UIDConsumer>
</UIDReset>;

UID is not 100% SSR friendly - use UIDConsumer.

Code splitting

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.

import {UIDReset, UIDFork, UIDConsumer} from 'react-uid';

 <UIDReset>
     <UIDFork>
      <AsyncLoadedCompoent>
         <UIDConsumer>
           { uid => <span>{uid} is unique </span>}
         </UIDConsumer>
     </UIDFork>
     <UIDFork>
       <AsyncLoadedCompoent>
          <UIDConsumer>
            { uid => <span>{uid} is unique </span>}
          </UIDConsumer>
      </UIDFork>
 </UIDReset>

The hooks API only needs the <UIDFork> wrapper.

So hard?

"Basic API" is not using Context API to keep realization simple, and React tree more flat.

Types

Written in TypeScript

Licence

MIT