Try one block per paragraph

[ellatrix]

WIP. Tests will fail.

[notnownikki]

Nice, I'm liking this! Do you think it makes sense to make double enter in lists break out into a new text block? Might be a nice shortcut ,people are already used to doing that so they can carry on typing text after a list 😄

[nylen]

While this may simplify things from a technical perspective, I'm not seeing other benefits, and I think there are overwhelming reasons not to do it. So I am going to weigh in against an approach like this once again. Quoting from a significant portion of #409 (comment):

Layout blocks

Longer-term we want to extend the concept of "content blocks" to "layout blocks" - providing an alternative to a widget seems like a good first step here. I'm going to use the term "widget" to mean the block editing experience that we will eventually want to bring to other pieces of a WP page layout [because I think widgets will be one of the first areas to be replaced or upgraded in this way].

Should widgets be able to contain multiple paragraphs of text? Yes, absolutely.

Should widgets contain multiple "blocks" as we are currently building them? I think probably not.

Most common editing operations

Writing multiple paragraphs of text in a row is extremely common. Therefore, this operation should be extremely easy.

The only way we should have one paragraph per block is if the friction of inserting a new block and navigating across blocks is near zero. We already know this isn't the case. To me this implies very clearly that a single text block should be able to contain multiple paragraphs.

More specifically, what I am referring to with "friction of navigating across blocks" is the typical text-editing operations described in #179, which we have so far decided not to support across blocks. In my opinion the only way to make a reasonable writing experience out of this is if a text block supports multiple paragraphs - many of the operations there are extremely common while writing sequences of text.

[aduth]

While not necessarily a guarantee, nodeListToReact will already handle the NodeList -> Array coercion:

https://github.com/iseulde/dom-react/blob/2159830/index.js#L116

[aduth]

Can we add some clarifying inline comments here? Not sure why we care to test whether the final node is a linebreak, or why we're expecting a second line break per the subsequent condition.

Edit: After testing, I understand now that we want two line breaks before split.

[aduth]

Outside scope, but given removal of element dependency, sooner than later I'd like us to move from inferred wp.element.createElement to explicit import { createElement } from 'element';. Related: #742

[ellatrix]

So I should add import { createElement } from 'element';?

[aduth]

Well, eventually, yes. For now since the pragma is defined as wp.element.createElement, it wouldn't be used anyways. Let's just leave it as-is for now, we can handle it separately.

[ellatrix]

Rebased && addressed comments.

[youknowriad]

do we need a closing </p> here?

[ellatrix]

We do :)

[youknowriad]

I kind of expected a single Enter to split the text block here, the br breaks in the text block feel weird to me.

[ellatrix]

@youknowriad That's intended for the line break on enter and paragraph on double enter behaviour.

[mtias]

The single enter behaviour is something we need some early feedback on to make a proper call. It's working better than I expected from the multi-paragraph version, but we'd like to see whether it gets in the way of normal writing flow nonetheless.