feat: async validation support #61
Conversation
|
@felangel @jorgecoca could one of you take a look at this PR? |
|
Sorry for the delay! I’ll have a look shortly 👍 |
Friendly reminder :) |
jopmiddelkamp
requested review from
renancaraujo and
wolfenrain
as code owners
|
Another friendly reminder :) @felangel @jorgecoca @renancaraujo @wolfenrain Would really appreciate it if one of you guys could free up some time to look at this PR and let me know if you agree or reject the change. Then I can focus again on getting the ugly temporary package out of my project.. |
|
Hi @jopmiddelkamp, sorry for the delay we will try to get to it this week! For now i'll at least run the workflows to validate if it also succeeds :D |
Thanks/bedankt @Wolferain! |
jopmiddelkamp
changed the title
|
Hello @jopmiddelkamp, Thanks for all that effort, and forgive us for the huge delay in responding 🙏🏽. After looking into the code and having a conversation with the team, we decided that async validation has use cases that may need a more careful look into. So we won't merge this. Thanks again for your contribution! |
| @@ -0,0 +1,6 @@ | |||
| import 'package:example/async/ui/app.dart'; | |||
There was a problem hiding this comment.
I appreciate the example app from a more "real world usage" point of view, but it defeats the purpose of the example of allowing people to understand what a package API looks like when used.
| final E? error; | ||
|
|
||
| /// The validation status of the [AsyncFormzInput]. | ||
| final AsyncFormzInputValidationStatus validationStatus; |
There was a problem hiding this comment.
With the validator being independent of the input class, there is no safeguard (and out-of-the-box clarity) on who should change this value.
The package usage becomes too much dependent on the boilerplate to work consistently.
| /// ``` | ||
| /// {@endtemplate} | ||
| @immutable | ||
| abstract class FormzInputBase<T, E> { |
There was a problem hiding this comment.
This is a nice abstraction from the premise that sync and async inputs would have different classes. That may not necessarily be the case. See this proposal.
|
@renancaraujo could this PR be taken as a base for a new one? Or better raise a new PR having this proposal in mind? |
|
@gugadev yeah, this is still on our backlog of things to do. The specifics of this pr (including the things exposed by comments) for sure will be base for the implementation. |
|
@renancaraujo I have made this one #93 as a initial setup to bring back to discussion if using FutureOr as mentioned by #15 (comment) is a good idea. I would appreciate more thoughts on how we can do the async validation. If we want to have FutureOr at the FormzInput abstract class we would force who is just using sync validators to use the await keyword as you can see at my initial PR. |
Description
I've added code to support async form validations.
Type of Change