Size Change: -138 B (-0.24%)

Total Size: 58.6 kB

_{compressed-size-action}

could I know what's blocking this?

could I know what's blocking this?

I will need more time to get to it and then release an RC version of it later.

I have found an issue in the latest beta version where formState from useFormContext and useFormState inside of a nested component is memoized incorrectly by the compiler and doesn't trigger re-renders.

Minimal example to show the issue: https://codesandbox.io/p/devbox/q3kgmx?file=%2Fapp%2Fpage.tsx

Press the submit button. The form shouldn't submit because of an error, but the Component doesn't reflect that there's an error.

I have found an issue in the latest beta version where formState from useFormContext and useFormState inside of a nested component is memoized incorrectly by the compiler and doesn't trigger re-renders.

Minimal example to show the issue: https://codesandbox.io/p/devbox/q3kgmx?file=%2Fapp%2Fpage.tsx

Press the submit button. The form shouldn't submit because of an error, but the Component doesn't reflect that there's an error.

<FormProvider {...form} formState={formState}> we will have to do this unfortunately.

id has made most of the complain over the years, key is a reserved keywords for react props make more sense to migrate over.

key is reseved in react, yes, but it isn't reserved in js or on the server. I think that just doing {key: string; value: T} instead of T & {key: string} is a more elegant and robust solution overall.

Also, I wonder if its the only reason why in the current implementation you coundn't use useFieldArray on an array of primitives? If so, it would be cool to get this functionality. We have multiple places in our apps, where we have to first make array of objects out of array of primitives to pass it to default values and than do the reverse on validation step. It is one of the pain points of using this library for us.

It would be cool to see this fixed in v8

as for watch(), we have a relatively large project which uses rhf heavily and we've been able to migrate all our code to use useWatch in components bodies and getValues in callbacks and effects. Maybe its just our experience, but I cant imagine a case where it would be beneficial to use watch(). And I wounder if those potential cases could be easily and more idiomatically accurately be solved with formData.subscribe()?

id has made most of the complain over the years, key is a reserved keywords for react props make more sense to migrate over.

key is reseved in react, yes, but it isn't reserved in js or on the server. I think that just doing {key: string; value: T} instead of T & {key: string} is a more elegant and robust solution overall.

Also, I wonder if its the only reason why in the current implementation you coundn't use useFieldArray on an array of primitives? If so, it would be cool to get this functionality. We have multiple places in our apps, where we have to first make array of objects out of array of primitives to pass it to default values and than do the reverse on validation step. It is one of the pain points of using this library for us.

It would be cool to see this fixed in v8

I fully agree. I also think it’s more intuitive to return the defined value rather than a modified object with an added key. This way, the value reference can be preserved as well (though that would also be possible when adding the key property).