[HN Gopher] FormKit: Form building framework for Vue 3
___________________________________________________________________
FormKit: Form building framework for Vue 3
Author : Destiner
Score : 169 points
Date : 2022-05-13 13:47 UTC (9 hours ago)
(HTM) web link (formkit.com)
(TXT) w3m dump (formkit.com)
| msoad wrote:
| 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.
| bpicolo wrote:
| 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.
| buremba wrote:
| 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...
| bpicolo wrote:
| 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?
| ROARosen wrote:
| 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!
| calltrak wrote:
| juddlyon wrote:
| 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?
| ROARosen wrote:
| 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/
| meetups323 wrote:
| 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.
| [deleted]
| andrew_braid wrote:
| 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
| Jarvy wrote:
| 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.
| user3939382 wrote:
| Here's a Clojure strategy optimized for streamlining this exact
| type of development https://hyperfiddle.notion.site/Reactive-
| Clojure-You-don-t-n...
| divan wrote:
| 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.
| blowski wrote:
| 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!
| pineconewarrior wrote:
| 1000% this. The state of native form inputs on the web
| platform is dismal, truly. Particularly on mobile.
| tuckwat wrote:
| 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.
| rekwah wrote:
| 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.
| lubos wrote:
| 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.
| ramraj07 wrote:
| 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.
| Etheryte wrote:
| 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.
| pmx wrote:
| 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.
| ramraj07 wrote:
| 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!
| DJBunnies wrote:
| Are you expecting vue to prevent you from doing something
| wrong?
| ramraj07 wrote:
| Imagine if you write a java program and you execute it to
| get BSOD on windows, is that reasonable?
| croes wrote:
| In that case you should blame Windows not Java.
| spiderice wrote:
| 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.
| badthingfactory wrote:
| 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.
| Etheryte wrote:
| 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.
| AlbinoDrought wrote:
| 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...
| __ryan__ wrote:
| Why can't you debug?
| ramraj07 wrote:
| 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.
| skybrian wrote:
| Maybe try console logging?
| aabhay wrote:
| But what if the component is a recursively nested logging
| tool?
| sgt wrote:
| They might even become part of the next YC batch. A
| recursively nested logging platform - quite a novel idea.
| Possibly even possible to patent.
| whizzter wrote:
| 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.
| strict9 wrote:
| 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.
| newuser94303 wrote:
| Is there something like this for bootstrap?
| Yuioup wrote:
| Honestly I would rather have a UI-less solution a bit like the
| "Reactive Forms" from Angular.
| andrew_braid wrote:
| For clarity, the base theme -- Genesis -- is 100% optional.
| FormKit is not and does not aspire to be a UI library.
| Yuioup wrote:
| Ah great! I didn't read the docs closely, just did a quick
| surface scan.
|
| I'll definitely check this out.
| andrew_braid wrote:
| 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!
| andrew_braid wrote:
| 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.
| axi0m wrote:
| I personally use that lib: https://github.com/openizr/gincko
| Still in beta, but quite stable though.
| XzAeRosho wrote:
| I wish more frameworks or tools offered a landing page as good as
| this project.
| pupppet wrote:
| 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!
| Semaphor wrote:
| 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?
| ditsuke wrote:
| What would you know, today I learned
| KronisLV wrote:
| 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.
| pupppet wrote:
| 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.
| [deleted]
| est wrote:
| What's the difference between Free and Pro?
| jvzr wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-13 23:00 UTC)