The Parser does not appear to be working correctly anymore??? Help needed!

[BE-Webdesign]

Hi, after doing a rebase for a PR I was going to submit, the parser did not have the same functionality. The code I had running before was pre hpq maybe that is the culprit? Can anyone verify the same behavior seen below? It seems that the parser went from parsing 8 blocks or so down to only 3 on a clean version of master, while parsing post-content.js.

If you are experiencing the same thing, please let me know as I am stumped, I was told that things were building properly, so I have no idea what is wrong. Here is an image below of the parsed post-content.js I am seeing after running

npm install

npm run dev

For the gutenberg plugin directory. Now the markup which used to feature images etc. Looks like this:
Notice some of the html tags are escaped as well because there is now a react component handling things.

Previously I was able to get a front end editor running which parsed correctly like this:

But now the parser seems broken to me? Help!

[aduth]

@BE-Webdesign This is expected. Previously the markup was not being parsed at all. It was simply assigned as the innerHTML to a contenteditable element. Basic block parsing now exists as of #319 and #322, but only for plain text (the only block currently implemented). This explains why you're only seeing paragraphs.

Now that there's some basic behaviors around block parsing, we'll need to continue implementing and fleshing out blocks. If you're interested, I'd invite you to take a stab at one of them, using the text block and proposed block APIs as a base.

[BE-Webdesign]

@aduth Okay, now it makes sense. The parsing is basically super strict right now?

There will need to be a way to grab raw stuff as HTML though, or else it will be pretty hard if not impossible to have post_content be portable going forward. I will check out hpq and try and get it to do that. I think it is critical to have a base HTML block potentially that is just a slab of HTML. Maybe I will take a stab at that for a first block.

What is the plan for handling tags inside of react components? I think avoiding using dangerouslySetInnerHTML is a good thing. Are we going to parse block content into more components recursively or what is the plan?

[aduth]

The parsing is basically super strict right now?

More accurately the parsing barely exists, and hadn't existed at all previously. What you were seeing before was simply the default behavior of contenteditable.

There will need to be a way to grab raw stuff as HTML though, or else it will be pretty hard if not impossible to have post_content be portable going forward.

Right, we'll need to explore some fallback options for content which can't be matched to a registered block. This might either be some transparent upgrade (<p> as text) or a generic block for unparseable content. At the moment it's just a matter that these have not been implemented yet.

I think avoiding using dangerouslySetInnerHTML is a good thing.

I think the only case I've seen so far where we'll need this kind of behavior is for rich text, which will be handled by TinyMCE (i.e. hopefully won't need dangerouslySetInnerHTML).

[BE-Webdesign]

More accurately the parsing barely exists, and hadn't existed at all previously.

Maybe we are interpreting parsing to mean two different things. Previously wp.blocks.parse() would match up any demarcated blocks and raw HTML and output an array of objects. Now it seems to only output block types that have been registered. I know the attributes were only just innerHTML basically. So although it was not parsing any attributes or parsing in a meaningful way, to me it was still "parsing" the text into an array of objects. Maybe I am using the wrong terminology.

I think the only case I've seen so far where we'll need this kind of behavior is for rich text, which will be handled by TinyMCE (i.e. hopefully won't need dangerouslySetInnerHTML).

Sounds like a great solution.