Try/even better previews

[retrofox]

This PR has been cloned from #16113 in order to achieve the same goal but from a different approach.

In short, the final idea behind of these PRs is improving the visualization of the <BlockPreview />.

Some screenshots

Preview styles in the sidebar

Full preview

How can use it

Unlike the previous approach, this proposal does not require that the dimensions of the block (srcWidth and srcHeight), the scale factor be defined (scaleFactor), and whether or not the scale should be adjusted (fitToScale). So, we only need to pass the blocks property to the <BlockPreview /> component to make it work.

<BlockPreviewContent blocks={ cloneBlock( block, { className: styleClassName } ) } />
</div>

How does it work

Width and the Scale.

The scale is computed only considering the width of the blocks and its container. We could polish this approach incorporating the possibility to fit the preview in height, centered, etc. I image something like the background-size and background-position.

The scaled is computed dividing the width of the container element (it belongs to the <PreviewBlock /> component) by the width of the block to visualize. VERY IMPORTANT: it works with only one block so far. However, I'm quite confident that we can make it work for more many blocks as well.

const scale = containerWidth / blocksWidth;

To get the width of the container we use the useRef() hook and the ref property. Kind simple.

Getting the width of the block to preview is kinda hacky at the moment. There is something funny when we try to get the DOM element. Although we are using the useLayoutEffect() hook, the dom isn't there yet meaning that when we try to pick it up through its clientId (using a dom/util function) it returns null.
First hack: setTimeout(). Wrapping the code into this function we can get the DOM element. I'd like to think that we can get a better solution, digging the reason why it happens. It seems to be related to the <BlockEditorProvider /> block. I've followed advice from @youknowriad, creating a new component to wrap the <BlockList /> but didn't work either. Maybe I'm missing something.

Another relevant change that I'm introducing here is using a CSS class to identify what part(elements) of the Block we want to visualize. AFAIK, This is completely needed since we don't have any other way to detect the exact part of the component that we want.

Although the getBlockDOMNode() returns the DOM Element of the block container, generally it doesn't match which what we'd like to visualize. And we can't generalize among all blocks saying ... just pick the first child of its children, or something like that.
Adding this new .wp-block-preview-container to those elements of the blocks, we can run a query selection easily. For this, I've added the getClockPreviewContainerDOMNode() function.
It means that we need to explicitly add this class the blocks that can be previewed. This PR adds the class to the table, button and pullquote component. While this seems to be complicated, it could also be considered one that allows us to easily define which elements we want to visualize from the block.

Finally, once we have the container width and the block with, the rest is a matter of simple calculation.

How to test

• create a post with a table, pullquote and/or a button.
• check how looks the preview in the different locations: Sidebar, Switcher and the Full Preview Popover.

Status

Pretty sure there are a lot of things to improve/change and at the end, I'm not 100% confident about this approach neither.

[youknowriad]

Let's add a comment to explain why we need the setTimeout (the block list being rendered async..)

[getdave]

It's pretty grim and I felt bad when I added this in my original PR. Is there no way to detect the rendered event?

[youknowriad]

The solution I proposed (see the PR comment) solve some of it but I think the block list is rendered twice. First at init with an empty block list, and then a second time with the full block list. that's because of how BlockEditorProvider works. (init on mount). I think that's the main issue here. So when first rendered, the block list is empty.

[getdave]

Is there no way of propagating the change of state within BlockEditorProvider from "empty" to "I have some blocks" via a callback or something?

[getdave]

Great work on exploring this route again. You made some improvements over my original version of this. However I still think there is a fundamental flaw that is outside of your (our) control namely that we cannot reliably target the DOM element which represents the visual width of the Block.

See #16113 (comment)

[retrofox]

If we remove the idea behind of querying the element to preview I think it won't work at least in the way it was initially thought.

For instance, the <Button /> childeNode represents the following:

While the element that we use to compute the scale is the next one:

[getdave]

If we remove the idea behind of querying the element to preview I think it won't work at least in the way it was initially thought.

I don't see any alternative but to remove it. Sorry 😢

