New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix!: align target and baseElement options with testing-library
#325
base: next
Are you sure you want to change the base?
Conversation
Fixes testing-library#312, fixes testing-library#313 BREAKING CHANGES: The `container` option has been renamed to `baseElement`, `result.container` is now set to `target` rather than `baseElement`, and `render` will now throw if you mix props with the `target` option.
| @@ -1,23 +1,17 @@ | |||
| <svelte:options accessors /> | |||
|
|
|||
| <script> | |||
| import { getContext } from 'svelte' | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicate context testing between render.test.js and context.test.js. Since context.test.js has its own Context.svelte fixture, I removed context stuff from here
src/__tests__/fixtures/Comp2.svelte
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixture wasn't being used for anything meaningful that I could figure out. I suspect it was from an old CJS vs ESM test. See other comments for more details
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixture was no longer needed now that rerender does not unmount. Instead, we can just hold on to the DOM element and make sure the element itself is updated rather than replaced
src/pure.js
Outdated
|
|
||
| return { props: options } | ||
| } | ||
| const ComponentConstructor = Component.default || Component |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this must be a weird holdover from CJS days. I may remove it in a future PR, since I can't figure out how to actually trigger this code-path in tests now that we're ESM-native
| rerender({ props: { name: 'World 2' } }) | ||
| await expectToRender('Hello World 2!') | ||
| expect(onDestroyed).not.toHaveBeenCalled() | ||
| test('change props with accessors', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test moved over from render.test.js because it has more in common with rerender.test.js
|
@yanick let me know if you think this is too much to change in one PR; I can split it up into a few separate changes relatively trivially |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Can you also prepare a branch for the documentation changes related to this PR?
|
10-4, will undraft this PR when corresponding docs PR is up |
Fixes #312, fixes #313
BREAKING CHANGES: The
containeroption has been renamed tobaseElement,result.containeris now set totargetrather thanbaseElement,and
renderwill now throw if you mix props with thetargetoption.Change log
renderOptions.containertorenderOptions.baseElementbaseElementasresult.baseElementbaseElementtocomponentOptions.targetif used, elsedocument.bodycomponentOptions.targetasresult.container, which is one layer lower in the DOM than the previous behavior and matches othertesting-libraryframeworkscomponentOptions.targetwill now trigger an error if it is mixed with props, matching the behavior of other component options