Add Support to Insert Existing Reusable Blocks from the Editor

[maxme]

Add Support to Insert Existing Reusable Blocks from the Editor.

• This requires the editor to fetch reusable block info from and API endpoint: /wp/v2/sites/{siteId}/blocks/
• Add new items to the block inserter.
• Inserter button will create a new core/block referencing the reusable block id.

[fluiddot]

@iamthomasbishop could you help me with the designs for this issue? Thanks!

[iamthomasbishop]

@fluiddot Hey there! Apologies for the delay on design direction. I didn't expect to be working on this so soon, but I do already have some notes/sketches/designs from previous explorations, so I should be able to provide something today or tomorrow. I have a lot of ideas for the inserter as a whole that are relevant to this work, but before I go too crazy I have a couple of questions I'd like to clear up in terms of scope -- @maxme I think you'll be in the best position to answer these, but @fluiddot obviously feel free to chime in as well.

• It seems that the scope of this work is only to provide an entry point inside the inserter. Is that correct, or will there be other tasks (as part of this chunk of work) that are relevant to the reusable blocks flow, such as enabling users to edit the blocks once they're inserted, searching in the inserter for reusable blocks, etc?
• Related to ☝️, it's also unclear to me is whether we will support reusable blocks as editable "wrappers" (like the Group block), or simply display them on the editor as 'unsupported'?

If the scope is simply "show users' existing reusable blocks in the inserter" then I already have a pretty good idea of how I think we should approach this. But if we are expecting to expand the scope, I might alter the design direction/proposal slightly. For now, I'll assume the narrowest scope and share some notes and designs either later today or tomorrow morning (UTC-5).

[fluiddot]

Hello @iamthomasbishop! Thank you very much for the response.

From my understanding of the issue, the scope is limited to only provide an entry point in the inserter to the reusable blocks, so there's no plan yet to add logic for managing them.
My idea is to implement something similar to what we have in the web version:

Regarding the support of reusable blocks as editable, I'm not sure about it, my impression is that this issue doesn't cover it neither, is this right @maxme?

[maxme]

Regarding the support of reusable blocks as editable, I'm not sure about it, my impression is that this issue doesn't cover it neither, is this right @maxme?

This is right, it's out of the scope of this ticket.

will there be other tasks (as part of this chunk of work) that are relevant to the reusable blocks flow, such as enabling users to edit the blocks once they're inserted,

We should lists all these tasks under this epic ticket #2497. I'll create a new ticket about editing existing reusable blocks and a second one for managing them, then add them both to the epic.

searching in the inserter for reusable blocks

This will come with some tweaks to our inserter instead, there is a ticket for that: #2570

[iamthomasbishop]

Ok, thanks for clarifying @maxme @fluiddot 😄 I think this is pretty straight forward then. We can probably utilize our Segmented Control component to separate reusable blocks from standard blocks. I put together 2 quick prototypes of what this would look like -- one with the Segmented Control on the top of the sheet and the other with the control at the bottom.

Gifs

Control on top	Control on bottom

Prototypes

• Control on top
• Control on bottom

Feedback

I'd like to hear feedback on the following:

