I appreciate you opening a PR to start a discussion on this. I agree that this kind of validation logic could be easier in Flutter, but I'm skeptical about adding this new parameter unless we're sure it's going to be worth it.

How is this better than the approach that I mentioned in the comment that you linked above? I've update the dartpad here so that it runs on modern Flutter versions: https://dartpad.dev/?id=b8c96286ae3d35c47c202123197ff6a0

Hey @justinmc, Thank you for taking the time to replay and update the example.

I think this is a better approach for two reasons actually. The first one is we don't have to set autovalidateMode to always. The second is we keep the validator function more isolated or use any pre-made library for validation that integrated well the Validator signature, and not go through the hassle of saving the old value and check it to make the api call, and then use setState with autovalidateMode set true to make the validation runs on rebuild.

Your approach is nice, but that's only because we're using in it in a statefull widget and relying on setState, and assuming the error would only happen form isUserNameAvailble endpoint. I remember when you first commented this approach, and I've been using it ever since, but it will become very hard when the error could be an predictable and using any state management solution, especially the point where we store the previous value to compare it against the new one and forcing a rebuild with setState.

With the approach that I'm suggesting, we can simply let our service (remote service, repo, controller etc..) handle the possible error that we would have, wrap the text field with say a blocBuilder to force the error state to a specific field when it happens.

This is important because we are not limited to just checking for a username, sometimes the api can still return a validation error even if the user pass the validation on mobile side. For example this is something happened to me recently, a long form that the user must submit it with his credit card number, but for some reasons there is a problem with that particular card. so it would be nice to be able to force the error to that particular field with an error message coming from the backend.

Please note that this kind of approach is not new to flutter. The InputDecoration class has a property called errorText to force the error, but the problem is, it only forces it on the field decoration and the FormField, so calling validate() will still return true even if the decoration is showing an error.

here is a snippet:

...
 TextFormField(
        decoration: InputDecoration(
             errorText: 'Forcing error to decoration',
         ),
...

Would you be able to post a full code example of the credit card case you mentioned, and/or the case of using bloc?

I'm actually on board with you that being able to simply provide error text to display unconditionally is a more simple and declarative pattern than what we have now. However, I want to make sure we don't bloat the API into having multiple ways of doing things. If what we really need is a bigger refactor or a breaking change then maybe we should take the time to plan that out instead.

I'm interested to look at those other code examples if you don't mind writing them, though!

I'm not sure if I can provide the full code of the credit card case, but I can write some example to demonstrate more the cases that I have mention. Will be working on them and update the thread here.

hey @justinmc, I've just created a small example, I tried not to use any library so you can able to check it on dart-pad (idk if dart-pad support using external libraries).

here's a link for the example on dart pad.

Now here, you may find it a bit confusing. But Riverpod/Bloc has a very nice way of filtering the state changes. But I couldn't simulate it without spending too much time.

 ValueListenableBuilder(
            valueListenable: service,
            builder: (context, value, child) {

              // this is the normal field without forcing any error.
             // it is here just to clean up the code a bit.
              final normalChild = _Field(
              controller: creditCardController,
              label: 'Credit Card',
              validator: Validators.creditCard,
            );

            return value.maybeWhen(
              orElse: () => normalChild,
              error: (type, message) {
                return switch (type) {
                 // filtring the error state related to cred card field to get
                // the error message if any.
                  ErrorType.creditCard => _Field(
                      controller: creditCardController,
                      label: 'Credit Card',
                      validator: Validators.creditCard,
                      // here I used the `errorText` property to simulate adding my suggestion to `FormField`
                      forceErrorText: message,
                    ),
                  _ => normalChild,
                      };
                    },
                  );
                },
              )

you can see in submit method that I saved a lot of boilerplate relating to caching the previous validated data
in order to run the validator again, and didn't be forced to use auto validation mode.

Future<void> submit() async {
    if (!_formKey.currentState!.validate()) return;

    // the approach I suggested won't let me register again when there is an error,
    // as the error would be forced to the [FormField] making the `validate` function return `false`.
    await service.register(
      username: usernameController.text,
      password: passwordController.text,
      creditCard: creditCardController.text,
    );
  }

The basic idea is to register a listener that will only be triggered if there is an error in an exact text field, so it will be rebuilt again with a forced error text.

this way we keep the logic for backed errors handling encapsulated in a (service, controller ..etc) and the ui will only be responsible for listening to any state change.

I think this way will give the developers more freedom on deciding how they would handle errors rather than sticking with one approach that can look like a work around.

Here is the link to the full flutter project on github link

hey @justinmc had you got the time to review this?

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Somewhat related: #54104