react-select generating duplicate instanceId's

[aidanlister]

Should we leave the id attribute off? Otherwise you'll get DOM errors:

[Rall3n]

@aidanlister It seems like you have a problem with the id creation for the search input.

The ids should count up with every new instance of the Select component by default (react-select-{n}-input). You having two input elements with the same id means there is some kind of error.

Unfortunately I can´t recreate this problem. Would you mind sharing a minimal reproducible example using CodeSandbox?

[karimdaghari]

I used the instanceId prop like so: instanceId={normalizedId}. It got rid the warning(s) for me.

I think the way it works is that react-select tries to keep an internal count of all its instances (hence the 2) but sometimes, for some (unknown to me) reason it doesn't work as expected.

[Methuselah96]

I've also intermittently experienced this without any code changes. @aidanlister Does this happen every time for you?

[aidanlister]

@Methuselah96 yes, it's consistently an issue. I won't have time to make a minimal example but we get this on every page where we have multiple select inputs.

We get it both on pages where we have a single react root, and on pages we don't.

Do we need that id set at all? Is there a way to disable it?

[ebonow]

@aidanlister we can investigate more to better understand why this is happening. I personally have not come across this.

As a work-around, I would offer you try something like lodash/uniqueId and pass that in as the instanceId prop to get around these warnings until we can diagnose why this is occurring and come up with a fix for it.

If you can provide a working example, when you have the opportunity, it will help us better identify the root cause. Thanks!

[aidanlister]

I’m curious why it is a thing- what is that unique ID used for? If it isn’t required for the component internally, would it be better to have id= generation disabled by default or disabled via a flag? Or is it accessibility related?

[ebonow]

@aidanlister Sorry but I still have not been able to reproduce this error such that the instance id repeats.

The instanceId is used for generating unique id's for the input (as well as other components within it) when one is not provided to the Select

[aidanlister]

@ebonow it seems easy to replicate, just initialise the widget twice in different react roots. My question is why do you need an ID by default at all? It's not a required attribute, what's the use case?

[ebonow]

@aidanlister, I looked over the code for a bit and it's not immediately clear to me. There is an open PR to support WIA-ARIA which would require unique id's in order to establish some relationships (ie: aria-owns). It's not clear why it's required but I'll keep it in mind as I keep digging through code.

[mellis481]

it seems easy to replicate, just initialise the widget twice in different react roots.

@aidanlister Bingo. I'm frankly shocked to learn that this is how react-select was implemented. It creates WCAG 4.1.1 accessibility violations for every microfrontend-architected application (unless you override instanceId in each microfrontend).

CC: @dgreene1

[dgreene1]

@mellis481 If you override instance ID with a GUID perhaps it’s something that each MicroFrontend can handle via a wrapper in the component library. But we can talk about this more next week when I’m back from PTO. At this point I don’t know enough about the cause or the symptoms. So can you share the a11y errors here for us all?

[cda210]

I played around with this a little bit - for those needing a viable solution within multiple MFEs that you cannot control: https://codesandbox.io/s/codesandboxer-example-forked-ggsyml?file=/example.tsx

This resolved the dupe id and kept the label link in tact.

CC: @dgreene1 @mellis481