Posibility of refactoring the structur of the FormGroup object ofr much nicer DX

[then3rdman]

Long story short, if the actual form fields where to be nested within a fields object then we would be able to generate significally nicer types and even provide propper autocompletes on the FormGroup object that is used within the VUE component.

Happy to discuss the details of why but before I create a PR with what would be a breaking change, I wanted to see if this would fly?

[alexgrozav]

Hey @then3rdman, to be honest I've been thinking of this as well in the past. Let's discuss it first.

Are you thinking to make the processing internally so the user-provided schema would be the same, or would the user-provided schema change entirely? Would love to see some code examples with what you've got in mind.

[then3rdman]

So the user defined schema would be almost the same. I think that the main change would be that fields would also need to be nested under a fields key. The ability to explicitly specify some of the state on a specific field which would remain the same.

[then3rdman]

Basically in order to correctly get the keys of the form fields they need to be isolated from the root of the object that contains the general form fields.

[then3rdman]

I can start a draft PR with some of the changes as I think they would work

[alexgrozav]

Alright, let's try this out. Looking forward to it! 🙌

[then3rdman]

Playing with this now and looking good. Though it is rather complex because of the mixins and options API. Obviously significant work but thoughts on transitioning to composables and coposition api?

[then3rdman]

As a follow up to that, if that transition is made it might make a lot of sense to move to SFC raather than the current split components. Unless there is a reason for the current approach I am unaware of