Motivation

When using Composite, it's not uncommon that CompositeItem components can get added / removed / mutated at render time; for example:

• the currently active item is removed from the react tree;
• the currently active item is disabled;
• the active id doesn't initially match any options, but an option with the active ID is added later at render time;

While Composite handles the initial selection of an active item, it doesn't seem to handle any of the above cases, which can result in some unfortunate scenarios, including the inability of the end user to focus any item in the composite widget.

It would be great for consumers of Composite (and derived components) if some (or all) of those scenarios were handled by the component itself, since they are edge cases that can cause the component to stop working as expected.

Usage example

https://stackblitz.com/edit/thqfra?file=button%2Findex.tsx&theme=dark

Note that, when the active composite item is removed from the react tree, the active id can become stale, causing Composite to skip focus on its items entirely.

Requirements

Composite (and Composite-based components) should offer a way for consumers to opt-in to the component updating the activeId when the currently active id doesn't match a focussable composite item, similarly to what the component already does on initial render.

Workaround

The workaround is to implement this custom logic in consumer-land, which is not convenient and requires the consumer to re-write the same logic every time.

Examples:

• updated version of the demo shared above posted above that resets the active ID when the element is removed;
• handling of such edge cases in the Tabs component in @wordpress/components

Or #4129 (comment)

Possible implementations

#4129 (comment)