Conversation
6f18bbd to
e6ffd52
Compare
|
While quickly putting this alternative together, I used dom-react to loop through the nodes. I wonder if we want to keep this though. The most important thing it does is mapping attributes to React canonical ones and parse the style attribute to JSON. If we don't mind attributes with dashes in the state... we could loop ourselves and drop this. With React 16, it seems still recommended to use the canonical attributes, so then we would need to map from state to React, instead of dom to React. |
blocks/editable/test/index.js
Outdated
There was a problem hiding this comment.
Is this needed? Not sure how that could happen.
There was a problem hiding this comment.
We can drop it, I just wanted to track down why this fails in test env.
|
It turns out we are using React 15 and this break most of the code used. I will look into an upgrade to React 16 tomorrow to get rid of |
e6ffd52 to
14315b3
Compare
blocks/editable/index.js
Outdated
There was a problem hiding this comment.
Only in test environment are we using React 15.
|
As soon as we land React upgrade for tests (#3079) I will update PR to stop using hacky |
14315b3 to
eebaeca
Compare
|
I rebased with We have still 14 failing tests, but 12 of them are directly related to the different JSON representation of components. There are 2 tests failing that we still need to investigate:
|
eebaeca to
0b5428f
Compare
blocks/api/test/source.js
Outdated
| const match = parse( html, sources.node() ); | ||
|
|
||
| expect( renderToString( match ) ).toBe( `<body>${ html }</body>` ); | ||
| expect( renderToString( valueToElement( [ match ] ) ) ).toBe( `<body>${ html }</body>` ); |
There was a problem hiding this comment.
@iseulde this test is failing. I didn't find a way to fix it. There is some issue with the sources.node parser. It inlines string nodes and nodes represented as an array. Once this is sorted out we should be good to do.
It also fails for this HTML fixture.
<blockquote class="wp-block-pullquote alignnone">
<p>Paragraph <strong>one</strong></p>
<p>Paragraph two</p>
<footer>by whomever</footer>
</blockquote>4cf568b to
03c9bc0
Compare
| @@ -27,10 +28,29 @@ registerBlockType( 'core/table', { | |||
| type: 'array', | |||
| source: children( 'table' ), | |||
| default: [ | |||
There was a problem hiding this comment.
We might want to keep what we had before and provide transformation layer instead. I wanted to make it work.
|
@iseulde @aduth @youknowriad - I manage to make it work with both the existing unit tests and the browser. There
|
blocks/api/source.js
Outdated
|
|
||
| if ( match ) { | ||
| return nodeListToReact( match.childNodes || [], createElement ); | ||
| return nodeListToReact( match.childNodes || [], toArray ); |
There was a problem hiding this comment.
I guess dom-react should be something like dom-traverse?
There was a problem hiding this comment.
Should I read it as we should introduce a facade for dom-react? I think it would make a lot of sense.
There was a problem hiding this comment.
I guess
dom-reactshould be something likedom-traverse?
Yeah, this confused me as well, and I thought we were creating instances of React elements and then converting those into arrays. Understand better now, but the naming is a bit misleading. I also wonder how much of the React-isms we really need to be accounting for (e.g. key) or if it's enough to pick attributes from node.attributes (see 6521f06).
There was a problem hiding this comment.
Honestly I just did this to spin up a fast POC. Would prefer if we get rid of this too.
blocks/editable/index.js
Outdated
| const { BACKSPACE, DELETE, ENTER } = keycodes; | ||
|
|
||
| function createTinyMCEElement( type, props, ...children ) { | ||
| function toArray( type, props, ...children ) { |
There was a problem hiding this comment.
Should we name it valueFromElement (to be consistent with valueToElement)?
There was a problem hiding this comment.
Good idea, I like your proposal :)
blocks/api/source.js
Outdated
| } | ||
|
|
||
| return nodeToReact( match, createElement ); | ||
| return flatten( nodeToReact( match, toArray ) ); |
There was a problem hiding this comment.
Why does this need to flatten?
There was a problem hiding this comment.
Yes, this one is tricky. I had to flatten it to mirror what is happening in the editor. Somehow it wraps with one additional array when you compare with what is passed to <Editable /> or <Editable.value />. It was quite hard to find a setup where all moving parts are satisfied: <Editable />, <Editable.value />, pasting from other documents. It might be a better idea to wrap value with another array in Editable. I'm not sure what's better here.
525b9c4 to
107a6d9
Compare
107a6d9 to
e9b7111
Compare
| const [ type, props, ...children ] = element; | ||
| const reactProps = Object.keys( props ).reduce( ( accumulator, key ) => { | ||
| const mapping = { | ||
| class: 'className', |
There was a problem hiding this comment.
It looks like adding those 2 mappings is enough to satisfy React.
There was a problem hiding this comment.
Okey, style needs its own handling, because I see this: https://reactjs.org/docs/error-decoder.html?invariant=62&args[]=
There was a problem hiding this comment.
All keys must go camel case, too.
| }; | ||
| }, { key: i } ); | ||
|
|
||
| return createElement( type, { ...reactProps }, ...valueToElement( children ) ); |
| onSetup={ this.onSetup } | ||
| style={ style } | ||
| defaultValue={ value } | ||
| defaultValue={ valueToElement( value ) } |
There was a problem hiding this comment.
Can we use applySimpleNodeList in here, too?
|
@gziolo @iseulde How reasonable do you think (in parallel to the work here) to implement our own I'm finding we're repeatedly bumping up against issues with React's serialization, most recently summarized at #3353 (comment). |
|
@aduth But then we can't use React elements inside the save function? Or would it be mixed? |
Right, I would think still supporting React elements, but "turning off" some of the sanitization behaviors, and supporting other object shapes. |
|
Should we consider this now as succeeded by #4049? |
Yes, probably it makes the most sense. This one was very helpful in the context of exploring what we really need. We should focus on one approach and finally get it merged :D |
|
Closing for now in favour of #4049. |
Description
Tries to address #2750.
This branch was created as a proof of concept and alternative to #2786. Logging it as a PR, but it's still a work-in-progress.
The goal is to have the editable state as a true (simple arrays), a cleaned up version of the current state as a React tree.