WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.55k stars 4.22k forks source link

Editor Canvas Container: refactor and isolate to the site editor #62216

Open ramonjd opened 5 months ago

ramonjd commented 5 months ago

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 https://github.com/WordPress/gutenberg/pull/45960 and refined in https://github.com/WordPress/gutenberg/pull/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:

What is your proposed solution?

Refactor the way Gutenberg displays these alternative slots.

Options could be:

See feedback:

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

What problem does this address?

Since https://github.com/WordPress/gutenberg/pull/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

ramonjd commented 4 months ago

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

Conceptual possibilities

Architecture

The Site Editor component load sequence:

ramonjd commented 4 months ago

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 commented 2 months ago

Related:

richtabor commented 1 month ago

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

ramonjd commented 1 month ago

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 https://github.com/WordPress/gutenberg/pull/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 https://github.com/WordPress/gutenberg/pull/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 https://github.com/WordPress/gutenberg/pull/65619

youknowriad commented 1 month ago

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 commented 3 weeks ago

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:

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 commented 3 weeks ago

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 commented 3 weeks ago

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:

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).