Fixes #11068 with error widget - #118610

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Hello @KishanBusa8 and thank you for your contribution. Looks like its a much asked for feature! I'm happy to give you some feedback and try to get this merged.

For some context, this feature has been proposed before #104165 . And there was some discussion around errorWidget vs errorBuilder.

It seems to me that errorWidget covers all of the use cases that we might want to cover, is there any added functionality given by a builder? I think a user can either provide an errorText or an errorWidget and not both. If a user wants custom text in their error, then they can make a custom text widget with their changes and provide that as the errorWidget. Is there any cases this doesn't cover?

Hey, @Renzo-Olivares Thanks for your time.
I think you are right we might need to use errorWidget instead of the builder. I'll add this change in the next commit.
Thanks!

Hey, @Renzo-Olivares As per your comments I resolved all the changes and replace errorBuilder with errorWidget. you can check it on above commit.
Thanks!

Hello @Renzo-Olivares Thank you for your time.
I have updated the PR title and description as per your suggestion and also completed the changes which you have suggest. You can check the new commit and Please let me know if we need any fixes.
I really appreciate your help.
Thanks :)

If you take a look at the diff in the "Files" tab here on GitHub, you'll see that there are now a lot of changes happening that are to the formatting of other unrelated parts of the file. You'll want to undo those changes.

In general it's a good practice to look at the exact diff you've submitted, and remove any changes that aren't intentional. (Several of the nits above were in this category.) You can do that in the GitHub UI, or you can do it with Git on your own computer. Doing it with Git become easier if you follow the advice in the wiki to not use merge: https://github.com/flutter/flutter/wiki/Tree-hygiene#using-git

Hello @gnprice ohh I thought I enabled auto formate on save by mistake I’ll revert the commit and update you in some time.
Sorry about that..:)

Cool. Everything in the PR now looks great as far as I'm concerned.

Hello, @gnprice and @Renzo-Olivares Thank you, guys, for your help and support.
If all is good then what's the next step as this is my first PR I don't know.
Thanks!

This PR went with errorWidget instead of errorBuilder. How will it not work with TextFormField.validator?

I would like to customise/stylise errors produced by the validator. How can I do it?

@xvrh That's a good point. Currently if validator is defined then the String from the validator overrides the InputDecoration.errorText.

If this was an errorBuilder instead that would mean that the widget needs to be linked to the errorText to grab the validators text.

An errorBuilder makes sense to me, but I also think theres another option. Maybe adding a validatorBuilder that overrides InputDecoration.error in the same vein that validator overrides InputDecoration.errorText.

Any thoughts on this @gnprice @KishanBusa8 @xvrh?

@Renzo-Olivares thanks for the consideration.
I think the best api is to have a Widget Function(String) errorBuilder property on InputDecoration. This callback allows to convert any InputDecoration.errorText to a widget.
It gives the developer a way to stylise the error message produced by the validator (ie. wrap the Text in a DecoratedBox). This is one of the most important use case for me.

Ah, excellent point.

I think the best api is to have a Widget Function(String) errorBuilder property on InputDecoration. This callback allows to convert any InputDecoration.errorText to a widget.

I like this suggestion.

Thank you, guys, for your help and support.
If all is good then what's the next step as this is my first PR I don't know.

In general the answer is: wait for additional reviews. See the Tree hygiene wiki page (which you should definitely read when contributing code to Flutter):

Expect that a new patch will be reviewed within two weeks, unless it is fixing a P0 bug in which case it should be reviewed the same day. If it has not been reviewed in that timeframe, reach out on Chat. Remember that reviewers are human beings with additional professional and personal responsibilities.

So waiting a few days is quite normal.

Relatedly, there's generally no need to merge the master branch back into your PR. If there's an actual merge conflict, then that can be helpful for resolving it, but otherwise there's generally no benefit to doing so.

I can think of several options to make it work with TextFormField.validator

Option 1

• Add Widget error in InputDecoration (this PR)
• Add Widget Function(String)? errorBuilder in FormField
• Apply the errorBuilder to the error message produced by the validator like this:

var errorText = field.errorText;
var errorBuilder = field.widget.errorBuilder;
var effectiveDecoration = decoration.copyWith(
    errorText: errorBuilder == null ? errorText : null,
    error: errorText != null ? errorBuilder?.call(field.errorText) : null);

return TextField(decoration: effectiveDecoration);

Option 2

• Add Widget error in InputDecoration (this PR)
• Add a validator variant: Widget? Function(String? input)? validatorBuilder in FormField. It allows to replace the classical validator with a version that can return a Widget instead of a string.

This is the idea of @Renzo-Olivares above

Option 3

• Add Widget error in InputDecoration (this PR)
• Change the type of validator to something like Object/*String|Widget*/? Function(String? input).

Option 4

• Add Widget Function(String)? errorBuilder on InputDecoration which when not null is called to convert errorText to a Widget.

For option 1, it looks like if the errorText is null (this can be because no validator is defined or no InputDecoration.errorText is defined) there will be no error widget displayed even if an error is defined in the InputDecoration given to TextFormField. Let me know if i'm missing something here.

That seems different from how it works now where even if errorText is null in the InputDecoration given to TextFormField, the validators error text would still show up/ if there is no validator, but an errorText is given then the errorText still shows up.

I think this new API should follow the notion that validator is an overrider for InputDecoration.errorText, so validatorBuilder should be an overrider for the InputDecoration.error. cc @justinmc if you had any thoughts on this API discussion.

I like option 2 (Renzo's) and I like the name validatorBuilder. Also I think that validator/validatorBuilder and error/errorBuilder should have assertions so that only one is allowed at a time, i.e. if you pass both validator and validatorBuilder then you get an error.

@KishanBusa8 Thanks for your contribution! Will you be able to continue working on this? It's totally fine if not; we can take it over (though it might take longer). I'm just asking because I'm trying to clean out our review queue.

Since we haven't heard back from @KishanBusa8, let's close this in favor of #129275. Thanks for helping us get to a solution regardless!