validate on input with debounce

[luca-peruzzo]

additional validation on typing for text inputs. It has a debounce of 300ms

[garronej]

Hold on.
There must be something I'm missing here.
Since the form is fully controlled, adding a 300ms debounce should cause a 300ms delay between the user input and seeing the field beeing updated.
Aditionally there are some auto formating of the input value that requires the dispatching of the form action to be synchronous.

Example: https://youtu.be/lMOLrdqilqE?si=JwKzNQHuTK9cLmpL&t=335

[luca-peruzzo]

Hold on. There must be something I'm missing here. Since the form is fully controlled, adding a 300ms debounce should cause a 300ms delay between the user input and seeing the field beeing updated. Aditionally there are some auto formating of the input value that requires the dispatching of the form action to be synchronous.

Example: https://youtu.be/lMOLrdqilqE?si=JwKzNQHuTK9cLmpL&t=335

ok we could remove the debounce time if it is needed, but the point is that on standard text input, validation is fired only on change listener, this means that it fires only when the element loses focus: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event

[luca-peruzzo]

For example, in register.ftl if I fill the form completely and correctly, after writing the Last Name input the button remains disabled until a blur event.

[garronej]

This means that the event triggers only when the element loses focus.

In the case of Keycloakify, it depends. Some fields are validated immediately upon change, as the user type, while others are only validated after focus was lost once then they are validated in realtime. The way I designed the API is to abstract away those details. The user is responsible for dispatching both the "focus lost" and "change" events—everything else is handled internally (like what errors should be displayed on what field and what is the current value of the inputs).

If you believe the default behavior should be adjusted, I'm open to hearing your arguments. However, this change should be made within Keycloakify itself, not in @keycloakify/angular, which would idealy be an Angular adapter.

Let me know if your suggestion is motivated by performance considerations, UX improvements, or if something isn't working as expected. Is the behavior you're trying to address observable in Keycloakify for React?

I'm looking forward to your thoughts.

[luca-peruzzo]

This means that the event triggers only when the element loses focus.

In the case of Keycloakify, it depends. Some fields are validated immediately upon change, as the user type, while others are only validated after focus was lost once then they are validated in realtime. The way I designed the API is to abstract away those details. The user is responsible for dispatching both the "focus lost" and "change" events—everything else is handled internally (like what errors should be displayed on what field and what is the current value of the inputs).

If you believe the default behavior should be adjusted, I'm open to hearing your arguments. However, this change should be made within Keycloakify itself, not in @keycloakify/angular, which would idealy be an Angular adapter.

Let me know if your suggestion is motivated by performance considerations, UX improvements, or if something isn't working as expected. Is the behavior you're trying to address observable in Keycloakify for React?

I'm looking forward to your thoughts.

I think this is a misunderstanding. It is now impossible to validate an input when the user is typing. There is only a listener on the change event and it is only fired when the focus is lost. There is no need to change anything in the lib because it is an html event listener callback, but the code inside is the same (it must send an update event).
The addition of an input event listener (only for input types that support it) is only an advantage.
I don't know if the onChange event in react works differently, but angular respects the DOM specification and so the change event works as specified