Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Writing Flow: Ensure default block on removal / replacement #9977
This pull request seeks to ensure that a default block is inserted (and selected) when all other blocks are removed. This helps assure there is no focus loss, and preserves expected native behavior of typing within an editable field, where pressing backspace from the beginning of an otherwise empty field should not incur a focus loss.
Note that as of #9808, in these cases where only a default empty paragraph exists, the saved content will not effectively include the paragraph, but will instead fall back to an empty string, as it's inferred now that a post containing only the default unmodified block is equivalent to being empty.
Verify that if all blocks are removed, a default block is inserted at the beginning of the post and that focus is preserved.
Ensure end-to-end tests pass:
Everything worked as expected on my tests
I wonder If we should add a smilar behaviour for nested blocks, e.g: when we delete the last paragraph inside a column the focus is lost, maybe we should ensure a similar behaviour there.
Re: Nested blocks, it was discussed a bit in #9626. I'd probably agree we don't want focus loss at all, so it may be sensible there as well. A difference might be that in a nested context, the default block might not always be allowed, so not only do we need to account for that, we'd need to decide what to do as a fallback.
It's also something I considered briefly for this as well, at least as far as the default block not necessarily being the paragraph. For example, if the default block was an image, would it make sense to add a default image block when all other blocks are removed? I don't know that this would be a common case (having image block as default would have many other odd consequences already). But worth pointing out that there's something about the paragraph and this expectation of how the block listing is meant to mimic the behaviors of a native textarea input / word processor.
Which is all to say: Maybe, but we might need to discuss further, and I'd suggest deferring it to a subsequent pull request. Perhaps we can keep #9626 open and continue the discussion there.