Describe the feature you'd like:
When using the debug wrapper in a test, it would be useful to be able to pass additional prettyDOM arguments through from debug
An example use case is being able to extend the number of lines that prettyDOM allows without needing to specify this in env prior to running the tests or needing to use prettyDOM directly
Example:
it('should print all the lines', () => {
const { debug } = render(<LargeComponent />);
const maxLinesForThisTest = 10000;
debug(undefined, maxLinesForThisTest);
});
I'd be happy to implement this feature, however just curious if there was a specific reason why this was not implemented on the first pass of debug - My team is familiar with using debug for printing out the DOM and we don't often use prettyDOM, and since this wrapper already exists as an api of the render method, allowing users to use debug as the default api makes sense to me
Suggested implementation:
1. First Suggestion:
Additional arguments could be forwarded through debug and passed into prettyDOM in this chunk of code
|
debug: (el = baseElement) => |
|
Array.isArray(el) |
|
? // eslint-disable-next-line no-console |
|
el.forEach(e => console.log(prettyDOM(e))) |
|
: // eslint-disable-next-line no-console, |
|
console.log(prettyDOM(el)), |
(I believe this is the correct place after a little bit of investigation, but am open to other implementations)
debug: (el = baseElement, maxLength, options) =>
Array.isArray(el)
? // eslint-disable-next-line no-console
el.forEach(e => console.log(prettyDOM(e, maxLength, options)))
: // eslint-disable-next-line no-console,
console.log(prettyDOM(el, maxLength, options)),
2. Second Suggestion
Keep the implementation of debug the same and add an additional method that always prints the baseElement and allows the user to forward args to prettyDOM - I'm not a big fan of this solution, but 99% of time I've found myself calling debug() without any arguments with the assumption that I wasn't able to pass debug(someElement) as the first argument - so being able to call debug(maxLines) without specifying the debugged element might be nice
debugBaseElement: (maxLength, options) =>
const el = baseElement;
Array.isArray(el)
? // eslint-disable-next-line no-console
el.forEach(e => console.log(prettyDOM(e, maxLength, options)))
: // eslint-disable-next-line no-console,
console.log(prettyDOM(el, maxLength, options)),
Describe alternatives you've considered:
- It's possible to get add additional lines by setting an env in the command line
DEBUG_PRINT_LIMIT=10000 npm test however when running jest in --watch mode, this requires us to kill the test runner, update the print limit, then rerun tests which isn't super painful, but adding this inline would be faster
- Also possible to use
prettyDOM directly from @testing-library/dom, however it's not immediately clear from the docs whether we should be passing in container, asFragment(), or baseElement into this method - Also, since debug is already a wrapper on top of prettyDOM, it makes sense to be able to pass the same args IMO
- Another downside of
prettyDOM is that debug wraps prettyDOM in a console.log, whereas prettyDOM requires you to call prettyDOM within a console.log, which makes using the two apis interchangeably potentially confusing
Teachability, Documentation, Adoption, Migration Strategy:
Docs would stay very much the same, only adding a link to prettyDOM from https://testing-library.com/docs/react-testing-library/api#debug and ensure that it's clear the user can forward prettydom arguments from debug
Describe the feature you'd like:
When using the
debugwrapper in a test, it would be useful to be able to pass additionalprettyDOMarguments through fromdebugAn example use case is being able to extend the number of lines that
prettyDOMallows without needing to specify this inenvprior to running the tests or needing to useprettyDOMdirectlyExample:
I'd be happy to implement this feature, however just curious if there was a specific reason why this was not implemented on the first pass of
debug- My team is familiar with usingdebugfor printing out the DOM and we don't often useprettyDOM, and since this wrapper already exists as an api of therendermethod, allowing users to usedebugas the default api makes sense to meSuggested implementation:
1. First Suggestion:
Additional arguments could be forwarded through
debugand passed intoprettyDOMin this chunk of codereact-testing-library/src/pure.js
Lines 63 to 68 in 89d11b0
2. Second Suggestion
Keep the implementation of
debugthe same and add an additional method that always prints thebaseElementand allows the user to forward args to prettyDOM - I'm not a big fan of this solution, but 99% of time I've found myself callingdebug()without any arguments with the assumption that I wasn't able to passdebug(someElement)as the first argument - so being able to calldebug(maxLines)without specifying the debugged element might be niceDescribe alternatives you've considered:
DEBUG_PRINT_LIMIT=10000 npm testhowever when running jest in--watchmode, this requires us to kill the test runner, update the print limit, then rerun tests which isn't super painful, but adding this inline would be fasterprettyDOMdirectly from@testing-library/dom, however it's not immediately clear from the docs whether we should be passing incontainer,asFragment(), orbaseElementinto this method - Also, sincedebugis already a wrapper on top of prettyDOM, it makes sense to be able to pass the same args IMOprettyDOMis thatdebugwrapsprettyDOMin a console.log, whereasprettyDOMrequires you to callprettyDOMwithin a console.log, which makes using the two apis interchangeably potentially confusingTeachability, Documentation, Adoption, Migration Strategy:
Docs would stay very much the same, only adding a link to
prettyDOMfrom https://testing-library.com/docs/react-testing-library/api#debug and ensure that it's clear the user can forward prettydom arguments fromdebug