That tweet cited around the 2-minute mark is so... aggressively ignorant. It peeves me to kingdom come when someone tries to make something complex sound simple by abstracting it into a short list where each item just happens to contain a world of complexity. The "user interactions" and "state management" items alone can get incredibly difficult to get right, robust and intuitive across all kinds of devices. "Toss in some validation functions", great, why not reinvent the wheel every time for all the validations that need to happen in the front-end and the back-end, with their attendant error messages and whether they exist on the form level, step level or field level? Might as well make it all one function even, validateForm(). All set!
It's not true "Personal details" is just nothing and doesn't end up in the tree. It will if you would make it a field set (with a label). They do not exist for nothing lol
In this case, looking at the form structure that we're trying to produce - `` does not contribute to our desired form tree. We want the inputs nested inside to be at the top level and not grouped in any fashion (this is arbitrary and we could certainly make an example where this was not true). Even if we did want them grouped, the point remains that the `` component _is_ completely irrelevant to our form data and you could image a form where many layout-type components of various kinds (cards, groups, tabs, accordions, etc) create boundaries in the component tree that are irrelevant to our desired form tree structure. The value that FormKit is providing here is that you don't need to worry about these strictly UI component at all - no matter what depth or degree of separation there is between a group and it's child nodes in the form tree, FormKit will organize it for you without you needing to do any manual plumbing of props / events. FWIW, FormKit does make use of `fieldset` tags to create accessible markup for its grouped inputs such as `repeater`, `radio`, and when you're doing multiple associated `checkbox` inputs.
@@Andrew_FormKit thank you for your response! Much appreciated. I like the approach of not ending up in a tree hell, referring to callback hell. We will certainly try out this library. How is support for nuxt 3 atm?
Great job, this is exactly what I've always wanted, simple and powerful
Formkit looks very promising ! You are a life saver, excited to try it out.
This is awesome! I am definitely going to give it a try today.
Impressive, I hope it also makes it easy to make the designers happy.
Will be looking into this for my project
That tweet cited around the 2-minute mark is so... aggressively ignorant.
It peeves me to kingdom come when someone tries to make something complex sound simple by abstracting it into a short list where each item just happens to contain a world of complexity. The "user interactions" and "state management" items alone can get incredibly difficult to get right, robust and intuitive across all kinds of devices.
"Toss in some validation functions", great, why not reinvent the wheel every time for all the validations that need to happen in the front-end and the back-end, with their attendant error messages and whether they exist on the form level, step level or field level? Might as well make it all one function even, validateForm(). All set!
It's not true "Personal details" is just nothing and doesn't end up in the tree. It will if you would make it a field set (with a label). They do not exist for nothing lol
In this case, looking at the form structure that we're trying to produce - `` does not contribute to our desired form tree. We want the inputs nested inside to be at the top level and not grouped in any fashion (this is arbitrary and we could certainly make an example where this was not true).
Even if we did want them grouped, the point remains that the `` component _is_ completely irrelevant to our form data and you could image a form where many layout-type components of various kinds (cards, groups, tabs, accordions, etc) create boundaries in the component tree that are irrelevant to our desired form tree structure. The value that FormKit is providing here is that you don't need to worry about these strictly UI component at all - no matter what depth or degree of separation there is between a group and it's child nodes in the form tree, FormKit will organize it for you without you needing to do any manual plumbing of props / events.
FWIW, FormKit does make use of `fieldset` tags to create accessible markup for its grouped inputs such as `repeater`, `radio`, and when you're doing multiple associated `checkbox` inputs.
@@Andrew_FormKit thank you for your response! Much appreciated. I like the approach of not ending up in a tree hell, referring to callback hell.
We will certainly try out this library. How is support for nuxt 3 atm?
But that's exactly the thing, there's no reason why your UI requirements should dictate the shape of your data.