You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current documentation seems to suggest that userEvent should be used almost always instead of fireEvent, but as others have called out, things like userEvent.type() are pretty expensive at scale. Heavy usage of that method may require overriding defaults (Jest timeout, userEvent's own delay, etc.).
A lot of developers are likely to take documentation as gospel... so can recommendations like this be reconsidered?
Most projects have a few use cases for fireEvent, but the majority of the time you should probably use @testing-library/user-event.
Suggested solution
Language suggesting fireEvent should be considered only a fallback solution seems to be dismissing test performance, and scale. Something more along these lines would make more sense in my opinion:
Projects writing mostly integration tests should prefer using userEvent over fireEvent, but that may require overriding test framework timeout defaults. However, projects that don't intend on changing any defaults, and don't require key-by-key emulation may need to consider if fireEvent is the more appropriate tool for the job when performance is a concern.
Or even something that mentions setting delay: null, as suggested by the aforementioned issue reviewer.
Problem description
The current documentation seems to suggest that
userEvent
should be used almost always instead offireEvent
, but as others have called out, things likeuserEvent.type()
are pretty expensive at scale. Heavy usage of that method may require overriding defaults (Jest timeout, userEvent's owndelay
, etc.).A lot of developers are likely to take documentation as gospel... so can recommendations like this be reconsidered?
Suggested solution
Language suggesting
fireEvent
should be considered only a fallback solution seems to be dismissing test performance, and scale. Something more along these lines would make more sense in my opinion:Or even something that mentions setting
delay: null
, as suggested by the aforementioned issue reviewer.Additional context
Consider this Typescript example:
The outcome:
The text was updated successfully, but these errors were encountered: