Audit experimental features in WordPress Components Gallery

[WunderBart]

Master tracking issue: #44251

WordPress Components Gallery is dependant on experimental features without a fallback for a scenario where such a feature is not supported anymore. Below is a list of usages that we need to update in this matter:

• wp-calypso/client/devdocs/design/wordpress-components-gallery/alignment-matrix-control.tsx

  Line 9 in 1790a34

  import { __experimentalAlignmentMatrixControl as AlignmentMatrixControl } from '@wordpress/components';

• wp-calypso/client/devdocs/design/wordpress-components-gallery/autocomplete.tsx

  Line 9 in 1790a34

  import { Autocomplete, __experimentalInputControl as InputControl } from '@wordpress/components';

• wp-calypso/client/devdocs/design/wordpress-components-gallery/box-control.tsx

  Line 9 in 1790a34

  import { __experimentalBoxControl as BoxControl } from '@wordpress/components';

• wp-calypso/client/devdocs/design/wordpress-components-gallery/radio.tsx

  Line 10 in 1790a34

  __experimentalRadio as Radio,

• wp-calypso/client/devdocs/design/wordpress-components-gallery/radio.tsx

  Line 11 in 1790a34

  __experimentalRadioGroup as RadioGroup,

• wp-calypso/client/devdocs/design/wordpress-components-gallery/text.tsx

  Line 9 in 1790a34

  import { __experimentalText as Text } from '@wordpress/components';

• wp-calypso/client/devdocs/design/wordpress-components-gallery/toolbar.tsx

  Line 28 in 1790a34

  __experimentalToolbarItem as ToolbarItem,

• wp-calypso/client/devdocs/design/wordpress-components-gallery/tree-grid.tsx

  Line 11 in 1790a34

  __experimentalTreeGrid as TreeGrid,

• wp-calypso/client/devdocs/design/wordpress-components-gallery/tree-grid.tsx

  Line 12 in 1790a34

  __experimentalTreeGridRow as TreeGridRow,

• wp-calypso/client/devdocs/design/wordpress-components-gallery/tree-grid.tsx

  Line 13 in 1790a34

  __experimentalTreeGridCell as TreeGridCell,

[WunderBart]

@Automattic/team-calypso is this something that you could look into?

[sarayourfriend]

@diegohaz I wonder if you have any insight into the best way to deal with experimental features? Would it be wiser to just not use them at all in this setting or is there a safe way to use them? I'm not familiar with how to do "safe" imports or anything like that.

[diegohaz]

@saramarcondes

If it's just for internal usage and we're okay with things unexpectedly breaking, I think it's not a big problem. But, ideally, we shouldn't depend on experimental features.

The problem is that code will eventually break:

The conversion to a stable API will inherently be considered a breaking change by the mere fact that the function name must be changed to remove the __experimental prefix.

source

If we use experimental features, we should set fixed versions in our package.json (which is currently not the case).

For reference, this has already been a problem because Gutenberg was depending on experimental features of Reakit without fixing the dependency version: ariakit/ariakit#667 (comment). Reakit has a dedicated section about this that would also apply to @wordpress/components usage: https://reakit.io/docs/experimental/

[sarayourfriend]

That's helpful @diegohaz, thank you. I think it's safe for things to break in the components gallery world... however I'm wary of adding another potentially roadblock to upgrading the WordPress dependencies (as today it's already a hassle). I wonder if we should remove these afterall?

This PR #46424 does depend on an experimental feature... in fact I don't believe there's any other component that could be used there. Luckily I believe we can switch it to just use a regular input because it is ultimately de-styled by the Search component's styles.

[griffbrad]

I'd recommend doing a pass through the list that @WunderBart provided and asking whether each one provides value in regards to the broader style compatibility efforts for @wordpress/components in Calypso. For example, I feel totally fine dropping AlignmentMatrixControl out of the gallery. It's a newer component used in particular blocks that is styled with CSS-in-JS, so it's not really important to monitor as we remove global styles from Calypso. ToolbarItem, on the other hand, can be used in many core blocks (wherever a straightforward ToolbarButton isn't appropriate) and may be used elsewhere in Calypso.
I'd err on the side of removing the experimental usages to ease future upgrades, like you suggested. Worst-case, though, it's good to keep in mind that removing the usage in the context of the gallery is always pretty trivial. We're not talking about a component really being used for actual functionality.

[tyxla]

I agree we can drop some of the experimental components out - some of them may never end up being stable ones, and if they end up stable, we can always include them back.

It's worth keeping an eye on the WordPress components gallery every now and then, as the list of experimental components will always change with every new release.

That being said, it's also worth keeping an open mind that the gallery is far from being a widely used tool at this point, but that is going to start changing as we continue adopting @wordpress/components more and more in Calypso.

[WunderBart]

Worth keeping an eye on this one in case you've missed it: WordPress/gutenberg#25786

[diegohaz]

ToolbarItem, on the other hand, can be used in many core blocks (wherever a straightforward ToolbarButton isn't appropriate) and may be used elsewhere in Calypso.

ToolbarItem is an example of a component that dropped the __experimental flag. So this will break when upgrading @wordpress/components.

[sirreal]

Closing this as of #47712 / p4TIVU-9xW-p2