Some time ago a decision was made to bundle @wordpress/components when React hooks were introduced. Previous versions of Gutenberg bundled with WP versions we supported did not include hooks and we were forced to package all WP components to avoid fatal errors.
Since then, we have become accustomed to using the latest features of @wordpress/components, including new components marked with the __experimental prefix.
Now that we support WP 5.3, can we unbundle @wordpress/components? The React hooks issue is likely resolved, but can we conditionally import { Text } from '@wordpress/components' or { __experimentalText } from '@wordpress/components' depending on availability?
To go one step further, it would be awesome to have some kind of chart/table/diagram to look up what versions of dependencies we support. For example, to quickly know that WP 5.3 includes Gutenberg 7.3, @wordpress/components 3.0.0, etc. Bonus if it could be automated. This would allow us to quickly know if using a particular component or feature of React will cause backwards incompatibility issues.
An update on this from the branch I briefly worked on:
With some manual effort and digging around I think we can write a Wordpress compatibility matrix, but sadly changelogs for things like @wordpress/components are not accurate. If we were to automate this it would involve spinning up an environment and checking for presence of exports on the wp.components global.
If we drop support for WP 5.3.x (go to 5.4 as minimum) and don't add any more experimental features from @wordpress/components we can unbundle @wordpress/components like I tried to in #5144
With some manual effort and digging around I think we can write a Wordpress compatibility matrix,
Is is worthwhile to do this process manually on WP updates?
If we drop support for WP 5.3.x (go to 5.4 as minimum)
This will happen December 2020.
@psealock that's sooner than I thought. That's good news, we can likely do this later in the year then.
I think it could be worthwhile to do it manually on WordPress updates. I can see it being a value table.
Checking in here @samueljseay as the 5.6 RC was recently released.
If we drop support for WP 5.3.x (go to 5.4 as minimum) and don't add any more experimental features from @wordpress/components we can unbundle @wordpress/components
Unless I'm missing anything, the only new experimental components added since 5.4 are the ones introduced by Navigation. This feels like a good time to experiment with conditional loading of a feature based on version or availability. Something like a check for __experimentalNavigation or maybe even more explicit like a check in PHP before passing window.wcAdminFeatures onto the client using the woocommerce_admin_features filter.
import { __experimentalNavigation } from '@wordpress/components';
const navigationRoot = document.getElementById(
'woocommerce-embedded-navigation'
);
if ( navigationRoot && __experimentalNavigation ) {
render( <Navigation />, navigationRoot );
}
Most helpful comment
Checking in here @samueljseay as the 5.6 RC was recently released.
Unless I'm missing anything, the only new experimental components added since 5.4 are the ones introduced by Navigation. This feels like a good time to experiment with conditional loading of a feature based on version or availability. Something like a check for
__experimentalNavigationor maybe even more explicit like a check in PHP before passingwindow.wcAdminFeaturesonto the client using thewoocommerce_admin_featuresfilter.