It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

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

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).

For more information, open the CLA check for this pull request.

Hi @justinmc, thanks for reviewing the code.

1. Yes, we might have, is there a quick way to roll back?

2. Sure, we'll figure what exactly should be tested, I'm not sure we can have widget tests within flutter itself, right?

3. We'll have a look into it, I remember running into issues when trying to go that route, that's why we settled for a builder in the end.

4. I think it does make sense to have it for helperText as well, we'll have a look into it.

@justinmc upon further analysis on the current error implementation on both TextField and TextFormField, which both use InputDecoration, we consider the builder approach the better one as it doesn't brake the form validation logic.

We're working on adding tests and helperWidgetBuilder

Specifying an errorWidget instead of errorText seems sufficient, since the developer needs to specify one or the other for InputDecoration and if we allow an errorWidget to be specified, some apps may choose to just show an icon (or whatever) rather than a text message.

This PR reformats InputDecorator.dart; it should not. Please only change as much of the existing code as is necessary to make your change.

Note also: tests for this new feature will be needed.

+1 to the above. I'm not sure if there's an easy way to rollback the formatter changes or not. For tests, take a look at input_decorator_test.dart or maybe text_field_test.dart.

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.

@dancamdev @Michele-x98 Are you guys still available to finish this PR? Let me know if there's anything blocking you.

It looks like there is a merge conflict, but it's probably just due to the formatting changes in input_decorator.dart.

@justinmc I removed the change due to autoformatting and added the errorWidget property as proposed, so it is not possible to define both errorText and errorWidget. The tests are missing for the moment, I have defined them but without implementing them at all.

I like the idea to customise the style of an error messages in TextFields.

But with a simple errorWidget, I don't understand how it work with the validator of TextField? Can we stylise those messages too?

Shouldn't the API be like: Widget Function(String errorMessage) errorBuilder as proposed initially?

@xvrh That's the point, you can't. Now with the simple errorWidget you can just add something under the field and it is permanently showed, without the builder you don't have access to the error message string if that is not null. In the previous version that i proposed, the builder method allow to take the message error in input and handle it as you want, but as @justinmc and @HansMuller said, that logic works only if the widget is "linked" to the errorText, and if the errorText is Null, the widget is never displayed.

@Michele-x98

that logic works only if the widget is "linked" to the errorText, and if the errorText is Null, the widget is never displayed.

Unless I'm missing something, this is the behaviour we want.

And if not, then we can also update the builder to be Widget? Function(String? errorMessage) errorBuilder. So the user of the API can really decide what to do with and without an error message.

@xvrh I follow this logic above:

Specifying an errorWidget instead of errorText seems sufficient, since the developer needs to specify one or the other for InputDecoration and if we allow an errorWidget to be specified, some apps may choose to just show an icon (or whatever) rather than a text message.

But i think that it also works as you propose as well, maybe the function could be Nullable and the return type Widget not?

Widget Function(String? errorMessage)? errorBuilder

This make more sense to me.
Let me know if it's ok

any update on this?

I'm closing this due to lack of activity. If you decide to resume working on it, please reopen the PR.