You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've brought up a few feature requests and issues related to issues with using shallow copies on form values. Since I haven't seen many updates here and I continue to face issues regarding this, I wanted to see if anyone else shares these issues and if a more inclusive feature request should be made. Here are my issues:
getValues and watch return a reference to its internal form values rather than a deep copy. This means if for any reason you modify this reference (accidentally or intentionally), you will change the library's internal state rather than just the object it returns.
The same issue occurs with setValue. If I pass in some new form values to setValue and then change that object for any reason, I am changing the internal library state.
Lastly, it makes working with libraries like immer that use the frozen object feature much more unpleasant. immer is a very popular library and I use it often to modify my form state when I'm working with arrays and nested data. For example:
const currentArrayValues = getValues().someArray
const newArrayValues = product(currentArrayValues, draft => {
// make some modifications
})
setValue('someArray', newArrayValues)
The problem is I'm now passing a frozen object into hook form which will cause a crash.
My current workaround for all this is to use the lodashcloneDeep method every time I'm setting data or retrieving data that will be used for a new object (like in 3 above). I'm always facing crashes in places where I didn't use cloneDeep in the right location and it makes the code much messier.
It would be great if there was some option to have the library only work with immutable data. So anytime we pass an object in or get an object back it's a deep copy. This way we wouldn't have to worry about any of these issues. I get that this leads to worse performance, but I'm totally fine with that for my use case. It would obviously be disabled by default.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've brought up a few feature requests and issues related to issues with using shallow copies on form values. Since I haven't seen many updates here and I continue to face issues regarding this, I wanted to see if anyone else shares these issues and if a more inclusive feature request should be made. Here are my issues:
getValues
andwatch
return a reference to its internal form values rather than a deep copy. This means if for any reason you modify this reference (accidentally or intentionally), you will change the library's internal state rather than just the object it returns.The same issue occurs with
setValue
. If I pass in some new form values tosetValue
and then change that object for any reason, I am changing the internal library state.Lastly, it makes working with libraries like
immer
that use the frozen object feature much more unpleasant.immer
is a very popular library and I use it often to modify my form state when I'm working with arrays and nested data. For example:The problem is I'm now passing a frozen object into hook form which will cause a crash.
My current workaround for all this is to use the
lodash
cloneDeep
method every time I'm setting data or retrieving data that will be used for a new object (like in 3 above). I'm always facing crashes in places where I didn't usecloneDeep
in the right location and it makes the code much messier.It would be great if there was some option to have the library only work with immutable data. So anytime we pass an object in or get an object back it's a deep copy. This way we wouldn't have to worry about any of these issues. I get that this leads to worse performance, but I'm totally fine with that for my use case. It would obviously be disabled by default.
Beta Was this translation helpful? Give feedback.
All reactions