Open Offcanvas List View appender popup within sidebar

[getdave]

Currently the popover for the appender in the offcanvas sidebar opens in the block canvas. Rather it should open relative to the sidebar itself.

---

This looks like a good first step. Ideally we'd open the appender in the sidebar, but we can do that in a followup.

Originally posted by @scruffian in #45947 (review)

[getdave]

Research

• <Inserter> effectively has two modes:
  • render an icon which when clicked will show a popover containing various blocks you can insert
  • render an icon which when clicked auto-inserts a block (deferring all subsequent interactions to whatever the block does when selected).

gutenberg/packages/block-editor/src/components/inserter/index.js

Lines 186 to 205 in 8e93b93

	if ( hasSingleBlockType || directInsertBlock ) {
	return this.renderToggle( { onToggle: insertOnlyAllowedBlock } );
	}
	return (
	<Dropdown
	className="block-editor-inserter"
	contentClassName={ classnames(
	'block-editor-inserter__popover',
	{ 'is-quick': isQuick }
	) }
	position={ position }
	onToggle={ this.onToggle }
	expandOnMobile
	headerTitle={ __( 'Add a block' ) }
	renderToggle={ this.renderToggle }
	renderContent={ this.renderContent }
	onClose={ onSelectOrClose }
	/>
	);

• The current behaviour of the Nav block defaults to the 2nd option - directly inserting core/navigation-link blocks.
• We can see that it is directInsertBlock being truthy that causes insertOnlyAllowedBlock to be called as onToggle by the rendered toggle component.
  

  gutenberg/packages/block-editor/src/components/inserter/index.js

  Lines 186 to 188 in 8e93b93

  	if ( hasSingleBlockType || directInsertBlock ) {
  	return this.renderToggle( { onToggle: insertOnlyAllowedBlock } );
  	}

