Editor Canvas Container: refactor and isolate to the site editor

[ramonjd]

Background

The Editor Canvas Container is a slot for the Site Editor that was intended to act as an "alternative" editor canvas to render blocks and styles independently of the main canvas container.

It was first added in #45960 and refined in #49973

The important feature, at least for global style revisions, was to have a "separate" editor view that could be edited independently of the main editor canvas. So changes could be made to styles and so on in the alternative canvas view. When it closes, the user is returned to the main editor canvas in whatever state they left it.

The slot is currently used by:

• The Style Book
• Global Styles revisions

What is your proposed solution?

Refactor the way Gutenberg displays these alternative slots.

Options could be:

• move away from slots, and rather use editor context or children props
• create a new editor UI for such alternative editor views, e.g., removing unnecessary controls and views such as the list view, inserter and so on.

See feedback:

• https://github.com/WordPress/gutenberg/pull/62146/files#r1620915555

There are a lot of unknowns. An approach needs to be confirmed.

What problem does this address?

Since #62146, the Site Editor uses the editor interface from the editor package, which means that the post editor could theoretically fill the Editor Canvas Container is a slot. Currently the only use case for the slot is to house alternative Site Editor views.

Also the way the alternative views are rendered and tracked by is cumbersome and not scalable. Example.

Beyond

The potential is there for Global Styles could be "promoted" to be a top-level entity.

So much like the editor can load a template or a page, it could "load" the site's merged global styles entity with the style book, in conjunction with the global style panel and controls, being the "interface".

Related

• Style Book: Iterate on presentation and design #53431
• Explore improvements to Styles panel in site editor #53483
• Consider exposing the Style Book for classic themes #41119

[ramonjd]

I did a little splashing around the shallow waters of the editor, while thinking about possible approaches.

Here are some notes.

They may or may not have import in relation to the main issue 😄

Loose requirements

• Create a canvas "view" to display global styles-specific features, e.g., style book, revisions.
  • The view:
    • loads a given block list preview (not editable)
    • should function independently to the main editor canvas, e.g., loading and previewing a global styles revision entity shouldn't affect the current user global styles config. Closing the view will return to the main editor canvas in the state the user left it.
    • opens and interacts with the global styles side bar
    • is isolated to the site editor package
    • does not require other editor UI, e.g., list view, block toolbar
    • needs be able to load any user style config, e.g., a global styles revision entity

Conceptual possibilities

• Load a global styles CPT as the "currentPost", and then the UI will decide what to do, e.g., instead of wp_template, wp_global_styles is the "main" entity in the site editor.
  • In the site editor, the edited entity is also set using URL params (checked and resolved) via the setEditedEntity store action in useInitEditedEntityFromURL, which is called in App. Fetched via selectors getEditedPostType and passed (id and post type) to the Editor from Editor package
  • Currently, the Editor store value currentPost is set in ExperimentalEditorProvider via setupEditor, then synced with setEditedPost
• Build a completely different UI and load in the site editor on demand. This could be the path of least resistance.
  • Render in place of the main Layout, with its own entity and block providers , see for example the ExperimentalEditorProvider

Architecture

The Site Editor component load sequence:

• The main index.js of the edit-site package loads App component
• The App component loads the Layout component with a prop route from useLayoutAreas
• useLayoutAreas returns EditSiteEditor (site) based on postType and postId. It can swap layout areas, e.g., sidebar in and out depending on post type etc.
• EditSiteEditor renders the shared Editor component from editor package, passing postId, postType props
• The Editor component renders the ExperimentalEditorProvider which renders the block list, contextual settings and so on

[ramonjd]

A bit of rambling...

Load a global styles CPT as the "currentPost", and then the UI will decide what to do, e.g., instead of wp_template, wp_global_styles is the "main" entity in the site editor.

I started off doing this just to see how far I could get. I created a custom Editor in the edit site package that expected a global styles postType and postId, but ran into snags pretty quickly as I had to recreate the entire interface skeleton and load a global styles side bar that actually worked :D

I mean, it would be possible to build another editor interface from the ground up. Maybe as a separate package, e.g., styles-editor, but the effort might not be of value right now.

Build a completely different UI and load in the site editor on demand.

Passing a child to <Editor /> that can actually render instead of the <VisualEditor /> has some promise, but there are a lot of things to "turn off", e.g., the unnecessary toolbars in the header, showing only the global styles sidebar, and preventing the Visual Editor rendering in the first place.

Basically, the editor package would have to know that an alternative view needs to render instead of a post etc

One avenue might be to refactor the Editor to be able to load a "global styles" post.

[ramonjd]

Related:

• Allow extending editor preview in more ways #65005

[richtabor]

I'm not following here. What's the advantage of doing this, vs. what we have in place today?

[ramonjd]

What's the advantage of doing this, vs. what we have in place today?

Good question!

