Why is Controller fieldState naming inconsistent?

[GollyJer]

In formState 👉 isValid - boolean - Set to true if the form doesn't have any errors.
In fieldState 👉 invalid - boolean - Invalid state for current input.

This threw me off a bit. Had to go to the docs to find the invalid return object.

Just curious if this is a purposeful difference, and if so what is the reason?

Best,
Jeremy

[Moshyfawn]

Hey, @GollyJer!

I've updated the API to include isValid convention for the field's validation state.

@bluebill1049 u can freely reject #8196 if the API is supposed to be different between the form validation state and the field's one

[bluebill1049]

Thanks, guys for the input. @Moshyfawn I think this will be introducing a breaking change to the existing version. This is actually by design, we have form level state isValid which leads by when the user subscribes to the form validity. For field level, at the moment we don't trigger every field input and flush down errors that include onChange mode, that's why the initial state of input will remain invalid as false unless an error state appears. I understand this is not a consistent API, but unless we start to support another form state such as validateFields, we will have to keep the API as invalid for now.

[Moshyfawn]

I see your point, @bluebill1049! It is a breaking change and having V8 on the horizon, I understand how inconvenient it would be.

Maybe we can re-visit the API consistency once the V8 is out the door.

One additional thing: what's the point of fieldState.invalid again? In docs it's usually show to check for the errors.fieldName and not much of fieldState.invalid usage. Is the invalid state really necessary?

{errors.fieldName && <p role="alert">{errors.fieldName.message}</p>}

[bluebill1049]

yes, @Moshyfawn let's deprecate that field state, I don't think it's server too much value. if you want to adjust your PR and point to v8?

[Moshyfawn]

Sounds good!