Removing Reakit Composite implementation

[andrewhayward]

What?

Removes the 'unstable' Reakit implementation of the Composite component group.

Why?

We need to remove Reakit from the codebase (#53278).

How?

• Points default export to ./legacy implementation
• Changes 'legacy' Storybook title to "Composite"
• Removes deprecation messages from legacy (to be put back when current is available)
• Removes unstable Reakit implementation

Testing Instructions

Open Storybook, and confirm that there are still two Composite entries ("Composite" and "Composite (V2)").

Note

There are no consumers of the Reakit implementation left in Gutenberg, so we have to trust that test coverage is sufficient that any switch is transparent for consumers.

[ciampo]

Left a couple of comments, but overall the changes look good.

Should we also remove reakit in this PR, or do you prefer to do it in a follow-up?

(also cc @mirka for an extra pair of eyes)

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core SVN

If you're a Core Committer, use this list when committing to wordpress-develop in SVN:

Props: andrewhayward, mciampini, tyxla.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: andrewhayward <andrewhayward@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[andrewhayward]

Should we also remove reakit in this PR, or do you prefer to do it in a follow-up?

Personally I'd rather do it in a follow-up PR, if only to keep this one focused on Composite, but that's not a strongly-held opinion.

[tyxla]

Nice 👍

[tyxla]

Also unrelated, but just spotted that we have 2 "Enhancements" sections.

[ciampo]

Adding the Needs dev note label.

Assuming that changes up to reakit removal will be part of the WordPress 6.5 release, and that the promotion of the new Composite component from private to public API will be part of the WordPress 6.6 release, we will need to separate dev notes:

• one for the 6.5 release, highlighting that we removed reakit because of its incompatibility with newer versions of react and wrote a back-compat layer in ariakit which should cover standard use cases of the component (in theory no action required from consumers of the package). We could also anticipate that we're looking into exposing a new, stable version of the component written natively in ariakit.
• one for the 6.6 release, where we'll announce the new, stable, ariakit-based Composite component, and the related deprecation of the __unstableComposite family of components.

cc @mirka and @bph

[andrewhayward]

Dev note

Changes to the underlying Composite component implementation

WordPress 6.5 no longer includes the Reakit package, as it does not support React beyond v16. The __unstable* Composite component was built on this library, so has been internally refactored.

What does this mean for consumers?

The primary API has not changed, and can still be imported with no changes. For typical usage patterns, there should be no differences, and in most cases no action is required from consumers of the package.

However, composite state props must now be generated by the useCompositeState hook; they can no longer be provided by independent state logic. Composite state arguments have not changed though, and will continue to work as before.

import {
  __unstableComposite: Composite,
  __unstableCompositeGroup: CompositeGroup,
  __unstableCompositeItem: CompositeItem,
  __unstableUseCompositeState: useCompositeState
} from '@wordpress/components';

const state = useCompositeState({ ... });

// ✅ This will continue to work
...( <Composite { ...state } /> );

// ⛔️ This will no longer work
...( <Composite { ...state } currentId={ ... } /> );

Consumers can continue to either spread the state, or pass as a single state prop...

// ✅ Used by spreading the state
...(
  <Composite { ...state }>
    <CompositeGroup { ...state }>
      <CompositeItem { ...state }>
        { ... }
      </CompositeItem>
    </CompositeGroup>
  </Composite>
);

// ✅ Or with a single `state` prop
...(
  <Composite state={ state }>
    <CompositeGroup state={ state }>
      <CompositeItem state={ state }>
        { ... }
      </CompositeItem>
    </CompositeGroup>
  </Composite>
);

Because the shape of the returned composite state has changed, consumers can also now no longer destructure specific state props from useCompositeState.

// ✅ This will continue to work
const state = useCompositeState({ ... });

// ⛔️ This will no longer work
const { groups, items } = useCompositeState({ ... });

What's next?

We anticipate a new stable Composite component to be released in WordPress 6.6, along with the deprecation of this unstable version.