-
-
Notifications
You must be signed in to change notification settings - Fork 926
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardise vnode text representation #2670
Conversation
|
||
o(succeeded).equals(false) | ||
}) | ||
o.spec("contenteditable throws on untrusted children", function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous tests duplicated this sequence with a nebulous distinction between 'attr' & 'prop'
{tag:"option", attrs: {value: "0"}}, | ||
{tag:"option", attrs: {value: ""}} | ||
]} | ||
return m("select", attrs, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Constructing the select element itself via hyperscript rather than manually triggers these errors https://travis-ci.org/github/MithrilJS/mithril.js/builds/767047585#L293-L311:
attributes > select.value > updates with the same value do not re-set the attribute if the select has focus:
1
should equal
0
at /home/travis/build/MithrilJS/mithril.js/render/tests/test-attributes.js:639:35
attributes > select.value > updates with the same value do not re-set the attribute if the select has focus:
1
should equal
0
at /home/travis/build/MithrilJS/mithril.js/render/tests/test-attributes.js:644:35
attributes > select.value > updates with the same value do not re-set the attribute if the select has focus:
2
should equal
1
at /home/travis/build/MithrilJS/mithril.js/render/tests/test-attributes.js:649:35
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to isolate the issue from the DOM mocks, I can't replicate it with real DOM. Using a spy trap on the HTMLInputElement
'value' setter, both the manually constructed select and the hyperscript equivalent fail the first test but none of the others:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spy was buggy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well spotted! In this case, the DOM mock is correct, and the tests fail if we give them a hyperscript-generated select
rather than a manually constructed one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll have to dig into m.render
and the mocks to try and figure out why the setter is triggered extraneously
(tomorrow)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the hyperscript-generated vnode, the empty attrs object (i.e. {}) is re-set to null by execSelector(). This is the difference between the hyperscript-generated vnodes and the manually constructed ones in this case.
In execSelector(), instead of setting the attrs to null, it may be better to set an empty object or undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kfule brilliant! And fixing this would lead to further standardisation. Thanks so much!
The <textarea> bug caused by this fix:
|
A worthy effort! |
If you re-bundle the module, it will also fail the real DOM test. |
Thanks again @kfule ! So the rules of API precedence for textarea seem to be (lowest to highest):
I therefore propose we rewrite these tests and follow Reacts lead in avoiding use of subtree to define textarea value. This should be present as a warning in the change log for now. Neither 1 or 3 work as HTML values, but any DOM representation will be serialised with the element subtree, so this shouldn’t be a problem for SSR rendering (@StephanHoyer?). Thanks again for your insights @kfule |
429cc4a
to
75c6005
Compare
@barneycarroll I would really like to see this in the next release. Would be great if you can rebase and cleanup this PR so I can review and test this. |
Sure, I’ll have a look tomorrow. |
@barneycarroll Are you still interested in doing this? If not it's ok, then I can take a look at it. |
c0fd201
to
d223902
Compare
@barneycarroll just rebased without issues |
@barneycarroll Merged! |
This addresses the crucial feature of #2669: text is always represented as virtual text nodes, never as a
vnode.text
. Thevnode.text
field remains in place for now.The fix failed many tests which baked-in assumptions about vnode structure, so I took the opportunity of rewriting the tests to always use hyperscript expressions to avoid this category of brittle testing in future. In the process I removed a handful of tests which manually constructed vnode configurations which aren't feasible with hyperscript expressions, and fixed some text tests whose manual construction led them to validate impossible scenarios (boolean nodes are never treated as text nodes).
The fix as is creates a regression whereby
<textarea>
updates fail, which I'll need to fix.The test cleanup creates its own strange bug in the
<select>
value update tests. I don't quite understand how this happened or what it's about, I'd appreciate a second pair of eyes.