Generating unique ID's and SSR (for a11y and more)

[jquense]

Howdy ya'll,

tl dr: please provide a way to coordinate pseudo-random identifiers across the client and server

This issue has been discussed a bit before (#1137, #4000) but I continually run into this issue, trying to build libraries that provide accessible components by default. The react component model generally speaking offers a big opportunity to raise the often low bar for accessibility in the library and widget world, see experiments like @ryanflorence's react-a11y.

For better or for worse the aria, and a11y API's in the browser are heavily based on using ID's to link components together. aria-labelledby, aria-describedby, aria-owns,aria-activedescendent, and so on all need's ID's. In a different world we would just generate ids where needed and move on, however server-side rendering makes that complicated, because any generated ID is going to cause a mismatch between client/server.

We've tried a few different approaches to address some of this, one is making id's required props on components that need them. That gets kinda ugly in components that need a few id's but moreso it annoys users. Its unfortunate because if we could generate deterministic id's we could just provide more accessible components by default.

The frustrating part is that the component generally has all the information it needs to just set the various aria info necessary to make the component usable with a screen reader, but are stymied by not having the user provide a bunch of globally unique ids'

So far only really reasonable approaches I've seen are @syranide's solution of a root ID store, and using _rootID. The latter obviously has problems. The former doesn't scale well for library authors. Everyones' root App component is already wrapped in a Router, Provider, etc, having every library use their own root level ID provider is probably not super feasible and annoying to users.

It seems like the best way to do this would be if React (or a React addon) could just provide a consistent first class way to get a unique identifier for a component, even if it is just a base64 of the node's _rootID.

thanks for all the hard work everyone!

[milesj]

I currently solve this by generating a UID in a components constructor, which is then used as the basis for all my DOM IDs -- as seen here: https://github.com/titon/toolkit/blob/3.0/src/Component.js#L115

I then pass this UID along to all the children via contexts, which allows them to stay consistent: https://github.com/titon/toolkit/blob/3.0/src/components/accordion/Header.js#L62 I would then end up with IDs like titon-s7h1nks-accordion-header-1 and titon-s7h1nks-accordion-section-1.

IMO, this kind of functionality doesn't really need to be part of React.

[jquense]

I think your solution still suffers from the exact problem I'm talking about here. Your code seems to depend on this generateUID function which would break server rendering, since the uid generated on the server, is not going to be the one generated on the client, random numbers and all.

[rileyjshaw]

Pulling from #4000, which is a bit long... I believe the major criteria were:

• unique
• consistent between client & server
• consistent over time
• baked in (or in .addons)
• encapsulated: not dependent on knowledge of / access to the full tree
• less cumbersome than some of the presently demonstrated solutions
• shouldn't require users to manually manage & pass in their own ids

From #1137,

We try to avoid adding functionality to React if it can be easily replicated in component code.

Seems it's gotten a bit beyond that now :)

[milesj]

@jquense Then simply write a UID generator function that returns the same value on the server or the client.

generateUID() {
    return btoa(this.constructor.name);
}

[jquense]

@milesj thanks for the suggestions tho in this case that is only helpful if you have one instance of a component on the page.

@rileyjshaw I think that sums up the issue very succinctly, thank you. The best solution is the root store that passes ID's via context, but that's a bit cumbersome for each library to invent and provide unless there was some consensus in the community.

[milesj]

You're over-thinking this a bit. All the reasons you keep stating are easily fixable. Assuming that the server and client render everything in the same order (not sure why they wouldn't), just have a separate function module that generates and keeps track of things.

let idCounter = 0;

export default function generateUID(inst) {
    return btoa(inst.constructor.name) + idCounter++;
}

And in the component.

import generateUID from './generateUID';

class Foo extends React.Component {
    constructor() {
        super();
        this.uid = generateUID(this);
    }
}

And if for some reason you want individually incrementing counters per component, then just use a WeakMap in the function module.

[jquense]

@milesj I appreciate your suggestions and efforts at a solution but you may not be familiar enough with the problem. The simple incrementing counter doesn't work, if only because ppl don't usually render exactly the same thing on the client and server. I think you might want to read the linked issues, specifically #4000. I am well aware of the issues and the possible solutions, if there was an simple straightforward solution that worked I wouldn't be here.

[jimfb]

I think @jquense makes a valid point about us needing a good solution here - it is currently overly painful to coordinate psudorandom identifiers for component. The problem is exacerbated when different components choose different solutions for solving the coordination problem. We see the exact same problem when components use the clock (for instance, to print relative times). We also see similar use cases for things like sharing flux stores across component libraries. Anyway, I think it would be good to find a real/supported solution for this use case.

[brigand]

What about React.getUniqueId(this) which makes an id based on the key path + an incrementing counter for that key path. ReactDOMServer.renderToString could reset the hash of paths to counter ids.

[cannona]

Sorry if this comment is ignorant. I'm a bit of a noob, but if the key path is always unique and immutable, would we need a counter at all? So, in short:

React.getUniqueId(this[, localId])

This would return a unique id based on the key path, and the optional second argument, if provided. The function would be pure, in that it would always return the same output given the same inputs, I.E. no counter.

If more than one ID was needed within the same component, the optional second argument could be provided to differentiate between the two.

Of course if key paths aren't immutible and unique, then this obviously won't work.

[jquense]

@jimfb did you, or the rest of ya'll at FB have any thoughts about a potential API for this sort thing?

I might be able to PR something but not quite sure what everyone thinks the reach should be. Coordinating identifiers is a different sort of thing that coordinating a some sort of server/client cache, which is what suggests itself to me thinking about the Date or flux store use-case.