Allow reusable blocks to be edited in the editor

[maxme]

Description

Inserted reusable blocks core/block should be editable and convertible to regular blocks.

On the web, when clicking on a reusable block a bar on the top ow the block appears and let the user:

• Convert to regular blocks.
• Edit. After clicking on the "Edit" button, the grouped blocks are editable, and a "Save" button appears. The block name is also made editable. See the screenshots below:

Reusable block selected	Reusable block editing

Implementation

Edit content

We're going to use the floating toolbar for providing the actions for editing a reusable block. We'll present different actions depending on the editing state:

• Block unselected (no actions will be displayed)
• Block selected
  • Editing disabled
    • Edit: Enables the editing mode of the block. If the editing mode is not enabled, the block should be disabled.
  • Editing enabled
    • Discard: Discards the changes that have been applied to the block and disables the editing mode.
    • Save: Save the changes that have been applied to the block and disables the editing mode. Since this action requires us to make a request to the site, we should provide a loading indicator while the request is in progress.

In relation to adding items to the floating toolbar, the best option would be to add the SlotFill component to allow blocks to add their own actions. We could do something similar to what we do for the toolbar buttons or the inspector control.

Design

Edit button	Discard/save buttons

Edit name

Add Edit Name to the inspector controls to allow the user to modify it. As with the content, the user has explicitly to save the changes.

The name is part of the content so when the value is modified we should enable the editing mode. The discard action should revert any change made in the name and save action as with the rest of the content, it should save the name value.

Design

Convert to regular blocks

Similar to the Group block that also has this action, a toolbar button will be added to execute the conversion. We should be careful to verify if the undo/redo functionality works for this action.

As an optional improvement, we would show a notice message when the action is executed.

Caveats

Undo/redo

This functionality should work similar to editing other blocks, however since we have the editing mode for reusable blocks, we should enable/disable that mode depending on the undo/redo action.

Auto-save

The content of the post is auto-saved automatically on every change but this doesn’t apply to the reusable blocks content. I tested on the web version and it’s not auto-saving it so probably this is a minor issue or even not necessary for this block.

Offline

Updating the content of reusable blocks requires network connection, if the device goes offline and the user tries to make an update we should display an error message and allow it to retry.

Multiple instances of the same block

Based on the web version, if there’re two instances of the same reusable block, the modifications should be applied on both.

Example

Potential bug: As you can see in the example, making changes produce visual glitches on the second instance.

[fluiddot]

👋 @iamthomasbishop

I'm starting to review the next step for the support of Reusable blocks and I'd like to know if you have any design input regarding the edition of this type of blocks.
Thanks!

[fluiddot]

After doing a spike on adding support for editing Reusable blocks, I found the following topics that should be reviewed.

Edit flow

Current flow

The current flow for editing a Reusable block in the web version is:

1. Click on the block
2. Click on Edit button
3. Edit the content and/or the title of the block
4. Click Save button

Web version - Current flow

reusable-block-edit-flow-web.mp4

New flow

However in the web version this flow has been changed recently, now the content can be changed without enabling the edit mode and the block is updated when publishing the post/page.

Example - New flow

reusable-block-edit-web-new-flow.mp4

As far as I checked, the app doesn't request the user to confirm the changes so if we implement this flow we would have to figure out how to something similar.

Implementation in the app (Mobile version)

It would be nice to have some design inputs here, @iamthomasbishop do you have any ideas regarding this?.

Here are the the items I identified that would require design changes:

Title

Here are some questions I noted after the review:

• Should we keep the title visible when selecting the block?
• What would be the best place to place the text field for editing it (same place or in the inspector controls)?

Additionally we should remove the lock and help icon as well as any other logic we had with the edition through UBE.

Update content

I realised the the Group block has a lot of similarities with Reusable blocks regarding edition. I did quick prototype implementing the original flow from the web version.

Mobile - Current web flow [Prototype]

reusable-block-edit-native.mp4

Convert to regular blocks action

We need to find a place for this action, maybe we could replicate the way the Group block does and place it in the toolbar.

Group block example

POST requests are not available in Gutenberg mobile

For now we only support GET requests but the edition requires POST requests for updating the Reusable blocks. We need to add this logic to the Gutenberg networking module to handle this type of requests.

[iamthomasbishop]

Hey @fluiddot — apologies for the delay. I started to sketch out some ideas for the editing UX for these last week but haven't had a chance to finish. I'll try to answer some of your questions now so I'm not blocking you on all of it 😄.

New flow

Thanks for sharing the updated flow, I had missed that! I don't think we'll easily be able to replicate the web's "new" approach (because we don't have the same type of pre-publish sheet that they have — we have a very minimized version of that and I don't think we want to add anything to it if avoidable. I also don't really love that there is no clear indication as to what you're editing, so my instinct is to continue on the course that we're going (at least roughly). I think there's probably a middle ground to be found, but I'll have to dissect the web a bit more and think about how it should inform our path.

Should we keep the title visible when selecting the block?

I think probably while that parent/wrapper is selected, yes. But beyond that will depend on what our interaction model looks like as a whole for reusable blocks.

What would be the best place to place the text field for editing it (same place or in the inspector controls)?

Probably best to have a text input on a bottomSheet (inspector controls), but this is another thing I'll think more about.

We need to find a place for this action, maybe we could replicate the way the Group block does and place it in the toolbar.

I would instead add this as an action in the overflow menu (•••).

I'll be back with more tomorrow! Thanks for your patience!

[fluiddot]

Thanks @iamthomasbishop for your input an answering the questions, I know you're quite busy so I really appreciate your help in this 😊 !

In the mean time, I'll apply some changes following your answers in the prototype version I'm currently working on, let me know if I can help you with anything else.

[fluiddot]

I've added a section about the implementation to the description of the issue, the idea is to provide all the needed context for implementing this feature.