Investigate about potential use of WordPress components in WordPress dashboard

[raaaahman]

Would we be able to import React components from the @wordpress/component package and use them in the WordPress dashboard?

See @senadir reply in #17 #17 (comment)

Would it be a good thing to do ?

[folletto]

I'd +1 this direction — where it makes sense.

[raaaahman]

From March 22, 2021 Office Hours:

@aristath

With that in mind, I don't think the focus should be reusing the Gutenberg elements... Sure it's doable, but I'm not sure it's worth the time that will be spent doing it. At least not for a while... It wouldn't really make a difference considering everything else in the dashboard will be using the old implementations.

Definitely not jQuery... :sourire: We're trying to get rid of it in the dashboard and slowly but steadily scripts are getting converted to vanilla. On the frontend if we use jQuery that would assume that the active theme is also using jQuery - which is not always the case.

If vanilla JS is not an option then the next best thing would be React. Doing a different implementation for the frontend and backend wouldn't make a lot of sense...

In FSE themes there is a conscious effort to keep things as small and fast as possible, so for example there are no scripts at all required. If notifications load a 50kb script, then that's 50k on each pageload on 40% of the web

We can use react, but do we really need to?

@folletto

Afaik the plan is to bring Gutenberg and wordpress/components in WP Admin.

See for example the Navigation editing page here: WordPress/gutenberg#29793
Which has both a WP Admin page, as well as FSE blocks. (modifié)

The question is imho not “if”, but “when”.

Also I agree on a mention above that frontend and backend admin are different beasts. Waiting a bit for a page to load as a admin, once per WordPress upgrade, is reasonable. Different it is if you’re getting people in to read an article and then bounce. :visage_légèrement_souriant:

I also agree that FSE is probably not relevant here, but wordpress/components are – as they are meant to be reusable components

[raaaahman]

From March 29, 2021 Office Hours:

@TimothyBJacobs

I don't think page weight is a large factor since this is a WP-Admin screen, so we aren't affecting the load time of the front-end of the site, and the libraries we'd be using like wp-components and wp-data will likely be cached by the user's browser. Or will become cached.

there is a Card component, Button and Icon Button components, etc... I don't think there is a drawer in wp-components. There is a storybook with most things: https://wordpress.github.io/gutenberg/?path=/story/docs-introduction--page

[paaljoachim]

Take a closer look at this article:
https://wptavern.com/blockify-the-wordpress-dashboard-with-the-mission-ctrl-plugin

[paaljoachim]

I believe that Iframe the editor content being worked on will also help bring Gutenberg to areas outside of the Block Editor environment. WordPress/gutenberg#21102

[raaaahman]

Take a closer look at this article:
https://wptavern.com/blockify-the-wordpress-dashboard-with-the-mission-ctrl-plugin

Interesting. I could see the use of notifications / notification hub as blocks if the blockified dashboard become widely used. Although I fail to see the benefits of making the notifications / notification hub from blocks... 🤔

[jonathanbossenger]

I think it's important to make sure that we use the tool that makes sense.

To start with, I'll quote from the WordPress Block handbook Glossary

Block
The abstract term used to describe units of markup that, composed together, form the content or layout of a webpage. The idea combines concepts of what in WordPress today we achieve with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.

In my experience building custom blocks, a block is an interactive component that has three main elements:

1. Attributes - used to store arbitrary data for a block
2. An edit function - used to represent the functionality of the block in order to edit i's attributes/content
3. A save function - used to store the data attributes/content of a block.

It's worth noting that the purpose of the Mission Ctrl plugin is to allow "users, developers, agencies, or even hosts set up the dashboard with custom widgets (called boards) that are built through the block editor". So there is some aspect of the user using the Mission Ctrl boards interacting with them, in both editing and saving the content of a board, and it's location, to then be rendered on the dashboard.

A notification, however, while it may require some way to save data, will not require any interaction by the user to do so. A notification's data will be saved programmatically. At the same time, the edit functionality is not needed, as the content should never need to be edited. Once the notification is stored in the database, the only stage change will be along the lines of marking it as read.

That having been said, I am excited about the possibility of building the notification component on top of at least the @wordpress/component package, and maybe even others, but in my mind, the notification component would not extend the block component. That would almost be like using a custom post type for notifications.

[folletto]

That having been said, I am excited about the possibility of building the notification component on top of at least the @wordpress/component package, and maybe even others, but in my mind, the notification component would not extend the block component. That would almost be like using a custom post type for notifications.

+1 to this, Blocks don't seem a good fit here.

Reuse wordpress/components is the way to go.

[erikyo]

Is what we did! :)

Closing because outdated!