FormKit: Form building framework for Vue 3 | Hacker News Reader

FormKit: Form building framework for Vue 3

formkit.com

218 pointsDestiner65 comments

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.

Here's a Clojure strategy optimized for streamlining this exact type of development https://hyperfiddle.notion.site/Reactive-Clojure-You-don-t-n...

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.

I watched a video recently on how to make fire. 30,000 years we’ve been doing it, and videos like that are still interesting!

1000% this. The state of native form inputs on the web platform is dismal, truly. Particularly on mobile.

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.

I'm not saying it's easy. But hey, StackOverflow threads on how to post form with checkbox with "false" value in it are pretty telling.

I've done forms with Qt, QML and Flutter, and it's completely different experience.

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.

These exist, such as: https://github.com/rjsf-team/react-jsonschema-form

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.

I know https://github.com/bytebuilders/vue-openapi-form exists but no first hand experience with it.

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.

I've definitely tried to find a graphql form generator that would take a schema and mutation and make a form with validation.

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?

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.

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.

Primary author is Justin Schroeder - https://twitter.com/jpschroeder

I help :) (Andrew Boyd) - https://twitter.com/0xBOYD

FormKit is a "descendant" of VueFormulate[1] you'll find more information there. here's the co-founder's Twitter: https://twitter.com/jpschroeder

[1]https://vueformulate.com/

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

I didn’t know that a lot of these schema systems use eval. Surprising, why is that?

As far as I can tell, my go-to schema system doesn’t. https://github.com/colinhacks/zod

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.

[0]: https://ajv.js.org/security.html#content-security-policy

They there! The beta is public so you’re welcome to install from NPM and use. If you have issues we’d be happy to help out in Discord.

The schema parser is custom-written and does not make use of `eval`.

Whenever I see these form frameworks the first thing I do is click the label to ensure it focuses the input field. Aaaand pass, good job!

That's a very low bar, I wouldn't even check because it's to be expected. Are there any form frameworks getting traction that are so broken?

What would you know, today I learned

It does appear to do that for me in their example on the homepage (desktop Firefox), though?

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.

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.

I personally use that lib: https://github.com/openizr/gincko Still in beta, but quite stable though.

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.

Is there something like this for bootstrap?

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.

Honestly I would rather have a UI-less solution a bit like the "Reactive Forms" from Angular.

For clarity, the base theme — Genesis — is 100% optional. FormKit is not and does not aspire to be a UI library.

Ah great! I didn't read the docs closely, just did a quick surface scan.

I'll definitely check this out.

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!

https://cdmoro.github.io/bootstrap-vue-3/components/

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.

FormKit (formerly VueFormulate) team is the most responsive to issues I've ever encountered. Superb documentation and easy to understand apis.

If only all third-party packages/apps were as pleasant to work with as the ones put out by FormKit team.

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.

Why people keep inventing new schema formats? JSON Schema is not perfect but you can extend it to achieve all of what's in this schema format.

Well, they're not validating JSON. Forms are text value fields that aren't always sent as JSON later, or necessarily sent over the wire at all.

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.

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.

For example; React has a library to generate forms via JSON Schema and you can use uiSchema feature for the use-case that you mentioned: https://react-jsonschema-form.readthedocs.io/en/latest/api-r...

But then I'm running a bespoke DSL for interface display in a validation lib.

It's not obvious that's the better direction eh?

On a slightly related note, does anyone know of a form library like this one with first class support for a drag and drop form builder interface?

What's the difference between Free and Pro?

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 wish more frameworks or tools offered a landing page as good as this project.

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.

Why can’t you debug?

Because it doesn’t throw an error, and it hands deep inside the vue code when an even to add one more nested component is triggered.

Maybe try console logging?

But what if the component is a recursively nested logging tool?

They might even become part of the next YC batch. A recursively nested logging platform - quite a novel idea. Possibly even possible to patent.

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.

Why not just debug on component creation? Or maybe on DOM subtree modification [0]? Or maybe modify the compiled JS to add log or trace statements?

It’s all in your browser. You have a debugger at your fingertips.

Why doesn’t Vue stop this from happening? Because it assumes whatever you’re telling it to do is what you want it to do.

0: https://developer.chrome.com/docs/devtools/javascript/breakp...

That sounds like a bug in your code, honestly. Recursive components have been around in Vue since 0.x and they're used in many, many projects.

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.

Absolutely sure I’m doing something wrong but why would vue allow any case that hangs the entire tab? I’ve never seen that in any website ever!

Are you expecting vue to prevent you from doing something wrong?

Imagine if you write a java program and you execute it to get BSOD on windows, is that reasonable?

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.

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.

In that case you should blame Windows not Java.

Correct. And in this case, Chrome seems to be working as intended. Crashing the tab when bad code is written sounds like the correct behavior.

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]

[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...

Reply on news.ycombinator.com