Continuing #58 .
@pauloabmiranda suggested having setXX's accept a path to field to be updated a la Lodash's _.set
method.
Currently _.set
is mutative, an so we either need to copy state first and then call it on the copy or come up with a different implementation
Lodash has not mutative version of all methods, it is the FP version.
https://github.com/lodash/lodash/wiki/FP-Guide
I'm personally not a big fan of this type of behavior being part of Formik. IMO embedded structures inside a field should be handled by encapsulated components that update the structure appropriately, not at the top Formik level. Making a DSL for updating arrays and objects adds a lot of complexity and idiosyncrasy to the Formik API.
My suggestion was not to have a new methods but have the current methods that accept a string for the field name of the property to update, to be upgraded to do what they currently do with the same api but accept a field:string that can be a path too if the user wants.
To the current users nothing changes and there are no breaking changes, just a new option to path
this api stays the same --> handleChangeValue = (field: string, value: any) => {
//just the implementation inside changes
}
I am doing it on my side right now but if it goes inside formik my code would be more abstract and easier.
Now is the point were it is a decision on your part to were you want it to go. I gave my thoughts and hope it help to create new ideas at least.
I like your library because it almost doesn't demand me to do things one way.
Most helpful comment
I'm personally not a big fan of this type of behavior being part of Formik. IMO embedded structures inside a field should be handled by encapsulated components that update the structure appropriately, not at the top Formik level. Making a DSL for updating arrays and objects adds a lot of complexity and idiosyncrasy to the Formik API.