I came to the same conclusion, but if this is true, then now I have multiple useFields instead of useStates, it is just omitting value and onChange. About the Type parameter, I think he wanted to also set the input type.
Yes you'd have multiple useFields, I think that's clearly the idea.
But it's not omitting value and onChange - instead, value and onChange are being expanded as props on the elements, so you're effectively linking the attributes on the input elements with function closures which are generated by the "useField" calls.
I still don't see the point of the type param, unless you'd end up with just:
<input {...email}/>
where the 'type' attribute is then also generated through the object expansion (the ... ellipsis).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I came to the same conclusion, but if this is true, then now I have multiple useFields instead of useStates, it is just omitting value and onChange. About the Type parameter, I think he wanted to also set the input type.
Yes you'd have multiple useFields, I think that's clearly the idea.
But it's not omitting value and onChange - instead, value and onChange are being expanded as props on the elements, so you're effectively linking the attributes on the input elements with function closures which are generated by the "useField" calls.
I still don't see the point of the type param, unless you'd end up with just:
where the 'type' attribute is then also generated through the object expansion (the ... ellipsis).