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.
Well, forms aren't easy on any client toolkit (e.g. iOS/Android).
Forms are hard because they are (1) pure user input—often textual—, thus inheriting all fundamental difficulties with user input, and (2) arbitrarily reactive such that changing one value may arbitrarily impact other values, e.g. bidirectionally, and (3) you are at the mercy of the platform supporting the input UX that you want to build and you quickly find yourself off the rails otherwise.
This means that even though forms seem like they should be trivial, it's just as hard to generalize over forms as any other UI concept. Or rather, it's not a solved problem for the same reason UI in general isn't a solved problem.
Well, every platform has its idiosyncrasies that you have to learn. No less with Qt, QML, and Flutter. You just take them for granted.
Cocoa/UIKit are my wheelhouse and have their own share of entry level StackOverflow questions. Though personally I think they make even less sense than the web toolkit. But if you just go by StackOverflow questions, you'd wonder if it was possible to learn anything.
Just search something like "auto layout" on StackOverflow. Turns out that client dev just isn't that easy no matter which abstraction you want to use.
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
Anything that uses `ajv` under the hood and doesn't use their compile schema options. They use `eval`[0] for a number of things.
Quite a lot of schema validators use `ajv` under the hood. Some, like I believe `yup`, `zod` and `superstruct` do not. I'm not sure why one approach is more advantageous than another, to be honest. I'd think eval would also be a performance issue.
> 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.
It only occurs when you use the label's for attribute to manually associate the label with the input, or wrap both the label text and the input in the same label.
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.
Hit us up in Discord if you have any issues! We've got a very active community and someone (including the maintainers) will be able to help if you're stuck!
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.
Well, they produce JSON though. I understand that there is much more context related to the user interface but you can extend JSON Schema to be able to tie more information to it. It's an incredibly flexible & collaborative way to define the schemas. The backend people are also familiar with it and can validate the data & collaborate with frontend people over a JSON Schema probably much easier compared to a frontend libraries DSL.
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.
You can write a program that locks up your computer in most any language, it's called a fork bomb. Of course, there are guards against the most basic versions these days, but the point still stands that there's nothing stopping you from writing an endless loop that takes up more and more resources.
You can open the browser dev tools on this very page, write in `while(1);`, hit enter and watch the tab freeze up.
I've written C# code that deadlocked a webserver, C++ code that crashed a computer lab, JavaScript code that made the browser unresponsive, a SQL migration that accidentally deleted too much data. I don't really know what point you're trying to make, but bad code typically behaves badly.
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]
iirc Chrome sometimes handles stack-overflows and/or out of memory conditions badly. If you have any function there that is called try making an entry/exit counter and log/throw if it goes above some threshold.
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.