Reusable block issues re: detach, edit and delete.

[amandablum]

I know there are 40 issues re this and I've looked at them all, but I think there are little parts of this conversation in each and unless this conversation has taken place, I think it needs to. I've mentioned this in a few places, but while I think reusable blocks are essential to Gutenberg working as a concept, the flow of them and lexicon of them as global blocks vs this block instance vs this block instance content is really unclear, confusing and potentially screw-upable by a user.
In particular, the concept of "detach". Even after playing with these blocks for a week or two, I'm confused about detach.

1. create a block. make it reusable. lets call this instance 1 of block A.
2. reinsert reusable block A. now this is instance 2 of block A.
3. Click to edit instance 2 of block A. Am i editing instance 1 and 2? or just 2? What if I edit instance 1? Same question.
4. Does detaching mean that I am now only editing instance 2? What if I want to keep ALL the settings, the style, etc but just change the content? How do I do that? <- isn't this literally the point of reusable blocks? otherwise its duplicating a block, that is not the definition of reusable.
5. Where would I go if I wanted to edit all instances of a block? like I'd given them a dropcap, but now I realize dropcaps are douchey and want to change that on all instances of the block. Do I need to go back to instance 1 or can I edit instance 36 so long as its not detached or would I need to edit literally every single instance?
6. How does a user know on any given instance the difference between edit this block, this block instance or this block instance content?
7. What if I want to delete the block? How does a user know the difference between delete this instance of block and delete this block?

I reference in #3936 the need for a lexicon that distinguishes the hierarchy of this content, this block and this block type. I do not think this can or should be done all via the inserter. i think we can and should keep all functions related to THIS block instance and THIS block instance content limited to the inserter and shouldn't let clients potentially screw up all instances of a block from the inserter. All global block issues should move to their own page in admin. Either under settings or if the "gutenberg" menu item is to stay or become a "blocks" menu. I think this also has great extensible opportunity for plugins as I outline in the above noted thread.

[amandablum]

I've been using reusable blocks for the last 2 weeks on a build, so this is an issue i come up against repeatedly. Am I genuinely the only person concerned about this?

[mickmel]

To answer those to the best of my ability (and testing):

Click to edit instance 2 of block A. Am i editing instance 1 and 2? or just 2? What if I edit instance 1? Same question.

If you edit any instance of a reusable block, it will edit all instances of it.

Does detaching mean that I am now only editing instance 2?

Correct

What if I want to keep ALL the settings, the style, etc but just change the content? How do I do that isn't this literally the point of reusable blocks? otherwise its duplicating a block, that is not the definition of reusable.

Just insert the reusable block (to bring in all of the style) and then detach it.

Where would I go if I wanted to edit all instances of a block? like I'd given them a dropcap, but now I realize dropcaps are douchey and want to change that on all instances of the block. Do I need to go back to instance 1 or can I edit instance 36 so long as its not detached or would I need to edit literally every single instance?

You can edit any instance of it (that you didn't "detach") and all will be updated to remove the filthy dropcap.

How does a user know on any given instance the difference between edit this block, this block instance or this block instance content?

Good question. It's hard to know what users will think, but adding more context/text to help explain things is always wise.

What if I want to delete the block? How does a user know the difference between delete this instance of block and delete this block?

I think that is pretty clear. If you click "remove", it goes away. If you click "Delete Reusable Block", it gives you a warning about what's going to happen.

[karmatosed]

As we have one thing merged from this, what else can we pull out as real action points? Or have we pulled out everything we can? It would be great if you can consider this @amandablum and we can look to get issues made even, closing this one.

[amandablum]

@karmatosed which issue was merged? Honestly I disagreed with most of what @mickmel said. I disagree that its pretty clear. I actually think its not at all clear, hence writing the post.

Reusable blocks should be purposed like styles. You're setting up a style to be utilized throughout the site. The content may change, but the format and style of the block will not. Which means you need to go somewhere else to edit the parent block, editing each instance would not result in changing the parent block. I understand you can detach, but I don't know what the point of detaching is. You lose the styles and content, so you might as well have started from zero.

[mickmel]

Honestly I disagreed with most of what @mickmel said. I disagree that its pretty clear.

You can certainly disagree that things are clear enough (and increased clarity is always a good goal), but how did you disagree with "most of what" I said? It was just explanations. Were some of them incorrect?

I understand you can detach, but I don't know what the point of detaching is. You lose the styles and content, so you might as well have started from zero.

When you detach, you shouldn't lose any style or content. The block looks identical to how it was when it was attached, but now you can change it freely without affecting the master copy. If content or style disappears when you detach, there's a bug somewhere.

[amandablum]

Somewhere, between reusable blocks in their native state and detached needs to be a way to use the reusable block, change the content and keep all the styles. So that when you change the styles on the parent block, it changes all the child blocks. But I can't find much use case for consistently reusing the same block w the same content all the time.

I suggest that you should always be able to change the content of a resuable block instance without changing the parent block, without detaching. Then there would need to be a way to edit the parent block, as well.

[amandablum]

Issue: Make Reusable Block instance content changeable without affecting parent block or allow users to choose between detaching content and/or styles.

[jasmussen]

Good discussion with lots of answers.

Reusable blocks (now "Shared blocks") have been in Gutenberg for a bit now. Creating and optionally detaching them are a way authors to create a custom block without having to write code.

The block being described in this issue is not yet in Gutenberg — but it could be revisited in the future. Given that we're trying to get Gutenberg Phase 1 to the finish line, however, I'm going to close this for now. We should never be afraid to close tickets, because they can be revisited or reopened if need be.

[DeanE1]

It appears this issue is back. I don't see a detach option but I do see "convert to regular block" option. When selecting convert to regular block though, all style formatting and content gets erased and I'm left with two columns.

The block was a simple block I created with two columns, a pros and cons heading, one for each column and a bullet list in each column. Trying to edit the content before converting was editing all instances of the reusable block, which I believe to be a "feature" which is fine. There then should be a way to detach it from the original block which I believe is the intention of the "convert to regular block" option but this does not work.

[chrisvanpatten]

@DeanE1 that sounds like a bug, which you might want to report separately. Were you using the native Columns (Beta) Block?

[DeanE1]

Yes, it was the add columns (beta) option.