I fully understand the problem (I've worked on it all week 😄 ) but it isn't a problem we can solve in this way.

We've hit that roadblock already on #1611. We cannot control or know in advance how the DOM of Blocks will be created.

The best we can do is Riad's suggestion of firstChild which is ok, but will never be perfect.

[youknowriad]

For instance, the childeNode represents the following:

I think for the button we can solve this by making that container "div" take the size of its content. (especially for the "unselected" state)

[retrofox]

For instance, the childeNode represents the following:
I think for the button we can solve this by making that container "div" take the size of its content. (especially for the "unselected" state)

The best we can do is Riad's suggestion of firstChild which is ok, but will never be perfect.

But that's the problem, Raid. We make that assumption for the <Block /> element, but for the <Table /> or <Pullquote /> we should pick up the <figure> element. There isn't consistency in terms of the tree of a Block, which is great but not useful for this purpose.

[youknowriad]

I think there's two things. The fact that the wrapper of the button doesn't take its container's size can be considered a bug IMO because that's not how the frontend looks and the editor should match the frontend for blocks.

The other aspect here is that depending on the content of the block, the preview might not look great. (Say you type just a few words in a quote compared to a full line text). For this case, a solution (that is needed elsewhere as well) is to add a new API to blocks to be able to define "an example content" instead of the content shown in the block while opening the block switcher. (that should be a separate PR though)

[youknowriad]

Actually, I just noticed that there's a full-width div for the button block in frontend too. you can argue that in that case, it's "normal" that the button block shows up as very small because its content is the whole div (what if it has a background image defined by a theme for instance, as silly as it is, it's part of the content).

This is to say IMO, we should tweak the button block to make its container take the size of its content in both editor and frontend.

[obenland]

The "Build artifacts" test keeps failing, not sure if that is something that's caused by this PR?

[youknowriad]

@obenland That's one of two things npm run docs:build (most likely to update the docs). or npm install to update the lock file.

Should be addressed now

[youknowriad]

What a team effort 🎉

[obenland]

Thank you SO much for all your help!

[shaunandrews]

💋

[jasmussen]

HOOLY wow. 👏👏👏

[getdave]

👏 👏 👏 👏

[talldan]

Is display: table; the only way to solve this? It seems like a bit of a hack that'll make life a lot harder in the long run.

[aduth]

I'm not sure if it was introduced here, but while the preview shows well in most contexts, in the block transform menu, I see horizontal scroll:

From some inspection, it seems to be because of the negative offsets from pseudo-elements surrounding the block in the block list:

gutenberg/packages/block-editor/src/components/block-list/style.scss

Lines 1120 to 1122 in be671ea

	left: -$block-padding * 2;
	position: absolute;
	right: -$block-padding * 2;

I'd think that ideally, we could have some concept of a "read-only" block list rendering, since these previews have no use for all of the extra control elements of a block.

But I comment here because it seems like you had to deal with this anyways. Maybe something we can be addressing with overflow: hidden ?

(Aside: I find it helps to use the "Show Scroll Bars: Always" option in macOS, to help discover these sorts of issues: https://cloudup.com/cqF641QROEe)

[youknowriad]

I don't have a good answer here, This was a very complex PR and I know that it can be tricky to get right on all situations.

read-only mode or preview mode

I see this mentioned over and over and I think we'll probably need that for several things (previews and also some special FSE mode where some blocks are "enabled" while others are not)

negative left/right

This looks specific to the hover and selected styles, so yeah if we can move this out of the flow somehow (overflow: hidden maybe but I'd be very cautious), it could work or just remove the selected/hover styles entirely in preview.

[retrofox]

👋 Honestly, I don't remember exactly the purposes of introducing these resets here. As Riad mentioned, it's a very complex PR and any modification can affect other instances where the preview is being used. AMost of these resets are usually an attempt to make cross-theme support.

read-only, view, etc. have been talked as well. I thought that even we could remove all elements which are not needed just for the preview (appender, drop-zone, etc) in order to make the preview process more efficient.