DataViews: Component crashes on interaction with UI

[ryanwelcher]

Description

I have an admin page that is using the <DataViews /> component. The code is based on the this Developer Blog article.

On initial load, the there are a large number of console errors for JSX elements returning undefined and then when clicking on any of the controls, the app crashes with more errors.

I have tested this and it only occurs with version 4.3.0 of the package but 4.2.0 works as expected. This also occurs in repo related to the article

Step-by-step reproduction instructions

Checkout the developer blog repos and install it:

1. git clone [email protected]:wptrainingteam/devblog-dataviews-plugin.git
2. cd devblog-dataviews-plugin
3. npm i
4. npm run build
5. npx @wp-now/wp-now start

Navigate to Media->Add Media from third party service

Screenshots, screen recording, code snippet

dataviews-crash.mov

Environment info

• WordPress 6.6.1
• Node version: v20.17.0
• Mac OS 14.6.1
• Google Chrome

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[ryanwelcher]

cc @juanmaguitar @oandregal

[oandregal]

@ryanwelcher I've setup the devblog-dataviews-plugin, modified package.json to use dataviews 4.3.0, and I can see an error upon clicking any control.

I don't have much time to look at this today, but wanted to ask if you could provide instructions to use the devblog-dataviews-plugin with unminified React (I've tried using npm run start but it didn't help).

Gravacao.do.ecra.2024-09-10.as.08.18.02.mov

---

The video in the OP is a different example. Based on the console messages, the issues there may be different: I'd think your fields aren't getting proper labels/headers as React elements. Happy to take a look if setup instructions are provided.

[louwie17]

@gigitux and I were getting similar errors but with version 4.2.0 ( haven't tried 4.3.0 yet ). We found out that the reason is that dataviews relies on @wordpress/components and DropdownMenuV2 component, its exports have recently changed, see this PR: #64654

We were seeing the error in 4.2.0 when running it against GB trunk, using GB 19.1 worked for example.
I am guessing you are seeing it in 4.3.0 because you are not running GB trunk and running the newer Dataviews package relying on the new DropdownMenuV2 exports, while the site still bundles the old one.
This should get fixed if you run it against GB trunk or wait until GB 19.2 is released.

In summary the error should dissipate if you run:

• Dataviews 4.2.0 and older with GB 19.1 and older ( or don't have GB installed )
• Dataviews 4.3.0 and GB trunk or 19.2 and newer ( 19.2 should get released soon ).

[ryanwelcher]

Thanks for the follow up here. This makes sense to me.

[oandregal]

For awareness, there's a related slack thread about this.

The TLDR is: the issue is not DataViews, but how it's bundled in a WordPress environment. When one of its dependencies (@wordpress/components, for example) have differences between what DataViews declared and what the environment uses.

In particular, this can happen if you use the npm package but the corresponding Gutenberg release is not yet public. This is, there's a few days between the Gutenberg RC (where packages are released) and the Gutenberg release where dependencies can differ.

This is my understanding so far. I'm far from an expert in this matter, but it seems an recurring issue we may have. I'm thinking we should close this issue as won't fix or repurpose it to explain/focus the bundler situation.

[jsnajdr]

The dataviews package uses the private DropdownMenuV2 component from @wordpress/component and the way that component is exported has changed a lot in recent months. First it started using an "overloaded naming convention" where DropdownMenuItemLabelV2 disappears and is replaced with DropdownMenuV2.ItemLabel. And then the entire DropdownMenuV2 component was renamed to just Menu. Neither the dataviews nor the components package makes any attempt at being compatible with out-of-sync versions. As soon as the versions of both packages don't match exactly, exports are missing and become undefined.

Production plugins, when they use experimental or private APIs, always maintain some compatibility layer where a Menu.ItemLabel would be retrieved like:

const ItemLabel = wp.components.Menu?.ItemLabel ?? wp.components.DropdownMenuV2?.ItemLabel ?? wp.components.DropdownMenuItemLabelV2;

[jsnajdr]

@mirka @ciampo @tyxla This is a very practical issue with using private APIs we could attempt to solve.

It's been just addressed and closed by Riad vie the @wordpress/dataviews/wp bundle in #66825, but that is a very radical solution and we cannot use it everywhere. Not every plugin can bundle the @wordpress/components library. And we'd rather if everyone was able to use the wp.components provided by the platform.

The story is that someone reads a blog post on developer.wordpress.org about DataViews, and when they want to try it out themselves, they fail miserably. Everything crashes with a mysterious error:

React.jsx: type is invalid -- expected a string or a class/function but got: undefined

The reason is that dataviews imports a private component from components and tries to use the component is JSX. But the name that dataviews is importing is not exposed on the private API object.

Can we start with improving the DX? To at least report some sensible error?

The object returned by the lock function could detect that someone is accessing a property that doesn't exist. And log a console error:

You're trying to access a "DropdownMenuV2" private export in the "@wordpress/components" package but that export doesn't exist.
The private APIs exposed by this version of the package are: ComponentsContext, Tabs, Theme, Menu.

Or:

Plugin "foo" is trying to access a "DropdownMenuV2" private export in the "@wordpress/components" package but that export is not available for plugins.
You need to install the latest version of the Gutenberg plugin in order to use private APIs in a plugin.

This won't solve all the private API issues discussed in #66197, but it would be a tangible and valuable step forward.

[oandregal]

I want to link this issue to wptrainingteam/devblog-dataviews-plugin#2 in the original repository. I'll keep the conversation over there but TLDR: I'll update that repo to use what Riad implemented at #66825 so it doesn't randomly breaks with updates.