Gutenberg: No visual feedback when Parent Page dropdown is loading.

[iandunn]

Is your feature request related to a problem? Please describe.

There's no visual feedback when the Parent Page dropdown in the Page Attributes inspector control is being populated via a REST API endpoint.

I open the Page Attributes panel, and then find myself thinking, "Wait, where's the Parent Page dropdown? I thought it was under this panel." And then, depending on how long the request takes to finish, I either go off in search of it by looking in other panels (and possibly closing Page Attributes in the process), or it appears just in time, and I realize that it was simply loading all along.

Describe the solution you'd like

Is there a compelling reason why this data needs to be fetched from the API, instead of just being passed from PHP to JS during the initial page request (i.e., with wp_add_inline_script()). The latter would make it available immediately, rather than introducing all of the overhead and latency of an HTTP request.

Although, I guess in some cases the number of pages could be so large that it would significantly slow down the initial page request. So maybe instead it'd be better to pre-fetch the data once the page has loaded, rather than waiting until the user has opened the panel?

Describe alternatives you've considered

If those options aren't good, then we should at least add immediately show the Parent Page label with a disabled dropdown, and a spinner, so that the user knows the application is loading data. When the data returns, the dropdown can be populated and enabled.

Related issues (which won't solve the underlying problem)

https://github.com/WordPress/gutenberg/issues/13618
https://github.com/WordPress/gutenberg/issues/15115

[mapk]

I'm not entirely sure the reason behind the path we chose here, but I agree that we don't want to add to the initial page load time.

As discussed in today's triage in the Design channel in slack, this sounds like a good idea.

If those options aren't good, then we should at least add immediately show the Parent Page label with a disabled dropdown, and a spinner, so that the user knows the application is loading data. When the data returns, the dropdown can be populated and enabled.

I'm removing Needs Design Feedback and adding Needs Design for this particular part.

[mapk]

Here's what the disabled parent dropdown would look like. I like @iandunn's suggestion of just using PHP to solve this because I'm unaware why we're using the API here, but the lag is real and it would be great to either fix the lag, or at the very least show a disabled dropdown like this before the real dropdown appears.

[iandunn]

I think that would solve a big part of the problem 👍

I do worry that people would still be confused as to _why_ it's disabled, though. What do you think about having some kind of "loading" placeholder?

[mapk]

While I really like the reasoning in that documentation, I don't think we use the blueprint loading effect in Core, do we? In this case we could include the spinner component which might look something like this:

[iandunn]

I can't think of any instances in Core or Gutenberg, so maybe a spinner would be better. I personally feel like placeholders are better, but that's probably outside the scope of this ticket.

For now, I think a spinner here would prevent confusion 👍

[karmatosed]

This brings up the potential need for a loader that adapts because not sure the circle one works. For now, though I would advise this goes beside the thing it's loading as we don't need to put below, the UI element will populate that.

[ItsJonQ]

Hallooo 👋 !

@iandunn + @karmatosed I see where you folks are coming from! I agree that having a (loading) indicator of some kind would be helpful. Like you mentioned @karmatosed , having the loading circle may not be the best.

Ideally, I think the base/core/primitive components should have a built-in loading state of some kind.

Example:

It solves the UX issue @iandunn originally mentioned - not only in this one particular case but in all parts of Gutenberg.

From a code standpoint, having the mechanism being built into the core components is incredibly valuable. It takes care of a lot of rendering/internal/accessibility complexities - simplifying the code to being something like isLoading={true/false}.

[ItsJonQ]

@iandunn + @karmatosed How's this? :D

Note: I didn't focus too much on aesthetics. Personally, I don't know if the current spinner design UI works well in these embedded loading contexts. For consistency, I used the Spinner as is for now

P.S. Accessibility is taken care of as well, as the isLoading trigger controls the aria-busy attribute

[iandunn]

That looks good to me, thanks!

[mapk]

This is great, @ItsJonQ! I think using the Spinner component as you have it right now might be a good interim solution. Do we need a list of which components can benefit from this feature?

[karmatosed]

Love it! That's ace @ItsJonQ.

[ItsJonQ]

Thanks all!

Do we need a list of which components can benefit from this feature?
@mapk Sure. That wouldn't hurt. I'm starting off with form control based Components, so Buttons, Select, etc... :)

[MichaelArestad]

@ItsJonQ is there a PR for this yet? 🤞

[ItsJonQ]

@MichaelArestad Ah, it's been a while. My apologies! I'll revisit this work/PR this afternoon 🙏

[ItsJonQ]

Haii! I just created a PR here for this:
https://github.com/WordPress/gutenberg/pull/21435

The isLoading state looks like this:

This is different compared to the mockups/renders earlier in this issue. I kept the changes minimal.

I'm unsure how the UIs (spinner, select, etc...) will be adjusted with the evolving editor UI (aka. G2). I can of course make best guesses based on mockups, Figma files, and shared work.

However, I feel like this design adjustment can be done as a complimentary follow up to the functional change, that is, providing the SelectControl and TreeSelect with the ability to handling loading states.