CheckboxControl: stop using Gutenberg's CheckboxControl to avoid duplicated ID's

[Aljullu]

To Reproduce

1. In the block editor add a Checkout block and run AXE or search for #inspector-checkbox-control-5 (the number might be different) in the inspector devtools.
2. Notice there are two checkboxes with the same ID.

This is causing some checkboxes not to be actionable through the <label>:

[Aljullu]

The issue seems to be because we use two different versions of @wordpress/components in the same page (the aliased version for the block checkboxes and the external for the editor checkboxes). @wordpress/components relies on useInstanceId from @wordpress/compose, so it's generating ids independently for the block checkboxes and the editor checkboxes, thus causing duplicates.

My first idea to solve this would be to try to upstream a change in Gutenberg so CheckboxControl¹ allows specifying a custom id. But happy to hear other ideas. 🙂

1. We might want to extend this to all other *Control components in Gutenberg, but maybe better start with only one.

[senadir]

is it the version we're enqueueing that is using useInstanceId I remember we downgraded components so that we don't use that (it caused issues with WP 5.3)

[Aljullu]

I don't think our direct usage of useInstanceId is what's causing the issue here, even though it might cause similar issues in the future. The problem seems to be with <CheckboxControl>: we have two different versions of @wordpress/components in the editor, both of them using different useInstanceId.

useInstanceId uses its own Map to track Component instance number, so two different useInstanceId will have two different Maps, and that could produce duplicated ids.

I can't think of any easy solution other than trying to hardcode ids for the conflicting elements.

[nerrad]

Hmm ya we've hit one of the potential problems we'll face by loading two different sources for packages on the same route.

One suggestion I have is to use webpack alias wordpress-components to the external pacakge for editor builds and leave it alone for frontend builds. Alternatively, we could just always use @wordpress/* in our imports and just use webpack to alias to direct imports for frontend builds.

[senadir]

One suggestion I have is to use webpack alias wordpress-components to the external pacakge for editor builds and leave it alone for frontend builds. Alternatively, we could just always use @wordpress/* in our imports and just use webpack to alias to direct imports for frontend builds.

This seems like the most preferable approach granted that all of our editor code should depend on the external for that to work, mismatched versions in the editor will create issues since sometimes an update in a package is reflected in all packages and they're published together.

[Aljullu]

Correct me if I'm wrong but one of the reasons we are using an aliased version of @wordpress/components was to be able to use components that might still not be available in the external (<Card>, for example). If we force the editor to use the external, those components will not be available.

[senadir]

components that might still not be available in the external (, for example)

That's a good point that I forget, regarding this point, looking at the current state of things, I'm really thinking of doing a refactor for our components and removing @wordpress/components as a dependency (rebuilding included components from scratch) the reason is that as long as we keep supporting 5.3, we won't have tree shaking at all in @wordpress/components, causing a really large extra weight, seeing how complex @wordpress/components dependencies can get, we can't simply alias it, I'd rather see my options in this area before I go rewrite some components, but we might end up doing that if can't constantly keep getting the latest version of @wordpress/components.

This however, should wait until cooldown to see if we should do this or we can see a way out of this.

[nerrad]

Correct me if I'm wrong but one of the reasons we are using an aliased version of @wordpress/components was to be able to use components that might still not be available in the external (, for example).

Oh right. Is this issue only affecting checkbox controls? If so, then it's probably because we import checkbox control for the block. If we don't import WP's checkbox control and just build our own (ugh, but if unavoidable), would that fix?

If this affects all controls then we have a larger problem.

[Aljullu]

• For text inputs and radio controls we are not using Gutenberg's components, so they don't have this issue.
• For country/state inputs, we are using <CustomControlSelect>. It's not setting a unique ID, so it doesn't have this issue either.
• Other components we use like <Card> or <Panel> don't seem to set a unique ID either.

So you're right, the only affected component is the <CheckboxControl>. Refactoring it so it doesn't rely on Gutenberg's checkbox control would fix this issue.

I updated the title of this issue accordingly.