feat: Add filterNode option to prettyDOM
#907
Conversation
eps1lon
added
enhancement
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit e949974:
|
Codecov Report
@@ Coverage Diff @@
## alpha #907 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 24 25 +1
Lines 902 914 +12
Branches 279 286 +7
=========================================
+ Hits 902 914 +12
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
eps1lon
changed the title
<script /> and comment nodes when logging the DOM
eps1lon
changed the title
<script /> and comment nodes when logging the DOM<script /> and comment nodes when logging the DOM
|
I can see the value of this one but it is a breaking change and should be considered thoroughly. |
I think I referred to all of this in the PR description: "We can then decide whether we want to defer to userland, release it as a breaking change or make it backwards compatible." |
|
Perhaps we could hide this behind a config boolean, and set the default to true on a major release. |
|
I appreciate the review but let's focus on the high level problem: Do we want this as a feature or breaking change? What is the use case for the current behavior? Then we can talk about the implementation. The implementation is problematic for a feature since it adds configuration but trivial to do. |
I'm actually not so sure I'm in favor of adding this one. I think that isn't a part of our responsibility and may just cause bugs/issues in some cases. As you already wrote, this can be patched on the user-land so I'm not sure a solution on our end is really necessary. |
I think neither of these statements are relevant. What is our responsibility is better error diagnostics. So the question is if this helps or hinders error diagnostic which we should talk about. Causing bugs is inherent to any change. The question is how likely they are.
I believe. I haven't actually done it so let's not jump to conclusions and assume that the userland implementation is trivial. |
|
We already have dom-testing-library/src/config.ts Line 44 in ffc8f26 That's used for the |
|
To be clear, I'm in favor of this change in light of that :) |
That makes a lot of sense. I was a bit suprised that I couldn't find existing implementation. Will try to see if I can leverage |
|
To be clear, I think we should try to use whatever the |
|
In fact, it may be useful to also display the |
eps1lon
changed the title
<script /> and comment nodes when logging the DOM<script />, <style />, and comment nodes when logging the DOM
| @@ -0,0 +1 @@ | |||
| export const DEFAULT_IGNORE_TAGS = 'script, style' | |||
There was a problem hiding this comment.
Breaks up a circular dep between config and prettyDOM
eps1lon
force-pushed
the
feat/pretty-dom-noise
branch
from
1378c7d
to
4ee6ec8
Compare
eps1lon
changed the title
<script />, <style />, and comment nodes when logging the DOMfilterNode option to prettyDOM
There was a problem hiding this comment.
Thanks for this work!
Not excited about vendoring the DOMElementFilter file. I'm guessing they weren't receptive to a PR for this feature?
How much work would it be to take the ignore option into account for the errors that are thrown? For example, let's say I'm trying to find text within a style tag. I would set the selector and ignore values like so:
screen.getByText('.css-selector', {selector: 'style', ignore: 'script'})Then my error should only show the things that could have matched. And it should show the selector and ignore configuration options as well.
So would it be possible to automatically filter the error message print out in a way that matches the selector and ignore values? I just think that a mismatch in those two could lead to confusing results.
I think it would amount to passing the selector and ignore options to prettyDOM and when those are provided, a filterNode function is created which only let's nodes that match the selector and don't match the ignore through. That way the error message displayed shows exactly what the user could have queried for given the options.
Me neither 😄
It was pretty cumbersome to integrate while not breaking all the other tests. They generally weren't receptive to filtering stuff out at all which makes sense considering I think I'm generally fine with the "fork now, upstream later" approach here.
This is a real concern I agree. But we might want to revisit if we want to consider |
Agreed.
Yeah, I was worried my contrived example would be distracting 😅 I think in general the biggest problem is the mismatch between what we see in the error and what we ignore/select. If you don't use
That's fair. I currently don't have a use case for |
Sounds good. I just go ahead and add a test so that it's really "just" about fixing the problem. Makes it easier to get started contributing. |
Co-authored-by: Tim Deschryver <28659384+timdeschryver@users.noreply.github.com>
|
🎉 This PR is included in version 8.0.0-alpha.5 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
BREAKING CHANGE:
<script />,<style />and comment nodes are now ignored by default inprettyDOM.If you whish to return to the old behavior, use a customfilterNodefunction. In this caseprettyDOM(element, { filterNode: () => true }).I would find this change useful. But I believe this is possible to do in userland so I'm preparing a PR that just implements this in userland. We can then decide whether we want to defer to userland, release it as a breaking change or make it backwards compatible.
What:
Ignore
<script />,<style />and comment nodes inprettyDOMWhy:
test frameworks like
karmaandmochaadd<script />and comment nodes that add quite a bit of noise making debugging harder.Would also improve #902
How:
Fork
DOMElementplugin frompretty-domto allow filtering singleNodeinstances.Checklist:
docs site
Will do when we release the stable v8