Sibling inserter: Fix the inserter position for floated blocks

[youknowriad]

closes #4142

This PR fixes the sibling inserter for floated blocks by moving the sibling inserter inside the BlockEdit component, that way we can position it relative to its container.

Testing instructions

• Add a block button
• Alight it right
• Check that the inserter is showing up when you hover the border bottom of the block.

[jasmussen]

Impressive! This is working well for me. Can't speak for the code but experience wise this seems to fix it.

Does it also fix some of the float issues @gziolo reported? (Not that it has to) — #3870 #3869 #3868

[youknowriad]

Unfortunately, it doesn't solve these issues. These will be much harder to solve since it's related to how "floating" works. We may have to think about "workarounds"

[jasmussen]

Unfortunately, it doesn't solve these issues. These will be much harder to solve since it's related to how "floating" works. We may have to think about "workarounds"

Yep, they're still on my todo list, and someting I'd like to think about over the holidays. Perhaps we need to go back to a fixed-width main column, and use JavaScript to make full-wide images :(

[youknowriad]

Perhaps we need to go back to a fixed-width main column, and use JavaScript to make full-wide images :(

I agree with this, we need a fixed-width main column.

[jorgefilipecosta]

I am not certain moving sibling inserter inside block-list will not have the undesirable side effect of making sibling inserter unusable for locked blocks cc: @gziolo.

[youknowriad]

What do you mean by "locked blocks"?

[youknowriad]

I guess you mean "template locking". In which case, this change doesn't change the current behavior which is: The Inserter component does not show anything if the template is locked. This component is included in the BlockListSiblingInserter component.

[jorgefilipecosta]

In PR #3493 BlockListBlock was made extensible to allow the creation of Frozen/locked blocks. Blocks that are temporarily not editable because of co-editing for example. It looks like the hook allows us to "change" BlockListBlock, so in places that use/or we have plans to use this hook, we may be disabling sibling inserter.

[youknowriad]

Good point! If that means the hook should be "smarter" or the hook should target BlockEdit instead?

[jorgefilipecosta]

In accordance with the conversation on PR #3493 adding the hook to BlockEdit does not fit the needs, because it would not be possible to lock the toolbar or the block transform mechanism. So we can make the hook smarter or we can try to add a component that wraps BlockListBlock and the sibling inserter.

[youknowriad]

@gziolo any thoughts on this?

[gziolo]

@jorgefilipecosta thanks for raising this issue. Yes, it might be a bit inconvenient, but I'm sure we can find workarounds :) Don't treat it as a blocker as we can figure out solutions later.

So we can make the hook smarter or we can try to add a component that wraps BlockListBlock and the sibling inserter.

It seems like a wrapping div would work perfectly fine. I like the idea. I didn't think about it too much though :)

[jorgefilipecosta]

I left a concern related to locked blocks. But other than that everything works as expected in my tests and I did not find any problem. Nice work 👍

[aduth]

This can be map now instead of flatMap if we're just returning a single value from the mapper.

[youknowriad]

Ok this should be ready to go, merging