Feat request: Add blur

[yuritoledo]

Just to add the fireEvent.blur()

:)

[Gpx]

Why do you need this if fireEvent.blur() exists?

I'm closing the issue but feel free to comment and we can reopen it we can come up with a good use case.

[yuritoledo]

Hi,

I think should be good, all kind of interaction in only one package.
To avoid multiple imports

[Gpx]

We might move user-event to the main package at some point but for now, it's better to keep the separated

[yuritoledo]

great.

[j-u-p-iter]

Hey, hey guys :) Hope you're doing well!

Why not just to move everything related to interactions to the user-event package and after it's ready to be merged with the main library - do it? IMO it's always great to have one common thing for one concrete purpose in terms of consistency.

[ph-fritsche]

Please keep issues separate so we can find and reference them easily.
@j-u-p-iter I moved your comment to #669

[ErlanBazarov]

fireEvent.blur() only triggers onBlur event, right? It doesn't actually remove focus from the element. We need userEvent.blur() that would actually behave realistically (trigger onBlur event and remove focus from the element)

[ph-fritsche]

@ErlanBazarov userEvent is all about simulating user interaction. The occurring blur is just something that happens along the way.
Try "clicking somewhere else" like a user would do. 😃

[yuritoledo]

Do not get me wrong, but I think that the code of "click somewhere else" will not be readable

[ph-fritsche]

Why not?

userEvent.click(document.body) // move the focus away

[yuritoledo]

Is it not semantic.

Maybe it can be clear for who wrote it, but not for other developer or yourself in future.

[ph-fritsche]

I'm sorry, but I fail to understand the issue or the proposed solution here.
If you want to simulate that a user moves the focus away by clicking somewhere what could possibly be semantically closer than clicking somewhere?

If you want to test against an implementation detail, i.e. the blur event, there is already fireEvent.blur(element) for this.
If you want to just perform the blur, you could also keep it even simpler and just go:

element.blur()

So which abstraction should a userEvent.blur API provide?
All our APIs strive to be readable as "simulate that a user does...", but a user can not perform blur on a specific element.

[yuritoledo]

I disagree. The user can perform the blur event pressing tab for instance.

I think should be nice to have the .blur() in this library just to group all the user behavior in one package, just for the DX.

If I do userEvent.click() or userEvent.type(), why not userEvent.blur() ? instead of fireEvent.blur()
In other words: "If I use useEvent for clicking, typing, and whatever, why not using it for blur too?"

[ph-fritsche]

That is exactly the problem with such an API in this package. The user can trigger a blur e.g. by pressing [Tab].

So should your proposed userEvent.blur() API trigger a keydown event for the Tab key on the element and a keyup event for the Tab key on the next element in tab order?
Where should the focus be moved?

The user could also press [Alt]+[Tab] and the active element would stay the same, but a blur event would occur as well as a focus event when the user switches back.

How do we determine the correct behavior? Currently our standard is to perform the action described by the API call in the browser. But I fail to see what the reference action in the browser should be that I would perform to determine if our implementation is correct.

[RachitSharmaHS]

If userEvent.click(document.body) is not semantic enough, how about userEvent.keyboard('{esc}'). It is a direct user action (unlike blur) and you wouldn't use to to shift focus explicitly to something else.

Edit: Unfortunately, it looks like userEvent.keyboard('{esc}') doesn't actually trigger the blur event. Maybe it should?

[Saddage]

Hey, I've just stumbled upon this issue. What was the fix for me, without using fireEvent was to call userEvent.tab(). I think it is ok, as the focused element loses its focus due to the user clicking the Tab button on their keyboard. This simulates real user's behavior in a way how could they actually blur the element.

[ScubaDaniel]

Why not?

userEvent.click(document.body) // move the focus away

This doesn't work for me. It just times out with user-event version 14.

[ph-fritsche]

@ScubaDaniel In v14 all interaction APIs return a promise that you should await.

If you use fake timers in your test suits, have a look at https://testing-library.com/docs/user-event/options/#advancetimers