Comment Template: Consider using block placeholders when editing a template with no page context

[gziolo]

What problem does this address?

At the moment we show a list of the latest comments for the Comments Query Loop block when there is no post selected during editing the site. However, for all other theme blocks, we show placeholders in the same view:

I found out that the current approach aligns with how the Query Loop block works, for example when editing in the archive template:

Aside: Please note that the numbers used in the Pagination block don't match with the list of posts rendered (there is a single post only).

My biggest concern here is that when there is a ton of comments that include threads the Comments Query Loop block might dominate the template editing view. It also creates this disjointed experience where the data used doesn't necessarily is going to be present on the frontend in the same form.

What is your proposed solution?

Let's consider using block placeholders for nested blocks used inside the Comments Query Loop.

[gziolo]

The same question applies to the Query Loop block. @ntsekouras, do you have some insights why we landed on the current approach?

[ntsekouras]

The same question applies to the Query Loop block. @ntsekouras, do you have some insights why we landed on the current approach?

This is related to the context detection issue we have.

We need to find a way to detect the context a Query block 'lives' and handle any settings needed appropriately. By context I mean FSE context (site-editor) or a page/post (post-editor). Moreover is valuable to even know the kind of template we are on FSE context (related: #29438) [....]

So what happens now without the context detection is that we don't have a way for showing the proper results when we inherit the global query and we still need a way to customize this block. I think there was an issue about having a way to use an isolated view for editing the block in these cases, but I couldn't find it now.

To sum up probably a good approach in cases we don't know the context, would be to have an isolated editing view/UX to customize the block without caring about actual data. That could be showing 'dummy data' as well and could even start by showing a placeholder at first and have a way to edit this..

[gziolo]

That could be showing 'dummy data' as well and could even start by showing a placeholder at first and have a way to edit this..

At the moment we use block names as placeholders for other blocks in the same template so it would make sense to start with that. The difference here for loop blocks is that they need to repeat the same set of blocks a number of times and that is also another decision we need to make unless we are able to use a setting for the default number of items. In the case of comments, we would rather have to ignore comment replies in the default view.

[ntsekouras]

At the moment we use block names as placeholders for other blocks in the same template so it would make sense to start with that.

The difference is that we do need a way to edit the innerBlocks of the query blocks, so this wouldn't work here.

[annezazu]

I think there was an issue about having a way to use an isolated view for editing the block in these cases, but I couldn't find it now.

Perhaps this issue? #26190 :)

[ntsekouras]

Perhaps this issue? #26190 :)

Yes! That's the one I was referring to, thanks Anne!

[gziolo]

Perhaps this issue? #26190 :)

Yes! That's the one I was referring to, thanks Anne!

Thank you for linking the related issue!

In some cases, when there are too many posts rendered in the view, someone editing it might want to focus just on the inner blocks template in a singular view.

That part of the issue applies to the Comments Query Loop block, too. However, my biggest concern was the use case where users edit the Single Post template and they see placeholders (block names) for the blocks like:

• Post Content
• Post Date
• Post Author
• Post Terms

It happens because there is no post id selected in the editor so there is no data to pull in the view. Now, for the Comments Query Loop block, we display real data by querying all available comments on the website. If there would be no comments available then we would show a message that no results were found which would prevent any customizations. So there are several flaws in the current approach:

• No proper UX fallback when no comments exist.
• Suboptimal handling when there are hundreds of comments on the site.
• Placeholders used in some blocks and random real data in other blocks.

[ntsekouras]

It happens because there is no post id selected in the editor so there is no data to pull in the view.

I'm wondering if we can find a way to utilize fake examples for this isolated editing or retrieve just the first available post/comment to get that data.

There is also the related performance issue of rendering block patterns with such blocks. Right now even if we have the needed prop to render a preview it can be really bad, depending on the inner blocks and the number of entities we use(perPage in Queries). What if we could use that fake example for both cases?

I'm just spitballing here, I don't have a specific solution for this yet.

[SantosGuillamot]

@c4rl0sbr4v0 If I am not mistaken this issue was addressed in this Pull Request right? Should we close it?

[cbravobernal]

Yes! We can close it!