Dom-testing-library: typing

[icfantv]

• dom-testing-library version: 3.12.3 (but probably all)
• react version: N/A
• node version: N/A
• npm (or yarn) version: N/A

Relevant code or config:

// for example
fireEvent.keyDown(element, {...}) // second arg is KeyboardEvent, but is currently typed as a generic object.

// additionally
fireEvent(element, {...}) // second arg is typed as `Event` which might also be too generic.

What you did:

Using the fireEvent.xxx methods results in a generic options object (read: not typesafe) that defines the underlying event options.

Additionally, using the fireEvent(element, ...) function, the second argument is of type Event which might not be specific enough.

What happened:

Due to the generic nature of the event typings, there's no structure or typesafety in the event config object. This results in the user being allowed to specify deprecated, or even non-existent, properties. E.g., here is the typing for KeyboardEvent's configuration options KeyboardEventInit:

interface KeyboardEventInit extends EventModifierInit {
    code?: string;
    key?: string;
    location?: number;
    repeat?: boolean;
}

For brevity, I won't paste the entire inheritance chain here, but suffice it to say that the typings no longer include, for example, either keyCode or which due to them being deprecated (source: keyCode, which).

Problem description:

Having a generic options object still allows for their usage, and the event docs still "suggest" using the deprecated properties. For a library arguably centered around promoting best practices, it seems like this might be wrong, or at the very least discussed.

Suggested solution:

My advance Typescript typings knowledge requires some more research, but tying the fireEvent utility's event types to specific typings based on the type of event represented seems like a reasonable, if restrictive, solution. See next section for issues with this approach and for possible mitigation.

Issues with suggested solution

All that said, there are almost certainly ample web applications out there still using deprecated keyboard event properties so restricting the options as I suggested would be a breaking change. Perhaps this could be mitigated if there were a way to make fireEvent generically typed so that the developer could optionally specify a structure for the options argument with the default being the currently used Event object. Additionally, the shorthand fireEvent.xxx methods might also be generically typed in a similar fashion (however, currently, the second argument is typed as a generic object).

The documentation should also be updated depending on the implemented solution, if any.

[icfantv]

@kentcdodds, I'll probably have time next week to start looking at an optional generic typing solution if that's the route we want to go - at least in that direction, it wouldn't be a breaking change because we could always fall back to the current behavior. Thoughts?

[kentcdodds]

I think whatever the solution I'd prefer to not break existing people (for now). Let's make the improved typings opt-in via generics if we can.

[icfantv]

I haven't forgotten about this. It's still on my radar.

[kentcdodds]

Closing this for inactivity. If someone wants to work on it in the future feel free to open a new issue. Thanks!