• the defaultToogleComponent will call insertOnlyAllowedBlock as onToggle
  

  gutenberg/packages/block-editor/src/components/inserter/index.js

  Line 254 in 8e93b93

  insertOnlyAllowedBlock() {

• directInsertBlock is provided by withSelect and comes from call to __experimentalGetDirectInsertBlock
  

  gutenberg/packages/block-editor/src/store/selectors.js

  Line 2196 in 8e93b93

  export const __experimentalGetDirectInsertBlock = createSelector(

• setting of the values needed for experimentalGetDirectInsertBlock appears to come from the inner blocks of the Nav block -

  gutenberg/packages/block-library/src/navigation/edit/inner-blocks.js

  Lines 116 to 117 in 8e93b93

  	__experimentalDefaultBlock: DEFAULT_BLOCK,
  	__experimentalDirectInsert: shouldDirectInsert,

• onSelectOrClose is called after the directly inserted block is inserted
  

  gutenberg/packages/block-editor/src/components/inserter/index.js

  Lines 375 to 377 in 8e93b93

  	if ( onSelectOrClose ) {
  	onSelectOrClose();
  	}

• passing false to the 4th arg of insertBlock (i.e. updateSelection) will cause the selection not to be updated 🥳
  

  gutenberg/packages/block-editor/src/components/inserter/index.js

  Line 373 in 8e93b93

  insertBlock( blockToInsert, getInsertionIndex(), rootClientId );

• if we want to stop blocks inserted from the full inserter menu from becoming "selected" then we need to be able to set the 4th argument of insertBlock here:
  

  gutenberg/packages/block-editor/src/components/inserter/hooks/use-insertion-point.js

  Lines 107 to 114 in 3258483

  	insertBlocks(
  	blocks,
  	destinationIndex,
  	destinationRootClientId,
  	true,
  	shouldFocusBlock || shouldForceFocusBlock ? 0 : null,
  	meta
  	);

Challenges

• When inserter is clicked the new block is auto inserted thereby triggering that block to be selected. This causes the sidebar to show the <InspectorControls> for the newly added block. We can avoid this by passing false as the 4th argument to the insertBlcok inside of <Inserter> (see above).
• if we do the above, then the block is no longer selected (that's good) but now because of that the <LinkControl> interface does not display because the UI comes from the core/navigation-link block itself when it is selected
• we now need to find a way of displaying a LinkControl UI in the offcanvas which corresponds to the freshly inserted block in the canvas

[getdave]

Allowing the direct insertion of core/navigation-link blocks provides an additional requirement of displaying a Link UI within the offcanvas that mirrors (and interacts with) the one provided by the block's edit definition. That's going to open up a world of potential errors and inconsistencies.

An alternative might be simply to allow the inserter to bring up the standard inserter menu pre-filtered to blocks that are allowed in the Nav block. Here's an example of that:

Screen.Capture.on.2022-11-23.at.16-10-39.mp4

It's not the best experience in terms of editing the details of a Custom Link. For that we'd need:

• ability to click to edit the text of the link via the list view (for that I could potentially draw on Custom labelling/naming of blocks in List View #42605).
• ability to easily configure the link via the block inspector controls

If that isn't tenable then the only alternative is to have the offcanvas render a <LinkControl> which is configured to interact with the core/navigation-link in the canvas. That's not going to be easy and it will introduce a lot of duplication but it might be possible.

Thoughts appreciated.

[draganescu]

The research and the demo are awesome @getdave 👍🏻 👍🏻 👍🏻

I think that

• we need to keep direct insert in the canvas, but not in the off canvas
• we need to treat adding items like a small two step wizard
  1. Add the type of link or block
  2. Get to a UI to customize it

I think adding blocks in their not setup state is confusing and the next steps to set them up are not obvious.

Allowing the direct insertion of core/navigation-link blocks provides an additional requirement of displaying a Link UI within the offcanvas that mirrors (and interacts with) the one provided by the block's edit definition. That's going to open up a world of potential errors and inconsistencies.

• What are one or two of the potential errors and inconsistencies you foresee?
• Can we have a special LinkUI just for this off canvas use, for now? Maybe we don't need to add more stuff in LinkUI which is mega bloated anyway.
• Why mirror or interact? Just show the offcanvas LinkUI once a link type is chosen, replacing the inserter on the screen. Definitely the block does not show any LinkUI in the canvas.

[SaxonF]

Looking good @getdave !

Not much feedback to give. Couple of points:

Dialog should be the same one we use for adding links on canvas.

Is there a standard for how these dialog's should be positioned? I remember seeing a recent exploration that used a similar pattern (exposing advanced settings in inspector via dialog). For example in Figma it's always to the side of the inspector, overlapping slightly.

[getdave]

Dialog should be the same one we use for adding links on canvas.

👍 I expect that will be the tricky bit. I'm going to do more experimenting today.

Is there a standard for how these dialog's should be positioned?

The component relies on lower level @wordpress/components which have a positioning algorithm which is used across all "popover" type things. Currently it's anchored to the toggle trigger and then you can give it guidance about where you (ideally) want it positioned. Currently it's set to bottom right (I think).

[getdave]

What are one or two of the potential errors and inconsistencies you foresee?

@draganescu The issue is that the dialog shown when you add a new menu item in the canvas is a <LinkControl>. That control comes directly from the edit.js of the core/navigation-link block and is triggered when that block receives focus or is inserted.

At first I thought I would just re-position the link UI from the block so it's over next to the offcanvas. However, we cannot do that because to get that UI to appear we need to select the block. That means the Inspector Controls update to reflect the core/navigation-link block and we loose the offcanvas list view provided by the core/navigation block.

I'm now going to experiment with rendering a separate <LinkControl> in the offcanvas which will be triggered when a core/navigation-link is inserted. This control will need to set attributes on the core/navigation-link and will be basically a copy/paste of the exact same thing from that block's edit.js.

Does that make sense?

[getdave]

We discussed this away from Github. The current feeling is:

• canvas and offcanvas should match each others' interaction models
• we should retain the existing auto-insert (navigation link) block when the inserter is clicked
• the block should not be selected when inserted from offcanvas - this allows offcanvas to remain focused whilst creating a menu
• for simple links the Link UI should display in the offcanvas when the block is inserted.
• in the future we might want to move towards a different interaction model whereby clicking the inserter does not auto-insert a block but rather brings up the Link UI. Once a link is selected only then is a block created. This will require amending the Nav Link block code as well so is likely a nice-to-have and outside the scope of the immediate effort here.

[draganescu]

experiment with rendering a separate in the offcanvas [...]
Does that make sense?

Absolutely @getdave, it's similar to me asking "Can we have a special LinkUI just for this off canvas use, for now?", so yes that sounds like a good plan. For now the off canvas editor component is both experimental and exclusive to the navigation block. As we're trying to validate the interaction first, and learn from that, it's OK if some items are copied over or if less than ideal couplings appear. For now :)