Global Styles Framework: Remove the need for GlobalStylesProvider and GlobalStylesContext

[youknowriad]

The site editor uses GlobalStylesProvider and GlobalStylesContext to be able to track edits and modifications to global styles and also to make useGlobalStyle and useGlobalSettings hooks work properly.

That API was just an imperfect temporary API and it's not really needed. It's also blocking the possibility of third-party users from accessing global styles and modifying them properly.

Instead of this context and hooks, we should just have getGlobalStyle and getGlobalSetting selectors in core-data directly. I don't think the context is needed anymore.

One existing place where the "context" might still be helpful is the "style variations previews". That said, the need there is very small, we can instead just try to retrieve the values we need directly from the global styles objects (background, fonts...)

cc @WordPress/gutenberg-core

[ramonjd]

Thanks for the issue. Sounds like a plan.

we should just have getGlobalStyle and getGlobalSetting

What would these return? User/merged theme config??

If "user", should we think about stabilizing experimentals such as __experimentalGetCurrentThemeBaseGlobalStyles?

And then, I'm guessing we'll still need the usual suite of utility methods to accompany the API (assuming it's public for third parties). For example, mergeBaseAndUserConfigs — probably can think of a better name, or model after Theme_JSON_Resolver — or a getMerged selector so consumers can get the site's merged styles/settings.

I might be assuming way too much though 😄

[youknowriad]

What would these return? User/merged theme config??

It would depend on the arguments I think (just like the hook)

If "user", should we think about stabilizing experimentals such as __experimentalGetCurrentThemeBaseGlobalStyles?

I would like for this to be considered after we explore saved style variations. Because that id might change over time. So maybe the getGlobalStyle, getGlobalSetting can take an optional "user style id".

And then, I'm guessing we'll still need the usual suite of utility methods to accompany the API (assuming it's public for third parties). For example, mergeBaseAndUserConfigs — probably can think of a better name, or model after Theme_JSON_Resolver — or a getMerged selector so consumers can get the site's merged styles/settings.

Why? get/setGlobalStyle and get/setGlobalSetting should handle all the complexity internally.

We might even start with private selectors first and open them on a second time.

[aaronrobertshaw]

What would these return? User/merged theme config??
...
or model after Theme_JSON_Resolver — or a getMerged selector so consumers can get the site's merged styles/settings.

Having alignment or consistency between the JS side and the theme.json PHP classes would help make working with Global Styles features easier.

[ramonjd]

Why? get/setGlobalStyle and get/setGlobalSetting should handle all the complexity internally.

Because when I read getGlobalStyle and I assume get "user" global styles. "get" base config is, or at least has been, the base theme.json, conceptually speaking.

I agree that its complexity should be hidden from the end consumer, e.g., returning base/user/merged via function arguments. So that's also cool!

[Mamaduka]

Didn't we initially switch to the context instead of the store for performance reasons? I like the proposed solution, but we should watch out for any progressions.

[youknowriad]

Didn't we initially switch to the context instead of the store for performance reasons?

If I'm not wrong context was there from the start, but maybe my memory is failing me.