@wordpress/components referencing old version of FormTokenField

[sgrund14]

Describe the bug
A clear and concise description of what the bug is.
I'm trying to build a wrapper around the FormTokenField which asynchronously fetches a suggestion list from a graphql server and populated the dropdown with the fetched terms, and so am using it like this in my custom component

import { FormTokenField } from '@wordpress/components';
...
export const MyComponent = () => {
   ...
   return <FormTokenField suggestions={fetchedSuggestions} onInputChange={getSuggestions} />
}

The problem is, I'm seeing the behavior fixed in this PR #14819
which was merged + published last year. That is, I type in the input, the suggestion list is fetched, but it is not rendered until I trigger another input change. What's strange is that if I copy over the code from node_modules for FormTokenField, the dropdown behaves as expected from the previous fix. I'm not sure why there would be a discrepancy between what I import from @wordpress/components (@^9.3.0) and the node_modules code for that very same component?
To reproduce
Steps to reproduce the behavior:
Outlined above ^

Expected behavior
A clear and concise description of what you expected to happen.
The node_modules version of FormTokenField to run the same code as the imported version
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS] macOs Mojave
• Browser [e.g. chrome, safari] Chrome
• Version [e.g. 22] 79

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context

• Please add the version of Gutenberg you are using in the description. WP 5.2.4
  I'm using yarn@1.17.3 for package management and @wordpress/scripts@^7.2.0 for the build script (wp-scripts build)
• To report a security issue, please visit the WordPress HackerOne program: https://hackerone.com/wordpress.

[sgrund14]

cc @aduth

[aduth]

@sgrund14 Can you include some more detail about your development environment, and specifically which build tools you're using which would convert "import from @wordpress/components" into browser-ready code?

[sgrund14]

sure!

I'm using yarn@1.17.3 for package management and @wordpress/scripts@^7.2.0 for the build script (wp-scripts build)

[aduth]

Thanks. Following-up on my comment from #14819 (comment), while you're likely not explicitly referencing the globals, my understanding of how wp-scripts generates the output is that it will automatically transform imports to the respective globals, via the DependencyExtractionWebpackPlugin Webpack plugin.

Could you share a couple more details:

• The PHP code where your scripts are enqueued.
• The WordPress version of the site on which you're testing the code.

[sgrund14]

of course! it's WP v5.2.4

and it goes

add_action('admin_enqueue_scripts', function() {
    $gql_endpoint = "/soa/graphql";
    wp_register_script( 'taxonomy_plugin_typeahead', plugin_dir_url( __FILE__ ) . 'build/index.js', null, null, true );
    wp_localize_script( 'taxonomy_plugin_typeahead', 'server_vars', ['gql_endpoint'=> $gql_endpoint]);
    wp_enqueue_script( 'taxonomy_plugin_typeahead');
});

running from a custom plugin

[aduth]

By chance, are you able to upgrade the site to the latest version of WordPress to test if it's still a problem?

I am about 80% certain the issue is that the built version of the code is referencing the wp.components global, and that the issue is occurring because the version of @wordpress/components shipped with WordPress 5.2.4 and assigned to the wp.components does not include the changes introduced with #14819.

[sgrund14]

ohhhhh that did it. classic. do you know what version those changes went out with? the site i'm working with is using 5.3.2, and i'm not sure if we can upgrade right now or not.

[aduth]

@sgrund14 It's difficult to say with certainty, but given the release schedule of WordPress 5.3, I think it'd be fair to assume it landed with WordPress 5.3.0.

There may still be options to continue using an older version of WordPress while still using the latest version of the code. However, it can become risky, since it usually involves having multiple versions of the same package loaded in the editor (the version shipped with your version of WordPress, and the more recent NPM versions). I've not personally done this before, so I can't advise on the specifics, but I imagine it could be one or the other of:

• Creating a custom Webpack configuration which "opts out" of having your code reference the window globals, so that the build includes the live versions of the NPM modules.
  • Related: https://github.com/WordPress/gutenberg/blob/master/packages/scripts/README.md#provide-your-own-webpack-config
• Unregistering and replacing the default wp-components script handle in your site with a copy of a newer version of the module.
  • Prior art: https://github.com/WordPress/gutenberg/blob/4924eff/lib/client-assets.php#L37-L98
  • This is pretty risky! Since it's hard to say if the newer versions would cause conflict with other packages and code.

Since the original issue appears to have been identified, I'm going to close the issue since there's not any actionable steps to be taken from Gutenberg itself.

[sgrund14]

thanks much, @aduth. this has been enlightening.