fix(render): Default to HTMLElement in returned container #868
Conversation
eps1lon
added
bug
| @@ -35,13 +36,18 @@ export async function testPureRender() { | |||
|
|
|||
| // helpers | |||
| const {container, rerender, debug} = page | |||
| expectType<HTMLElement, typeof container>(container) | |||
There was a problem hiding this comment.
This was Element before this change which caused #834 (comment)
|
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 a61a0d5:
|
Codecov Report
@@ Coverage Diff @@
## master #868 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 4 4
Lines 140 140
Branches 26 26
=========================================
Hits 140 140 Continue to review full report at Codecov.
|
|
Out of curiosity, why not continue to default the return type to Alternatively, could we release this as a temporary fix and then go back after a major release? I think it's valuable to have a more generic return type for accuracy with React (as it can render both HTML and SVG elements). |
types/test.tsx
Outdated
| render(<div />, options) | ||
| const {container: returnedContainer} = render(<div />, options) | ||
| // Unclear why TypeScript infers `HTMLElement` here when the the input `container` is `HTMLDivElement` | ||
| // Hopefully this breaks someday and we can switch to | ||
| // expectType<HTMLDivElement, typeof returnedContainer>(returnedContainer) | ||
| expectType<HTMLElement, typeof returnedContainer>(returnedContainer) |
There was a problem hiding this comment.
This is a limitation of TypeScript's JSX syntax support. JSX elements unfortunately can't be inferred to a specific element type. You'd have to use the React.createElement syntax, though it's not recommended in most cases.
So for now, this test is accurate, though you could avoid JSX if you wanted to still test the regression.
There was a problem hiding this comment.
The <div /> is irrelevant here as far as I know though definitely confusing. The type should be inferred from options.
The confusing part is why it works for SVGSVGElement but not HTMLDivElement.
Let me replace <div /> with <button /> to check if your assumption is true.
There was a problem hiding this comment.
Hm, I missed that, I'm curious what happens
There was a problem hiding this comment.
Changed. Is it now clearer that the container is not inferred from the rendered UI but the options?
I expanded the test for svg containers to confirm this. They now return
Why would we go back? |
types/test.tsx
Outdated
| return {container, rerender, debug} | ||
| } | ||
|
|
||
| export function testRenderOptions() { | ||
| const container = document.createElement('div') | ||
| const options = {container} | ||
| render(<div />, options) | ||
| const {container: returnedContainer} = render(<button />, options) | ||
| // Unclear why TypeScript infers `HTMLElement` here when the the input `container` is `HTMLDivElement`. |
There was a problem hiding this comment.
If we'd swap the render methods in the declaration file, this would infer correctly (it uses the first one).
I'm unfamiliar with the types for RTL, so I'm not sure if this would break something, or if we could maybe entirely remove the other render type.
| // Unclear why TypeScript infers `HTMLElement` here when the the input `container` is `HTMLDivElement`. | |
| // Unclear why TypeScript infers `HTMLElement` here when the input `container` is `HTMLDivElement`. |
There was a problem hiding this comment.
@timdeschryver Awesome, thanks! Fixed in a61a0d5 (#868)
|
Merging despite pending codecov/project status. The codecov comment is up-to-date and reports the desired 100%. |
|
🎉 This PR is included in version 11.2.4 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
What:
Fixes #834 (comment)
Why:
By default we create a
divbut declare that the type isElement. This is not specific enough for most use cases since e.g.offsetHeightisn't implemented inElementHow:
Adding a type parameter as anticipated in #833 (comment)
Checklist:
[ ]Documentation added to thedocs site