v7 has problematic breaking changes - i think due to reset changes

[jpodpro]

in v6, the data object in the submit handler only contained properties that had corresponding hook form elements. in our interactive form if elements were removed then those fields wouldn't end up in the object. in addition, the initial object that we use to populate the form via reset has lots of other read-only data in it. none of this would end up in the submit data.

however in v7, the data structure provided on submit contains everything in the initial reset call. this includes all kinds of data that doesn't have hook form elements and is causing problems because we don't want to send all of that up to the server and i don't want to have to manually sort through the structure to pull out things that shouldn't be there. that's what building the form should already be (and was already) doing.

note that using shouldUnregister on a Controller appears to be a partial solution. however this causes new problems: it removes the reset default values completely such that when the form is switched into a state and back, any removed elements original state is gone. this is not how it worked before as the reset state appeared to be held in tact internally. why was this behavior changed?

from the v7 documentation:

It's not default for the form, to include additional form values.

[jpodpro]

reading through the v7 discussion notes i see that there was a poll for whether to do this. wouldn't it have been easy enough to make it a configurable option instead of forcing such a significant breaking change? it's really problematic for us.

[jpodpro]

i've also just noticed that validation rules are still triggered for form elements that have been removed. i don't want to unregister these because i want the data to remain if the user switches back to them. however they shouldn't still trigger validation rules if they have been removed! these changes are terrible for dynamic forms.

after losing 2 days struggling to migrate i'm forced to give up. v7 definitely has some great improvements but there's too many breaking changes with no possible work-arounds.

[bluebill1049]

sorry to hear, please keep v6 if migration is too difficult as I am still painting v6.