• Positioning: what do you think are the pros and cons of each approach? (I have my list already, but I'd like to hear what others think 😄 )
• Control width: do you prefer the "natural" width for the control (only wide enough to house the labels of the control itself) or the full-width control (each segment is ~50% of the area)?
• I thought about adding icons to the segments, which would look like this (ignore the wrong icon on the Reusable segment). Do you prefer the segments that have icons or text-label only?

Notes

• The Segmented Control would only be displayed if the user already has reusable blocks
• This interaction would rely on the cross-sheet transformations (for reference, look at color settings on the Buttons block)
• These mocks use the iOS design for the control -- here is the Android version

[fluiddot]

Really cool design @iamthomasbishop it's very clean, regarding the feedback:

Positioning: what do you think are the pros and cons of each approach? (I have my list already, but I'd like to hear what others think 😄 )

It's tricky to decide this kind of things 😄 , here goes my pros/cons of each:

Control on top:

Pros:

• From a structural point of view makes more sense because acts as the header of the content.
• Users expect this kind of navigation between tabs when a segmented control is presented.

Cons:

• The size of the sheet changes when navigating, moving the segmented control position, this could be annoying if you want to navigate multiple times.

Control on bottom:

Pros:

• It's easy to navigate between tabs.

Cons:

• The gesture for scrolling is from bottom to top so the segmented control could interfere.

In my opinion the best would the Control on top option because the cons are less likely to happen than the ones from the bottom option, what do you think?

Control width: do you prefer the "natural" width for the control (only wide enough to house the labels of the control itself) or the full-width control (each segment is ~50% of the area)?

I prefer "natural", it could make the header to look a bit empty but if we add the icons I think it could look cool.

I thought about adding icons to the segments, which would look like this (ignore the wrong icon on the Reusable segment). Do you prefer the segments that have icons or text-label only?

I think icons could emphasize the segments and since we only have 2 there's room for adding them.

[iamthomasbishop]

@fluiddot That's pretty close to my list of pros and cons, and I am also leaning towards top-positioned because while the control does move, this isn't an interaction that should happen super frequently -- or at least not enough that it's going to cause an uproar -- and it is more discoverable than the bottom-positioned alternative.

I prefer "natural", it could make the header to look a bit empty but if we add the icons I think it could look cool.

Agreed that natural probably will feel best because it allows the content to breathe a bit and as a result the control is more distinct. Let's start with just text for labels because I think some translations may give us longer labels. For example, here are some examples of text-label vs. with-icon, using English vs. German:

Note: at some point we will probably add a third segment ("patterns"), so we will need some wiggle room. I don't foresee us adding additional segments beyond that -- but if we do, we'd want to consider using scrolling tabs or something similar.

[fluiddot]

@fluiddot That's pretty close to my list of pros and cons, and I am also leaning towards top-positioned because while the control does move, this isn't an interaction that should happen super frequently -- or at least not enough that it's going to cause an uproar -- and it is more discoverable than the bottom-positioned alternative.

Yeah I agree, ok let's go with the "Control on top" option 👍

Agreed that natural probably will feel best because it allows the content to breathe a bit and as a result the control is more distinct. Let's start with just text for labels because I think some translations may give us longer labels. For example, here are some examples of text-label vs. with-icon, using English vs. German.

Good point, I think it's a good idea to start with only the labels and as you commented, overall it's going to be safer do it this way for avoiding potential text cut off issues 👍

Note: at some point we will probably add a third segment ("patterns"), so we will need some wiggle room. I don't foresee us adding additional segments beyond that -- but if we do, we'd want to consider using scrolling tabs or something similar.

For now if you agree I'm not gonna take this into account for this issue but of course, in the future that would be a good solution in case we want to add more tabs.

[iamthomasbishop]

For now if you agree I'm not gonna take this into account for this issue

Most definitely, that's a future project 😄

@fluiddot I think we should be able to utilize the Segmented Control component (RN) as-is, and I don't think we're introducing any new things, but if there's anything that I'm missing from a design perspective (or if you have any questions regarding flow, function, etc.) let me know and I'll be happy to pull that together!

[maxme]

Thank you Thomas for the designs!

Note: at some point we will probably add a third segment ("patterns"),

I wonder if patterns will replace reusable block some day, so we might not have this problem in the future.

[iamthomasbishop]

I wonder if patterns will replace reusable block some day, so we might not have this problem in the future.

I think there has been discussion on the core side, but I don't know has come of that discussion. My guess is reusable blocks will stick around in some form, because it is a bit different from standard Patterns — reusable blocks are a clever way of allowing users to group and re-use any arrangement of blocks — almost like "custom"/user-defined patterns. So I think they'll stick around for a while, although personally I think we could find a better name for the concept, but I digress 😄

[fluiddot]

I've got a question about the behavior when navigating tabs.
The way I implemented it doesn't preserve the previous scroll position of the lists when navigating, this means (as explained better in the GIF) that if you scroll down the block list, navigate to the Reusable blocks tab and go back again to the block list it will start at the top. What do you think?

[iamthomasbishop]

What do you think?

@fluiddot I would prefer that we preserve the scroll-position, but I wouldn't necessarily call it a deal-breaker. I think we had a similar discussion when working on the color picker UX where we wanted to preserve scroll position on segment-change, so maybe there's some knowledge to be gained from that implementation.

[fluiddot]

What do you think?

@fluiddot I would prefer that we preserve the scroll-position, but I wouldn't necessarily call it a deal-breaker. I think we had a similar discussion when working on the color picker UX where we wanted to preserve scroll position on segment-change, so maybe there's some knowledge to be gained from that implementation.

Ok sorry but for now I'm going to keep it without preserving the scroll-position however it would be a good improvement for a second iteration.

[iamthomasbishop]

for now I'm going to keep it without preserving the scroll-position however it would be a good improvement for a second iteration.

That's fine, we can save that refinement for an iteration. Would you mind creating a separate ticket for that just so we have it documented?

[fluiddot]

for now I'm going to keep it without preserving the scroll-position however it would be a good improvement for a second iteration.

That's fine, we can save that refinement for an iteration. Would you mind creating a separate ticket for that just so we have it documented?

Sorry for the delay, I've just created an issue related to this.

[fluiddot]

Here I'm resuming my work so far in this issue:

Split the issue in 2 parts

First of all, I decided to split this issue into 2 parts, the first part adds support for Reusable blocks and the second one adds Reusable blocks to the inserter menu. I did it this way because I wanted to keep the PRs as small as possible as well as I didn't want to mix both changes.

The first part to be honest was unexpected when I began to work on this but nevertheless was required for supporting Reusable blocks. Related to this, the support for now is limited to only the preview of the block, edition is going to be implemented in a different issue.

Here are the different PRs related to the issue:

First part - Add support Reusable blocks
Gutenberg PR -> WordPress/gutenberg#25265
Gutenberg-mobile PR -> #2627

Second part - Add Reusable blocks to the inserter menu
Gutenberg PR -> WordPress/gutenberg#25383
Gutenberg-mobile PR -> #2644

Pending things to do

• Regarding the first part, there's a bug that should be reviewed related to a loading glitch.
• Do a final review of the PR and apply fixes from potential feedback.
• The second PR is not yet reviewed although the changes are ready so first thing would be to review it and apply fixes from potential feedback.

Related issues

During development I spotted some issues that I opened in Gutenberg repository.

• Support unbounded queries
• Preserve scroll-position in inserter menu tabs

[fluiddot]

This task is completed although it won't be displayed to users until the reusable block is enabled in this PR.