Rework userEvent.type

[ph-fritsche]

We've got multiple open issues regarding the implementation of userEvent.type.
And while a few people offered help on this, I've got the impression we're a bit lost regarding what the code should do and look like in general as well as how and where each smaller problem should be addressed.
I propose we collect those issues, discuss what we want to achieve and refactor and comment the code so that we get more confidence working on this.

• Typing on contenteditable userEvent.type on contenteditable #442
• Referencing characters by keyEvent.code userEvent.type: wrong keyCode for dot character? #456
• Handling activeElement changing to another element show warning when using userevent.type and blur() #460 / Fix #460 #487
• Preserving input over value sanitization userEvent.type not entering a space into inputs with type email #479
• Typing on non-input elements The type event doesn't work on elements without a value property #481 , Firing {delete} or {backspace} in situations that have no input text string #506
• Selecting on non-text input elements Problems with custom input types #501, Incorrect event.target.selectionStart value when using left arrow and backspace keys #515
• Default behavior on clickable elements onClick event fired twice by typing "{enter}" or "{space}" on button element #554
• Prevent default behavior and missing events on navigation keys Arrowleft handler does not respect preventDefault resulting in incorrect selectionStart #578

Should I have overlooked something, please mention it and I'll add it to the list.

What do people expect userEvent.type to do? What should it do?
While userEvent.click is very clear and intuitive to use as userEvent click this element!,
I guess userEvent.type started the same way userEvent trigger the key events to add to the value of this element!,
but I think most people expect it to be more userEvent press those buttons on the keyboard!.

I think it should resolve around document.getSelection() and userEvent.type(null, "a{del}{shift}b{tab}c{/shift}[Semicolon]d{selectall}") should be a valid expression to test handling of hot keys and similar.

One problem that comes to my mind is how to handle the keypress events as they are triggered multiple times as long as the button is pressed. Maybe a configurable random timeout between key events? So that even an expression for Press [A] and then press [B] before releasing [A]. Then release [B]. would make sense.

[sethreidnz]

This makes a lot of sense to me, I am keen to try to pick up some part of this as I mentioned yesterday but digging into the code, it is very much written with inputs in mind and it is a little unclear the best way to improve this... This looks like a great summary!

[ph-fritsche]

@kentcdodds Could you weigh in on this before we start any work here?

What do people expect userEvent.type to do? What should it do?
[...] I think most people expect it to be more userEvent press those buttons on the keyboard!.

I think it should resolve around document.getSelection() and userEvent.type(null, "a{del}{shift}b{tab}c{/shift}[Semicolon]d{selectall}") should be a valid expression to test handling of hot keys and similar.

[kentcdodds]

All userEvent methods should be: "fire all the same events that a user would if they were to perform that action." There's some subjectivity here. For example, in type, we fire some mouse and click events before typing, but some people might tab into the input rather than clicking on it. But in general we try to make the most sensible decision.

[ph-fritsche]

I guess it will be a step towards that premise:

• Keep userEvent.type(element, "foo", {skipClick = false}) for backward compatibility and as a shortcut which people are used to.
• Prefer userEvent.type(null, "foo", {skipClick = true}) to act on the activeElement right away.

value	meaning
a	{key: 'a'}
{shift}a{/shift}	press and hold {key: 'Shift'} press {key: 'a', shiftKey: true} release {key: 'Shift'}
[ShiftLeft]	{code: 'ShiftLeft'}
{[ShiftLeft]}[KeyA]{/[ShiftLeft]}	press and hold {code: 'ShiftLeft'} press {code: 'KeyA', shiftKey: true} release {code: 'ShiftLeft'}
{a}[ShiftLeft]{/a}	press and hold {key: 'a'} press {code: 'ShiftLeft'} release {key: 'a'}

• Provide key-code mapping for common US-QWERTY layout so that event handlers for both could exist at the same time.

[nickserv]

• Keep userEvent.type(element, "foo", {skipClick = false}) for backward compatibility and as a shortcut which people are used to.
• Prefer userEvent.type(null, "foo", {skipClick = true}) to act on the activeElement right away.

It's unusual to have an optional argument at the beginning, and I think it adds more confusion than it's worth when it represents something different. Perhaps we could name it userEvent.typeActive or userEvent.typeAnywhere?

[sethreidnz]

I tend to agree with @nickmccurdy. Would it make sense to think about the different types of thing a user is actually trying to do and approach them differently with a different API. Specifically

• typing in an input (current type functionality)
• pressing buttons as commands / keyboard navigation

I feel like there is some core functionality in there perhaps but all the assumptions of clicking first and things like that, don't make sense for someone pressing say shift + f to do a shortcut key in your app.

[ph-fritsche]

As all Testing-Library packages aim for readability of the test, exposing the same core functionality per two APIs makes a lot of sense.

@sethreidnz What exactly do you have in mind regarding the assumptions apart from clicking first?
I think after clicking and setting the range the implementation already tries to follow the actual behavior in the browser regarding movement of focus etc and different behavior is considered a bug.

[martin-watts]

I've spotted another issue with userEvent.type and number fields. I think the approach suggested (fire key events at a specific element/the currently active element) will probably fix it. Any approach where type is too knowledgable about the element receiving the events is likely to be flaky.

If it's strictly necessary, I'd suggest an optional callback to allow the default 'type next key' behaviour to be overridden.