Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gracefully handle components with async behaviour #37

Closed
dariooddenino opened this issue Oct 26, 2018 · 2 comments · Fixed by #40
Closed

Gracefully handle components with async behaviour #37

dariooddenino opened this issue Oct 26, 2018 · 2 comments · Fixed by #40
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@dariooddenino
Copy link

Quick recap from the Slack conversation:

Right now the only way to handle inputs with async validation is to write some "external" logic, as there are two problems:

  • the validation is run every time the input field value changes
  • new validations are started even when the previous one didn't complete; there's no guarantee that they will complete in the same order in which they were launched

Just writing a random idea here, not sure if it's doable with the current library architecture:

Add the possibility to define "async fields", which are initialized by providing an optional debounce time (to avoid having the validation run at every input change).
These fields will carry a boolean value to keep track of whether the validation is undergoing, with a helper function for the user to extract this value (for example to show a loading gif or disable the field).

The form component could keep a record of optional debouncers that are initialized during the initialization of the component only for async fields. They would restart the timer on every input change, and when enough time would have passed without changes they would start the validation function.

I'm not sure whether it would be necessary to avoid multiple validations running at the same time, since with these changes this behaviour would become more explicit to the user.

As a bonus, I think this would make writing stuff like typeahead inputs trivial.

@thomashoneyman
Copy link
Owner

I'll have more to say later, but as a quick note:

the validation is run every time the input field value changes

This isn't necessary -- you could also just run modify on key press, and validate on blur (or modifyValidate on blur) to cut down on how often this validation is being run. That might mitigate some of the issues with expensive validations being triggered on each key press.

@thomashoneyman thomashoneyman self-assigned this Oct 26, 2018
@dariooddenino
Copy link
Author

dariooddenino commented Oct 29, 2018

It's a little better, but that means that no validation is run until a blur event is fired :/

This also make my hacky solution a little more awkward:

  , HP.disabled $ isloading $ F.getInput prx.userName form
  , HE.onValueInput $ HE.input $ F.set prx.userName <<< Success
  , HE.onBlur $ HE.input_ $ let
     val = F.getInput prx.userName form
     in (F.set_ prx.userName Loading) `F.andThen` (F.setValidate_ prx.userName val)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
2 participants