@ashank96 Related discussion at #48155

cc: @justinmc

@SpajicM @justinmc

This PR is easily the simplest (maybe even best) solution to that particular issue where autovalidate is not supposed to show error when screen is rendered for first time.

The discussion at #48155 is part of a bigger issue and about having more control over validation and an entirely different way of handling it. I'm not fully sure if that is going to be merged anytime soon.

In the meanwhile, this PR serves as the right fix for the initial render error text issue.

@SpajicM @justinmc
It's very rare to have a scenario where autovalidate would be needed at the initial state itself. Mostly, we would want it only when user has tried to change some value in the field.

Hence, as @nateshmbhat seconds, this issue is quite common across all the firms/developers who are using forms in production, and needs an update on this as soon as possible. This PR can be a small but useful fix to the same.

@ashank96 @nateshmbhat I totally agree, I only linked the other PR for informational purposes.

@justinmc Can you please review the PR ? TIA.

Sorry for the delay in taking a look at this and thanks for opening a PR. This is going to be tricky because it skirts the definition of a breaking change (see Flutter's breaking change policy). I have been trying to avoid changing this behavior directly because it seems to me that there could be apps that are relying on this behavior.

I'm going to try to get a conclusion on the discussion of how to fix this long term (started in #48155). If that solution allows for changing this behavior then I can try to check if this change would break anyone's app and figure out a way forward.

I'll try to post back with updates.

If we're concerned about the breaking change, May be we could add an additional optional parameter (say validateOnFirstBuild) which defaults to true for backward compatibility.

But honestly, I feel we need to fix this even if it's a breaking change because this behavior is not something 99% would want.

Adding a flag like that again just for backward compatibility (which was in fact a bug) is like not taking care of the bug in some way.

What if a developer wants to validate when the overall form is submitted, and the user submits the form but never focused or changed a field? I think it unexpectedly wouldn't show an error message for the field. That case should be handled.

@justinmc Regarding your concern, before the developer calls formstate.save() for the whole form without changing any value, he will obviously call formstate.validate() which will take care of the full form validations even if the value is not changed or field is not focused.
As following function will be called, which does not take into account the current changed state flag anyways:
bool validate() { setState(() { _validate(); }); return !hasError; }

Another thing to think about is the form.autovalidate which is doing the same thing except it only validate after the second build.

@ashank96 I'm going to close this PR as it looks like #56365 will achieve the same thing and is closer to being merged. Take a look at that PR and let me know if it meets your needs and if there's anything that this PR covers that that PR does not.