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

Emit type declaration files when building library #9

Merged
merged 1 commit into from
Oct 26, 2023

Conversation

acelaya
Copy link
Contributor

@acelaya acelaya commented Oct 26, 2023

This PR introduces these changes:

  1. Makes sure type declaration files are generated when building the library.
  2. Defines the types entry point in package.json, so that consumers con discover those type declarations.
  3. Adds a comment in the accessibility Scenario type, recommending returning a VNode when possible and explaining why.

Point 3 was the initial motivation for this PR, but then I realized that would not be available to consumers without publishing type declarations.

Our projects still don't use TS in tests, so the benefits this provides are limited at the moment, but I think it makes sense anyway as that's the direction we want to eventually go.

@acelaya acelaya requested a review from robertknight October 26, 2023 09:33
@acelaya acelaya changed the title Produce type declaration files when building library Emit type declaration files when building library Oct 26, 2023
@@ -10,6 +10,10 @@ export type Scenario = {
/**
* A function that returns the rendered output to test, or an Enzyme wrapper
* created using Enzyme's `mount` function.
*
* Returning a VNode is preferred, as returning an Enzyme wrapper can have
* unexpected results if the top-level rendered component is a Fragment.
Copy link
Member

Choose a reason for hiding this comment

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

Remind me: What are the unexpected results?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's imagine this case:

function MyComponent() {
  return (
    <>
      <label htmlFor="the-input">Label<span>
      <input type="text" id="the-input" />
    </>
  );
}

checkAccessibility({
  content: () => mount(<MyComponent />),
});

Internally, when an enzyme wrapper is provided, we do wrapper.getDOMNode() and mount that in an actual DOM container.

In this particular case, that will make the test fail, because only the label will be mounted, as getDOMNode() can only return one node, and the fragment is not a valid one.

On the other hand, if the component is passed as is, we internally create the enzyme wrapper attaching the result to the DOM (mount(wrapper, { attachTo: container })), which results in both the label and the input being properly mounted.

checkAccessibility({
  content: () => <MyComponent />,
});

I didn't know how to synthesize this in a single sentence 😅

Also, I can see other cases where this could also happen, like when a component returns an array of children instead of a fragment:

function MyComponent() {
  return [
    <label key={1} htmlFor="the-input">Label<span>,
    <input key={2} type="text" id="the-input" />
  ];
}

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 have updated the comment to:

Returning a VNode is preferred. An Enzyme wrapper for a component with a
top-level Fragment will result in the test being run for the first DOM
child node only.
Use the Enzyme wrapper only if really needed, and consider wrapping your
component with a `<div />` in that case.

@acelaya acelaya force-pushed the publish-type-declarations branch from 25a2a45 to e3d6a35 Compare October 26, 2023 14:32
@acelaya acelaya merged commit 7fd8b61 into main Oct 26, 2023
2 checks passed
@acelaya acelaya deleted the publish-type-declarations branch October 26, 2023 14:39
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