Adds HtmlElement pretty-format plugin.#3230
Conversation
Merging changes from Origin
thymikee
left a comment
There was a problem hiding this comment.
Nice work! Left some comments inlined. Btw, that's great usage of @jest-environment pragma 👍
| module.exports = { | ||
| getPrettyPrint: plugins => | ||
| (received, expected, opts) => { | ||
| const prettyPrintImmutable = prettyFormat( |
There was a problem hiding this comment.
We could use some generic naming here, e.g. prettyPrintPlugin
| opts, | ||
| ), | ||
| ); | ||
| const pass = prettyPrintImmutable === expected; |
|
|
||
| const escapeHTML = require('./lib/escapeHTML'); | ||
| const HTML_ELEMENT_REGEXP = /(HTML\w*?Element)/; | ||
| const test = (maybeSet: any) => isHTMLElement; |
There was a problem hiding this comment.
change naming, it's not Set
| val.constructor && | ||
| val.constructor.name && | ||
| HTML_ELEMENT_REGEXP.test(val.constructor.name)); | ||
| } |
There was a problem hiding this comment.
This is potentially a hot place, please keep perf in mind: https://twitter.com/bmeurer/status/846951275480711168
| describe('HTMLElement Plugin', () => { | ||
| it('supports a single HTML element', () => { | ||
| expect(document.createElement('div')).toPrettyPrintTo( | ||
| '<HTMLDivElement />', |
| const child = document.createElement('span'); | ||
| parent.appendChild(child); | ||
| expect(parent).toPrettyPrintTo( | ||
| '<HTMLDivElement >\n <HTMLSpanElement />\n</HTMLDivElement >', |
There was a problem hiding this comment.
Please remove this extra space also here: <HTMLDivElement >
| child.setAttribute('class', 'classy'); | ||
|
|
||
| expect(parent).toPrettyPrintTo( | ||
| '<HTMLDivElement >\n <HTMLSpanElement \n id=123\n class=classy\n />\n</HTMLDivElement >', |
There was a problem hiding this comment.
Attributes should be strings id="123" class="classy".
Reworks short circuiting logic for `isHTMLElement` function.
| const test = isHTMLElement; | ||
|
|
||
| function isHTMLElement(value: any) { | ||
| const toStringed = value.toString(); |
There was a problem hiding this comment.
I'm a bit worried about performance here. This will call toString on any value passed to pretty-format. toString may be expensive if it is overwritten on a class instance. Can we do Object.prototype.toString.call?
There was a problem hiding this comment.
That's a really good call -- I'll check how that behaves on an actual JSDOM HTMLElement to verify.
Looking at it again, I think it's possible that we could just remove this toString completely and just rely on the constructor validation, but I was deferring to the existing implementation from the previous PR.
Does that seem reasonable?
There was a problem hiding this comment.
Yup, I think we could make it even more performant. According to ElementImpl we could check for property nodeType. Although this prop alone could possibly result in some false positives (nodeType feels not so unique...), it's good for an early check. Only when we know there's such prop, we could perform constructor and regex check:
const test = (value: any) =>
value !== undefined &&
value.nodeType === 1 &&
value.constructor !== undefined &&
HTML_ELEMENT_REGEXP.test(value.constructor.name);There was a problem hiding this comment.
Awesome -- I've updated the PR with those changes.
I'm not sure what to do about the tests that are failing; do I need to have mercurial configured locally for those?
There was a problem hiding this comment.
Yes, as stated here, point 6: https://github.com/facebook/jest/blob/master/CONTRIBUTING.md#workflow-and-pull-requests
| const toPrettyPrintTo = require('./expect-util').getPrettyPrint([ | ||
| ReactElementPlugin, | ||
| ReactTestComponentPlugin, | ||
| ...ImmutablePlugins, |
There was a problem hiding this comment.
Node 4 fails because of this destructuring. You can use concat instead
Codecov Report
@@ Coverage Diff @@
## master #3230 +/- ##
==========================================
+ Coverage 64.24% 64.41% +0.16%
==========================================
Files 175 176 +1
Lines 6436 6469 +33
Branches 4 4
==========================================
+ Hits 4135 4167 +32
- Misses 2300 2301 +1
Partials 1 1
Continue to review full report at Codecov.
|
|
|
Sure thing! |
| @@ -60,7 +61,7 @@ const print = ( | |||
| ) => { | |||
| let result = colors.tag.open + '<'; | |||
| const elementName = element.constructor | |||
There was a problem hiding this comment.
const elementName = element.tagNameThere was a problem hiding this comment.
tagName defaults to all uppercase, which felt odd to me -- should I leave it that way or is the .toLowerCase() call okay here?
There was a problem hiding this comment.
lower case is better, leave it as is :)
|
Thanks for doing this! |
* Adds HtmlElement pretty-format plugin. * Adds missing copyright and 'use strict' * Fixes variable naming / formatting. Reworks short circuiting logic for `isHTMLElement` function. * Improves performance for isHtmlElement. * Updating snapshots * Revert "Updating snapshots" This reverts commit 55f797f. * Fixes node 4 syntax * - Switches to tagName rather than constructor. * Adds HTMLElement Plugin usage. * Removes `HTMLElement` fallback in favor of tagName
* Adds HtmlElement pretty-format plugin. * Adds missing copyright and 'use strict' * Fixes variable naming / formatting. Reworks short circuiting logic for `isHTMLElement` function. * Improves performance for isHtmlElement. * Updating snapshots * Revert "Updating snapshots" This reverts commit 55f797f. * Fixes node 4 syntax * - Switches to tagName rather than constructor. * Adds HTMLElement Plugin usage. * Removes `HTMLElement` fallback in favor of tagName
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
This addresses the issue noted in #2146, with
jsdomHTMLElement's producing an absurdly long string when pretty formatted. It adds anHTMLElementplugin which can be used to appropriatelypretty-formatthese elements.Test plan
I tested this using a variety of unit tests, similar to the existing tests that were covering
ReactElement.The cases I covered were ensuring that the class / title properties would pretty-format correctly, along with attributes on single elements and nested elements.
Here is the output from running those tests: