Unify "Firing Events" page

[afontcu]

Same thing as #485.

Event firing utilities are mostly "universal", so they could live above DTL docs.

[MatanBobi]

I'm up for this one :)

[MatanBobi]

Hi @afontcu, @kentcdodds.
I saw Kent's tweet a few days ago about "how to know which event to fire".

Do you think a reference to this app or maybe even gathering up this to an example page is worth doing within this task?

Also, do you think we should build a "General"/"Universal" section? Or do you think it's related to "Getting Started"?

[kentcdodds]

I think we're ready to start getting PRs ready to document user event as an official export to @testing-library/dom (importable via import {userEvent} from '@testing-library/dom')

Most of the docs from the original repo can be copied, but there are some improvements I think we should make:

1. No test-ids
2. If we can help it, less contrived examples. We can use imaginary components (similar to the "Tooltip" component I'm using in the hover example)

Off the top of my head, here are some of the differences (though someone should probably do an accuracy check with the PR testing-library/dom-testing-library#616):

1. toggleSelectOptions has been removed in favor of deselectOptions/selectOptions
2. type will now automatically close modifiers (unless skipAutoClose is specified)
3. type no longer supports allAtOnce (people should use paste which is coming soon)
4. blur and focus are new supported events
5. EVERYTHING is now async (user's can't synchronously fire one event after the other, so neither should our tests)
6. type now supports {del} (delete forwards) and {selectall} (and incidentally, clear is basically a shortcut for this)

I'm sure there are things I'm missing, but if someone could get this started, that would be phenomenal!

[afontcu]

Thanks, Kent! That's great news.

If we can help it, less contrived examples. We can use imaginary components (similar to the "Tooltip" component I'm using in the hover example)

Totally agree. If possible, all code examples in docs should be based on "real" components, instead of foo, bar and so on. Bonus points if we unveil concepts and feature by using and growing the same component. It'd mean less cognitive overhead for readers.

• EVERYTHING is now async (user's can't synchronously fire one event after the other, so neither should our tests)

I gotta say this makes me extremely happy – one less difference to worry about between React Testing Lib and Vue Testing Lib ❤️

---

I wonder if docs should still mention fireEvent for advanced use cases (at the end of the page or something). I'd say userEvent will not cover each case on day 1, so mentioning that fireEvent is there might make sense.

[kentcdodds]

@nickmccurdy, only bug fixes will go into user-event for the next little while. No new features or even improvements to "correctness".

@afontcu, I agree. fireEvent should definitely still be documented for advanced use cases and edge cases. But we should consider user event as the default eventing mechanism.

[afontcu]

Ok, so it looks like user-event is not getting merged (yet, hopefully!) into DTL, so we're back to the original plan 😇 testing-library/dom-testing-library#616

[MatanBobi]

Hopefully it will get merged, but for now it looks like @jacobparis have done some work on this in his PR #502, let's just try to keep them aligned with all the other "universal" work we're doing in #489 and #485

[MatanBobi]

@alexkrolick I think we can close this one also after #735 was merged, wdyt?