Add a block when clicking a button in the "Add Block" popover

[ScopeyNZ]

338 implements an "Add Block" popover. When the various block types shown in this popover are clicked, a block needs to be added to the relevant elemental area.

A/Cs

• [x] Clicking on a block in the popover will add a block to the relevant elemental area
• [x] Block is already saved but unpublished
• [ ] Animations as specified by the designs are implemented

[ScopeyNZ]

@clarkepaul For accessibility do you think we should add an A/C to make the newly added block the next thing that you tab to?

[clarkepaul]

Tough one, you might want to be adding multiple blocks (one after the other). I'm thinking to remain within the popover, after selecting a new block. Happy to hear what others think. Agree it should be an AC though.

[clarkepaul]

Three options as I see it:

1. Close the popover, focus moves to the "Add" button
2. Close popover, focus moves to newly added block
3. Keep popover open, focus is on popover ready for another block to be added

I took at look at a few examples from others and they didn't really consider this, although clicking through the experience feels quite intuitive if you go to the new block as you mentioned @ScopeyNZ (opt. 3).

[ScopeyNZ]

the experience feels quite intuitive if you go to the new block as you mentioned @ScopeyNZ (opt. 3).

This was my initial thought. To be honest I didn't consider the idea of even leaving the popover open after clicking to add a block.

[ScopeyNZ]

@raissanorth has done a "part 1" PR at #404. There's still a something that needs to be addressed:

Clicking "Add block" in the designs has it just adding the block ready for in-line editing (with some fancy animations)

• @robbieaverill @NightJar @raissanorth How do you think this should be done? With a CreateBlock mutation that just takes the block type? A save would have a lot more options and block type is not one of those. Creating seems quite different. The mutation could include the location of the block, similar to the sortBlockMutation (because we have the in-line add button too) and look like:

mutation AddBlockMutation($blockType:Sting!, $afterBlockId:ID) {
    addBlock(
        Type: $blockType
        AfterBlockID: $afterBlockId
    ) {
        ID
        Title
        BlockSchema
        InlineEditable
        IsLiveVersion
        IsPublished
        Version
    }
}

• @clarkepaul @newleeland How should this work with non in-line editable blocks? Do you expect people to add, then click on the block for editing or should it take you straight to a "GridFieldDetailForm"?

[robbieaverill]

Sounds good to me. A custom mutation which takes in the block type makes sense to me. We can either push an optimistic update to the Apollo cache with the new block or refetch the blocks again in order to re-render the new one

[clarkepaul]

@ScopeyNZ For complex blocks like Forms, I think the user can add the block to the page first, then they need to click on the block to navigate away to edit it.

[brynwhyman]

Adding a file/banner block that's been created via the GridFeildDetailForm that's empty currently wont be able to be expanded. This could come up as part of this ticket.

https://github.com/silverstripe/silverstripe-elemental-bannerblock/issues/11 https://github.com/silverstripe/silverstripe-elemental-fileblock/issues/5

[brynwhyman]

Also, please attempt to reproduce #312 after resolving this issue - it's possible this work could unintentionally resolve it.

[NightJar]

Done, animations are not a thing however. PR https://github.com/dnadesign/silverstripe-elemental/pull/443