TL;DR - I think the point here is to reduce technical debt and support a top-level global styles editing experience. My take is that it's primarily a technical nice to have, and its dependent on the direction of such PRs as #65619, so the priority in relation to the redesign tasks already in motion is lower.

@youknowriad first raised the technical and UI concerns: https://github.com/WordPress/gutenberg/pull/62146/files#r1620915555

---

The case for:

Two global styles-related UIs rely on a custom slot in the editor package: style book and global styles revisions.

The purpose of that slot is to display alternative canvas views independent of whatever entity is loaded. For example, if I'm editing a page and I flip to style book, it won't affect the current state of my page edits.

There are a couple of things that could be improved:

1. State management — determining what's on the canvas at any time — has become messy and a pain to maintain. A bit of blue sky thinking, but it could be nice to load a "global styles" editor and then tell it what to do rather than juggle state across the entire editor app.
2. In edit mode, a portion of the editor's UI controls do nothing when such global styles views are shown, although how far we take Site editor: integrate global styles controls and style book preview into the styles panel  #65619 might make this point moot.
3. If global styles editing is "hoisted" away from being an in-editor experience, abstracting away from the editor interface component and removing superfluous code would be a performance and code quality enhancement I believe.

The case against:

Things work okay for now, and we don't have dire need of refactoring, or the justification in terms of time and resources.

As mentioned, this idea will gain focus — for or against — as we work on PRs that offer discrete global styles editing experiences like #65619

[youknowriad]

I think for me it's clear that the slot is a hack, it's not really clear in the editor whether you're editing global styles or a template/post.

It's true that issue is technical mostly but I would say that the technical difficulties are just highlighting a UX issue as well. What's the header about when you've actually switched the canvas to focus on global styles...

This is very similar to the journey we had in the site editor: we started by mix and matching editing templates and pages at the same time and it quickly became confusing to users forcing us to come back to have a single focused entity at any given moment in the editor. (Either a template or the page, not both at the same time). Making that change brought a lot of clarity both UX wise and also technically (which is what allowed the unification of the editors). The current issue is basically, the same struggle/issue but for global styles and templates (or global styles and pages)

[ramonjd]

Just writing some more notes for now.

I've been looking into how to balance the various demands of global styles views in light of the latest discussions, e.g., style book in classic themes, and the discussion about a dedicated styles screen.

A one-size-fits-all approach — one that would cater for the above plus existing style book and global styles revisions — any "styles" view or "styles editor" would need to:

• load a template/page/post entity or any block list (think a list of block examples)
• load any global styles object (and render its CSS). So the current user global styles config, or any one of n historical revisions. It's not yet required but it could even load another theme's theme.json tree.
• ideally, only show a limited set of UI tools, or those that only apply to global styles.
• thinking of the style book, be able to load custom components/JSX.

If we think of a world where only a dedicated styles screen exists, for block and classic themes, there's a reasonable argument for a separate, dedicated package with its own interface, canvas and so on, e.g., edit-styles. This could handle global styles as its main "entity".

However, there's still a case for being able to preview global styles while in the block editor. In fact, that's the reality right now. And that means either making this functionality live in and cooperate with the editor, or, assuming an edit-styles package existed, linking off to that view. The latter could disrupt the flow of users working on a template in the site editor.

The slot hack works because it allows us to quickly swap in anything we want in place of the editor. Refactoring the editor to do this I think might be too hairy.

Assuming a dedicated styles screen becomes a "thing", this makes me wonder whether the style book needs to be extricated from the site editor. So users could still browse and load revisions, but the style book would be a separate experience. Clicking on the style book would take the user to the dedicated screen, which itself could handle anything related to styles.

</unintelligible-rant-over>

[jasmussen]

Appreciate the rant! And it was entirely intelligible! I wanted to note in context of that an update I wrote here, urging a focus first on style book, classic theme improvements, and other pieces first. We absolutely need to get the foundations for these screens in a good place eventually, so this is all valid. But there are arguably some smaller, more focused wins (a few suggested in that link), we can get to first!

[youknowriad]

I'm not sure yet how I feel about a dedicated package. My initial reaction is to avoid early abstraction here as the work is still very much in flux and the direction not settled yet.

That said, one main question here seems to be whether global styles editor/screen is just a regular Editor from @wordpress/editor package where the "post" prop (entity) is the global styles entity or whether it's a completely different UI/component StyleEditor or something like that.

I don't have a clear answer yet, what's clear to me is that:

• It's a component/provider where we pass a "global styles record id" as "active entity". It's clear that later we'd want to edit multiple global styles entities separately and switch... (just like we switch templates or pages today)

I think to answer the first question about whether this is just @worpdress/editor or a new dedicated component/package, we need to check the UI mostly. Is the header the same, is the sidebar the same, is the main area the same.

The more I think about it, the more it feels like these things are very different (only share some small things with the regular post/template editor), so yeah we could have a style-editor package (probably start as a component).