Block List: Display inserter button after block on hover, focus

[aduth]

Related: #2743, #833

With an exploration of nested blocks pending (#2743), the usability of the global block inserter is being called into question. As an example, consider the case that the quote block allows nesting text or image blocks. If while focused within the quote text I decide to use the global inserter to insert an image block, would I expect it to (a) be inserted within the quote or (b) be inserted as a new top-level block after the quote? While the insertion point highlight helps, it is not shown until after the user has made the conscious decision to use the inserter (assuming they had already decided the effects of said insertion).

Proposal:

A separate task will be created to eliminate the global inserter.

We should first prepare for this by establishing an alternative behavior for inserting before/after/between blocks. When hovering or focusing a block, an inserter button should be made visible after that block to allow a new block to be inserted between it and the next.

Complications:

• An hover inserter should be shown prior to the first block. It is unclear how this could work with focus and tab order (maybe it doesn't)
• An inserter should always remain visible at the end of a post, so either the last block's hover inserter is not rendered or assumes the role of what currently exists as the always-visible inserter

cc @adambbecker (I am told you have explored this previously 😄 )

[BE-Webdesign]

This kinda of touches on some experiments I have done around block templates, and nested stuff. Here goes nothin':

What if part of the block type definition is insertable block types? Then our top level container of the editor's content can become a post block type. All of our current blocks would be registered as insertable blocks to this container block. Then since each block definition can have its own insertable block types, so we can have better control over what goes into each block. This also ties into the block template concept.

Each of our blocks has a default setting of sorts when initially inserted already, and our default post and page also feature an empty title block and paragraph block. The quote block's template could be a combination of a pagraph, and citation. The block template for each block type could become a way to define what should be present when a block is first created. This tree of blockTypes would be passed into createEditorInstance and it will figure out what to do from there. This way creating an instance of the editor is more about assembling what building blocks you want to use rather than a top down (hierarchichal structure) saying what can be used, that we currently have.

Advantages of this approach: it is a recursive and composable model, allowing for reuse of standard interactions like inserting, and moving blocks around. This would make the next step of page building in Gutenberg a more trivial task, as different components of each page could just be different compositions of our primitive blockTypes. Better server/client interop because the definitions of blocks are baked into themselves as just data.

Disadvantages: Work and time investment, might be a premature decision. Entirely dependent on performant and well structured support of nested blocks.

[aduth]

@BE-Webdesign Great ideas. I think relationships between types of blocks is a natural progression of block nesting, and complements both existing blocks (quotes, cover image) and site building more broadly (rows, columns). In fact, in my original notes from which I created this grouping of framework issues I also planned a few more to this effect, but I thought to wait until after #2743 to see how nesting would play out.

What's currently implemented as VisualEditorBlockList could become the reusable "container" you describe, responsible for a top-level post block rendering, and also the rendering of nested children within a block. I could imagine an edit rendering <BlockList /> to enable child blocks to be nested. Maybe it's on this component we describe the insertable types, e.g. <BlockList types={ 'core/text', /* ... */ } />. We could want the reverse as well ("Column" only insertable within "Row", not standalone). The behavior of these nested block lists would be more-or-less identical to what we already have at the top level.

[aduth]

Reopening since #2890 was reverted in #2929

[mtias]

This has been implemented.