New rule: prefer-user-event

[timdeschryver]

When testing-library/dom-testing-library#616 gets merged, userEvent will be part of DOM testing library.

We could create rules for events on userEvent that are preferred over their fireEvent counterparts.

Before we start implementing rules, there are some thing we need to clarify first:

• Kent already mentioned click would be a good candidate, are there any others that could benefit from this rule? I think hover, unhover could also be included in within this rule.

• Should it be one rule for all events, or a rule per event? The latter would allow us to disable/enable specific events... but we could also create a config for it...

[Belco90]

Nice proposal Tim.

• To be honest, click was the only obvious one that came to my mind. I guess we will need to check proper user-event docs or wait for testing library docs to be updated to make sure about which methods we should cover.
• My personal preference would be a single rule to encourage userEvent methods over fireEvent ones. As you mentioned it could be useful to have rule per event method, but we can get that with proper rule config. I think with a single rule is clearer that userEvent wraps fireEvent. Any other potential cons a bout having this in a single rule?

[gndelia]

Should it be one rule for all events, or a rule per event? The latter would allow us to disable/enable specific events... but we could also create a config for it...

I'd go for a single rule to prefer one over the other. Kent mentions some stuff that you might only be allowed to do with the primitive, perhaps we could let the user configure for those methods that are present in both which ones should be allowed to be used with fireEvent?

[Belco90]

We should keep am eye on this issue for having more info/context testing-library/dom-testing-library#616 (comment)

[timdeschryver]

That's a good idea @Belco90

[nickserv]

The merge into dom-testing-library has been cancelled, but it would still be nice to have this rule to inform users about when they should be using the user-event package.

[gndelia]

@nickmccurdy I've read about the recommendation of using user-event instead of fireEvent because it better represents how the browser really behaves - and that fireEvent is perhaps on a lower level.

I like the idea of the rule, but could you point out some docs or relevant information to further understand the difference between these two? I am not sure if there are stuff that can only be achieved with either, or if the rule should just go with a simple "if using click on fireEvent, recommend using userEvent instead".

Thanks

[nickserv]

I like the idea of the rule, but could you point out some docs or relevant information to further understand the difference between these two?

For the most part, it's adding related event calls from browsers to make tests realistic, along with adding some convenience APIs to make calling these events easier. Overall the goal is to make testing like a user both easier and more accurate than calling low level fireEvent methods. See the user-event API documentation for more detailed information.

I am not sure if there are stuff that can only be achieved with either, or if the rule should just go with a simple "if using click on fireEvent, recommend using userEvent instead".

For the most part, we should be recommending any rules in fireEvent that are used in user-event APIs with these higher-level user-event APIs. There are exceptions for unsupported events, which I'd like to allow by default, and having to customize how existing supported events are called at a lower level with fireEvent, which you could do by simply disabling these rules inline.

[nickserv]

@Belco90 I added this to the v4 milestone, do you think it's a good idea or would you rather wait until more events are added to user-event? We have already added a bunch recently though.

[Belco90]

@Belco90 I added this to the v4 milestone, do you think it's a good idea or would you rather wait until more events are added to user-event? We have already added a bunch recently though.

I'd like to include this, but I'm afraid this could delay v4. Do we have clear then about what we want to include in this rule? If so, I'd include it in v4 as optional. If we have everything but this ready for v4 I'd release it and then include this in a potential v4.1. Sounds good?

[nickserv]

Do we have clear then about what we want to include in this rule?

I thought we agreed on adding one new rule that would check all events that should be used with user-event by default, with a config to toggle them individually. That being said, I'm not sure if we'd want to have distinct options for banning the user-event event vs just allowing both (most ESLint rules seem to use string literals for this).

If so, I'd include it in v4 as optional. If we have everything but this ready for v4 I'd release it and then include this in a potential v4.1. Sounds good?

👍

[Belco90]

LGTM