Open nighca opened 4 years ago
For now, I just do this as part of my bindField
utility:
interface Additionals {
onBlur?: (e?: React.FocusEvent) => void;
}
export function bindField<T>(fieldState: IState<T>, { onBlur }: Additionals = {}) {
return {
value: fieldState instanceof DebouncedFieldState ? fieldState.$.value : fieldState.value,
onChange: (value: T) => {
fieldState.onChange(value);
},
onBlur: (e?: React.FocusEvent) => {
onBlur?.(e);
fieldState.validate();
},
};
}
If onChange
doesn't require this workaround, then onBlur
might make sense too.
But if you do this, you might start getting requests for the possibility to turn it off (for some edge cases).
Thx for your feedback @mattleonowicz
It seems that in your sample code, validating will be automatically triggered both when blur and when change — something like validate-on-(change|blur)?
I thought if someone wants validate-on-blur, he may not want validate-on-change at the same time. While that's little difficult to workaround with formstate-x now.
But if you do this, you might start getting requests for the possibility to turn it off (for some edge cases).
Yeah you are right. Validate-on-blur, validate-on-submit & no-(auto)-validate, the three need to be considered together.
Now formstate-x uses validation-on-change mode (with debounce). Validation-on-blur is also a common use case. It is important to support such case officially.