RFC: useForm utilities props / improve existing clone #8030
Replies: 7 comments 7 replies
-
I see how that helps a lot with more complex data types and "unlocks" a better 3rd party data libs integration, per say. But I can't shake this thought that the problem here being solved is a problem about the lib internals that usually wouldn't be on the table for the users to vote on. What I mean by that is that thee issue of immutability isn't directly what RHF solves; it's about how the lib works and not the actual goal of the lib. All of my blabling is to say, maybe, we can do a kind of RnD and see how different libs of different or the same goal solve the immutability? Maybe it's not even for debate what RHF doing cloning objects? And I'm not trying to directly compare the experience different libraries have on the OSS field. If anything, I'm just laying my thoughts down to potentially spark some ideas about the topic :P That said, feel free to completely dismiss or ignore the comment, if it doesn't make sense to you. |
Beta Was this translation helpful? Give feedback.
-
Going to pause this RFC, the more I think about it the less I like the API. I will document the supported data type in the documentation for now. |
Beta Was this translation helpful? Give feedback.
-
An issue I'm currently having is: the instances of my class are being turned into plain objects. Maybe I could use this feature (not sure if there are any other workarounds currently). For example:
Thanks! |
Beta Was this translation helpful? Give feedback.
-
This is something that I'm running into constantly and am surprised that didn't have first-class support from the get-go. The result of this is that I have to write a lot of logic to transform data into the shape that I expect it to be when pulling out values from I don't think it's an uncommon use-case to want to store a Set of strings or a Mapping of string to object in the Form state if you're looking to keep a collection of values as part of the input data. I really do hope that this RFC gets picked up again and worked on as this is something I'm very keen on seeing in this library. |
Beta Was this translation helpful? Give feedback.
-
It seems to me that having complex types is a really common thing for anyone integrating this library with a complex form. Developers integrating the form don't always control the data types of each component they use, so flexibility in this end is (in my humble opinion) quite critical. In most major companies, there is a component library, usually developed by different teams and used by many, which makes it unfeasible to change the component data type in all the company verticals because RHF can't manage any kind of data type, while other teams might be using something else. Also, it is not clear at all what the user can do to deal with a complex data type (like DraftJS's EditorState, I opened #8214 to discuss this specific case). Is the user expected to serialise to string and deserialise again before using it to submit the form or validate? There could be an interim solution, even if hacky, while a better approach is thought. Exposing the cloning internals seems a bit strange to me, because it is not clear to me as a user why is the data cloned in the first place. But, if this is the only way forward, it'd work, and at least provide a way out for anyone stuck with this (like me). |
Beta Was this translation helpful? Give feedback.
-
Is there any progress on this issue? This is a great library and it seems like an unnecessary limitation. In my case I have a custom Date extension class which is currently being wiped out by the cloneObject implementation. It works fine when the value is changed (because my control returns the correct class) but if the value is not changed the class in submit data is wrong due to the clone. Having the ability to provide a clone override, or even a simple callback to inject additional logic ahead of the current logic would solve a lot of potential issues (mine included), and doesn't seem like it is either too much work to implement or likely to cause downstream issues (though obviously there may be complexities I'm not seeing) Happy to come up with a PR to implement this if it is a question of effort. |
Beta Was this translation helpful? Give feedback.
-
Any updates on this? |
Beta Was this translation helpful? Give feedback.
-
Context
To avoid internal mutation, react hook form internally clone any external state which gets a pass into the hook. The original goal is to cover usage on standard primitive form value. However, in some applications users are try to store external custom Object, Set, or Map into the library. (A good example would be a moment custom object.) Those data types are currently not supported.
Proposal
https://caniuse.com/?search=structuredClone is worth considering as well, but browser support is not great just yet. Maybe a v8 choice with polyfill at the app level.
check if the object is a plan object before cloning
https://github.com/jonschlinkert/is-plain-object
Props
Cons
Feature Request
#7279
PR
cc @Moshyfawn @kotarella1110 @jorisre @barrymay @felixschorer
Beta Was this translation helpful? Give feedback.
All reactions