I love these sorts of frameworks! Makes doing forms a lot nicer, especially the live validation.
I feel like the next evolution is automatically generating a whole form from selecting a schema in an OpenAPI spec.
In a lot of specs, the type (string, email, phone, int, etc) is present along with any constraints (min/max length). Depending on the language/OpenAPI generator, it even preserves field order. It could massively speed up a lot of the more generic forms that happen in frontend.
As for me, forms are the single most important aspect of many web apps. Including critical ones for the society (banking, tickets, taxes, etc). Large part of my frustration with the state of web stems from how terrible experience with (creating and using) forms is.
Web is almost 30 years old by now, and the announce of a way to make forms relatively easily, still generates an excitement.
I mean, how many more years webdev community needs to realize that typesetting engine from 80s is not a good option for making modern robust UI apps? Technology for making hyperlinked web-pages is a terrible foundation for apps.
We also built one from scratch and used it in client-facing production applications (Angular + React Native). The biggest hurdle is that JSON schema is great at describing the shape of the form data but not a great job at describing how the form looks. We ended up creating a separate "presentation" schema which handled things like order of the form, rows/columns, widgets to use, and much more.
The product and the website are really slick, but there is nothing about who made this other than "FormKit, Inc." in the footer. Is this a group, an individual, a subsidiary, or what?
One of the maintainers here — new business created by the team that made Vue Formulate (https://vueformulate.com/). FormKit is its own entity because its goals are larger than being a sub-product of a client-service agency.
GH contributions primarily from three people, all affiliated with https://www.wearebraid.com/home. Seems to be some web dev consultancy that has open sourced part of their toolchain.
I was just talking about this with a colleague. We really want to join the beta at my company. Would be happy to sign up for the pro plan!
One note though, I want to point out, that I am able to "break" some of the demo components, like changing type="number" doesn't seem to error the form when I input text over it.
In case one of the other maintainers sees this, I have one other question:
Does this in any way use `eval`? I know a lot of JSON schema validators do, and that is a pain when it comes to CSP. If Formkit doesn't use eval (and maybe we can get a commitment on that...) its a no brainer
> When a user clicks or touches/taps a label, the browser passes the focus to its associated input (the resulting event is also raised for the input). That increased hit area for focusing the input provides an advantage to anyone trying to activate it — including those using a touch-screen device.
Looks very good, but if I read validation docs correctly there is no built-in validation for group of fields, like range of dates or product price range. Or even more complex where third field, type of product, defines lower boundary for product price range.
This means you have to somehow hook up into input/validation events for each field, add validation manually and then try to put errors in the right fields even if that is not the last modified field.
Groups track the validity of their child nodes by default. You can also supply custom validation functions if you have needs outside of the scope of the built-in validation rules (such as your product example).
I've used VueFormulate in the past, and it was extremely powerful albeit somewhat bloated. FormKit seems like a step in the right direction. Good Luck!
Looks really interesting. We’re using a hand rolled solution on top of JSON schema but it’s pretty unforgiving and sometimes requires very invasive changes to add support for new requirements. One thing I didn’t get a good grasp on from the examples is what the error responses should look like from the server. I would love to use this as the per field and error groups are a very nice feature IMO.
With the genesis theme that ships with it there’s nothing that would be inherently incompatible with bootstrap if you threw it inside a container — provided you’re already using Vue.
Happy to hear if you’re having any issues! We have a very active and helpful discord community.
Very impressive. The schema covers everything I need. This library desperately needs "Repeater" component which I assume would handle array of inputs. This would allow FormKit to handle the most complex forms which is where this library would help the most.
What would be the advantage over creating forms (using jotform etc) and embedding them in apps as anywayz people wouldn’t want to take control over or engineer forms much.
Forms in UI code also tend to have a bunch of business-logic type validation (e.g. "there's already a user with that email address") which schemas alone are unsuitable for.
They will apparently (at least) offer new input types such as tag fields. You can find a few references of the pro features in the documentation and guides.
I used vue for a project and encountered a gnarly bug - I have a component which can embed itself recursively, and I pass some variables through the stack to communicate to the root. But if I nest 3 components deep, it actually hangs the tab and crashes chrome! Can’t even debug! Not sure how to even recreate it in a way that’s not proprietary and hence can’t file a bug as well.
I'd be interested in seeing your code for this. I'm 99% certain it's something in your code rather than in Vue itself. I've done recursive nesting myself plenty of times and as long as you limit the depth so it doesn't go infinite you're fine.
If it could help, I have a demo project that has recursive components (comments) [1]. It can be seen in action on GitHub Pages [2].
The only issue I encountered is that recursive components must be named since they can't import themselves. This is covered in the official Vue docs [3]
[+] [-] Jarvy|3 years ago|reply
I feel like the next evolution is automatically generating a whole form from selecting a schema in an OpenAPI spec.
In a lot of specs, the type (string, email, phone, int, etc) is present along with any constraints (min/max length). Depending on the language/OpenAPI generator, it even preserves field order. It could massively speed up a lot of the more generic forms that happen in frontend.
[+] [-] divan|3 years ago|reply
Web is almost 30 years old by now, and the announce of a way to make forms relatively easily, still generates an excitement.
I mean, how many more years webdev community needs to realize that typesetting engine from 80s is not a good option for making modern robust UI apps? Technology for making hyperlinked web-pages is a terrible foundation for apps.
[+] [-] user3939382|3 years ago|reply
[+] [-] rekwah|3 years ago|reply
There's also a number of them out there that generate a form from json schema. I'm most familiar with https://github.com/formschema/native which we use/extend at https://routegy.com for microapps.
[+] [-] tuckwat|3 years ago|reply
We also built one from scratch and used it in client-facing production applications (Angular + React Native). The biggest hurdle is that JSON schema is great at describing the shape of the form data but not a great job at describing how the form looks. We ended up creating a separate "presentation" schema which handled things like order of the form, rows/columns, widgets to use, and much more.
[+] [-] cyanydeez|3 years ago|reply
[+] [-] juddlyon|3 years ago|reply
[+] [-] andrew_braid|3 years ago|reply
Primary author is Justin Schroeder - https://twitter.com/jpschroeder
I help :) (Andrew Boyd) - https://twitter.com/0xBOYD
[+] [-] meetups323|3 years ago|reply
[+] [-] ROARosen|3 years ago|reply
[1]https://vueformulate.com/
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] no_wizard|3 years ago|reply
One note though, I want to point out, that I am able to "break" some of the demo components, like changing type="number" doesn't seem to error the form when I input text over it.
In case one of the other maintainers sees this, I have one other question:
Does this in any way use `eval`? I know a lot of JSON schema validators do, and that is a pain when it comes to CSP. If Formkit doesn't use eval (and maybe we can get a commitment on that...) its a no brainer
[+] [-] girvo|3 years ago|reply
As far as I can tell, my go-to schema system doesn’t. https://github.com/colinhacks/zod
[+] [-] andrew_braid|3 years ago|reply
The schema parser is custom-written and does not make use of `eval`.
[+] [-] pupppet|3 years ago|reply
[+] [-] Semaphor|3 years ago|reply
[+] [-] KronisLV|3 years ago|reply
Doesn't this happen by default in most cases where a regular <label/> is used?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/la...
> When a user clicks or touches/taps a label, the browser passes the focus to its associated input (the resulting event is also raised for the input). That increased hit area for focusing the input provides an advantage to anyone trying to activate it — including those using a touch-screen device.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] axi0m|3 years ago|reply
[+] [-] metalrain|3 years ago|reply
This means you have to somehow hook up into input/validation events for each field, add validation manually and then try to put errors in the right fields even if that is not the last modified field.
[+] [-] andrew_braid|3 years ago|reply
[+] [-] ROARosen|3 years ago|reply
[+] [-] memco|3 years ago|reply
[+] [-] newuser94303|3 years ago|reply
[+] [-] Yuioup|3 years ago|reply
[+] [-] andrew_braid|3 years ago|reply
Happy to hear if you’re having any issues! We have a very active and helpful discord community.
[+] [-] mariushn|3 years ago|reply
[+] [-] lubos|3 years ago|reply
[+] [-] strict9|3 years ago|reply
If only all third-party packages/apps were as pleasant to work with as the ones put out by FormKit team.
[+] [-] Divyeshkharade|3 years ago|reply
[+] [-] msoad|3 years ago|reply
[+] [-] bpicolo|3 years ago|reply
They definitely are using their DSL for things far out of the scope of JSON schema. The builtin debouncing is pretty neat: https://formkit.com/essentials/validation#debounce-milli
Forms in UI code also tend to have a bunch of business-logic type validation (e.g. "there's already a user with that email address") which schemas alone are unsuitable for.
[+] [-] manish_sg|3 years ago|reply
[+] [-] est|3 years ago|reply
[+] [-] jvzr|3 years ago|reply
[+] [-] XzAeRosho|3 years ago|reply
[+] [-] calltrak|3 years ago|reply
[deleted]
[+] [-] ramraj07|3 years ago|reply
[+] [-] pmx|3 years ago|reply
[+] [-] AlbinoDrought|3 years ago|reply
The only issue I encountered is that recursive components must be named since they can't import themselves. This is covered in the official Vue docs [3]
[1] https://github.com/AlbinoDrought/vue-dit/blob/master/src/com...
[2] https://albinodrought.github.io/vue-dit/#/sub/technology/uom...
[3] https://v2.vuejs.org/v2/guide/components-edge-cases.html#Rec...
[+] [-] Etheryte|3 years ago|reply
[+] [-] __ryan__|3 years ago|reply