Skip to content
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

Draft
wants to merge 2 commits into
base: next
Choose a base branch
from

Conversation

mcous
Copy link
Contributor

@mcous mcous commented Feb 15, 2024

Fixes #312, fixes #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.

Change log

  • Renamed renderOptions.container to renderOptions.baseElement
  • Return baseElement as result.baseElement
  • Default baseElement to componentOptions.target if used, else document.body
  • Return componentOptions.target as result.container, which is one layer lower in the DOM than the previous behavior and matches other testing-library frameworks
  • componentOptions.target will now trigger an error if it is mixed with props, matching the behavior of other component options
  • Updated and reorganized tests
  • Updated type definitions

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.
package.json Show resolved Hide resolved
src/__tests__/__snapshots__/render.test.js.snap Outdated Show resolved Hide resolved
@@ -1,23 +1,17 @@
<svelte:options accessors />

<script>
import { getContext } from 'svelte'
Copy link
Contributor Author

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

Copy link
Contributor Author

@mcous mcous Feb 15, 2024

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

Copy link
Contributor Author

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/__tests__/render.test.js Show resolved Hide resolved
src/pure.js Outdated

return { props: options }
}
const ComponentConstructor = Component.default || Component
Copy link
Contributor Author

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 () => {
Copy link
Contributor Author

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

@mcous
Copy link
Contributor Author

mcous commented Feb 16, 2024

@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

Copy link
Collaborator

@yanick yanick left a 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?

@mcous
Copy link
Contributor Author

mcous commented Feb 16, 2024

10-4, will undraft this PR when corresponding docs PR is up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants