fix: add custom element support to toBeDisabled
#368
Conversation
| expect(queryByTestId('disabled-custom-element')).not.toBeDisabled() | ||
| }).toThrowError('element is disabled') | ||
|
|
||
| expect(queryByTestId('enabled-custom-element')).not.toBeDisabled() |
There was a problem hiding this comment.
This currently fails with:
I can't figure this out: clearly the custom element is not disabled. More to the point, if I remove the disabled custom element (L122) long with the corresponding assertions (L126-129), the test now passes. It's as if some state was not being reset or something. @gnapse, do you have any idea?
(The same thing happens on the other test L281-L284)
There was a problem hiding this comment.
In other words, splitting the 2 new tests into 4 tests (see diff below) passes. I could do that, but I would prefer to figure out first if this is a bug with the test or with the code: if I split them and it passes, nothing ensures this wouldn't happen in real-life tests that have a mix of disabled and non-disabled custom elements.
Diff
@ src/__tests__/to-be-disabled.js:120 @ test('.toBeDisabled fieldset>legend', () => {
expect(queryByTestId('outer-fieldset-element')).toBeDisabled()
})
-test('.toBeDisabled custom element', () => {
+test('.toBeDisabled disabled custom element', () => {
const {queryByTestId} = render(`
- <custom-element data-testid="disabled-custom-element" disabled="" />
- <custom-element data-testid="enabled-custom-element" />
+ <custom-element data-testid="custom-element" disabled="" />
`)
- expect(queryByTestId('disabled-custom-element')).toBeDisabled()
+ expect(queryByTestId('custom-element')).toBeDisabled()
expect(() => {
- expect(queryByTestId('disabled-custom-element')).not.toBeDisabled()
+ expect(queryByTestId('custom-element')).not.toBeDisabled()
}).toThrowError('element is disabled')
+})
+
+test('.toBeDisabled enabled custom element', () => {
+ const {queryByTestId} = render(`
+ <custom-element data-testid="custom-element" />
+ `)
- expect(queryByTestId('enabled-custom-element')).not.toBeDisabled()
+ expect(queryByTestId('custom-element')).not.toBeDisabled()
expect(() => {
- expect(queryByTestId('enabled-custom-element')).toBeDisabled()
+ expect(queryByTestId('custom-element')).toBeDisabled()
}).toThrowError('element is not disabled')
})
@ src/__tests__/to-be-disabled.js:275 @ test('.toBeEnabled fieldset>legend', () => {
}).toThrowError()
})
-test('.toBeEnabled custom element', () => {
+test('.toBeEnabled disabled custom element', () => {
const {queryByTestId} = render(`
- <custom-element data-testid="disabled-custom-element" disabled="" />
- <custom-element data-testid="enabled-custom-element" />
+ <custom-element data-testid="custom-element" disabled="" />
`)
- expect(queryByTestId('disabled-custom-element')).not.toBeEnabled()
+ expect(queryByTestId('custom-element')).not.toBeEnabled()
expect(() => {
- expect(queryByTestId('disabled-custom-element')).toBeEnabled()
+ expect(queryByTestId('custom-element')).toBeEnabled()
}).toThrowError('element is not enabled')
+})
+
+test('.toBeEnabled enabled custom element', () => {
+ const {queryByTestId} = render(`
+ <custom-element data-testid="custom-element" />
+ `)
- expect(queryByTestId('enabled-custom-element')).toBeEnabled()
+ expect(queryByTestId('custom-element')).toBeEnabled()
expect(() => {
- expect(queryByTestId('enabled-custom-element')).not.toBeEnabled()
+ expect(queryByTestId('custom-element')).not.toBeEnabled()
}).toThrowError('element is enabled')
})There was a problem hiding this comment.
BTW I am not wrapping the elements in a div/fragment because the render function does it on its own, but the error is the same if I do.
|
Hey @gnapse, do you think you could help me with this one? 🙏 Thank you so much in advance! |
|
Hi @gnapse, any chance you could help getting this over the finish line? We'd love to get unstuck! Thanks! |
|
Sorry @astorije for the lack of responsiveness here on my side. Can you remind me what's blocking this right now? |
|
Hi @gnapse, no worries! |
|
Hi @gnapse, friendly ping? We would really love to be able to use |
|
@astorije sorry for having neglected this. I took a deeper look now. Even checking this branch out locally and running the tests. Unfortunately, I have not much of an idea of what's going on. My main bet is that this may have something to do with some shortcoming in the support for custom elements in jsdom. Maybe you should investigate that. My knowledge of custom elements is also not too good. I cannot confidently point out to anything that could be wrong in the PR changes per-se. |
|
@astorije @gnapse this is a straight forward fix. Per the spec, custom elements cannot be self closing. So for the second (enabled) element, it was treating the first (disabled) element as it's parent, and the logic says an element is disabled if it's ancestor is. Change the test code to have a closing tag. See "Rules on creating custom elements": https://developers.google.com/web/fundamentals/web-components/customelements. |
Codecov Report
@@ Coverage Diff @@
## main #368 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 26
Lines 621 624 +3
Branches 230 231 +1
=========================================
+ Hits 621 624 +3
Continue to review full report at Codecov.
|
|
Aaaah thank you @ashleyryan, silly me! It looks like CI is passing now 😍 |
|
@all-contributors please add @astorije and @ashleyryan for code, idea |
|
I've put up a pull request to add @astorije! 🎉 |
|
@all-contributors please add @ashleyryan for code, idea |
|
I've put up a pull request to add @ashleyryan! 🎉 |
|
@astorije @ashleyryan thanks! |
|
🎉 This PR is included in version 5.16.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Thank you @gnapse and @ashleyryan!! |
What:
Allow
toBeDisabledto match against custom elements as supported by the WHATWG spec.Why:
Rationale and example failure + reproduction repository available at #367
How:
This is a draft PR I opened directly from the GitHub UI. In other words, it could not get less tested than that. I'm just opening this to see if you agree with the premise. If you do, I'll add tests, docs, etc. properly.Done.Checklist: