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

Add utilities for mounting and un-mounting components #53

Merged
merged 1 commit into from
Nov 26, 2024

Conversation

robertknight
Copy link
Member

A common pattern in our tests is to render a component and add the wrapper and (optionally) its DOM container to a list of active wrappers/containers. At the end of the test a Mocha afterEach block is then used to ensure all components are unmounted.

This commit adds mount and unmountAll utilities to this package to simplify this pattern. The mount function renders the component and adds its wrapper to the active set. unmountAll unmounts all active wrappers.

A common pattern in our tests is to render a component and add the wrapper and
(optionally) its DOM container to a list of active wrappers/containers. At the
end of the test a Mocha `afterEach` block is then used to ensure all components
are unmounted.

This commit adds `mount` and `unmountAll` utilities to this package to simplify
this pattern. The `mount` function renders the component and adds its wrapper to
the active set. `unmountAll` unmounts all active wrappers.
Comment on lines +8 to +14
export type MountOptions = {
/**
* If true, the element will be rendered in a container element which is
* attached to `document.body`.
*/
connected?: boolean;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is convenient, as very frequently we need the element to actually be in the DOM and we don't care about the container, but there are cases in which we need to customize the container with styles and such. See this test for example.

Maybe we could allow an HTMLElement to be conditionally provided, either by allowing the connected option to be connected?: boolean | HTMLElement, or by providing a more complex union type where either connected?: boolean or container?: HTMLElement to be allowed.

The later is probably more correct from a type point of view, but will require more checks.

We could also try to find a different option name where boolean | HTMLElement feels less awkward.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To begin with I would suggest that callers continue to use the underlying Enzyme API if they need to customize the container. When we better understand how custom containers are used then we could integrate it into this convenience API. There are some details I'm not sure about. For example, with this API the container is "owned" by this package and gets removed when unmountAll is called. I'm not sure if that is appropriate for custom containers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, good point.

Let's land this. It will allow us to remove a lot of duplicated code already.

@robertknight robertknight merged commit 22aa072 into main Nov 26, 2024
2 checks passed
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.

2 participants