Video yükleniyor...
Video Yüklenemedi
Hell froze over: announcing FormKit for React. Secretly framework-agnostic since inception, today we’re open sourcing the most popular Vue form library…for React. Why is this a big deal? 1. Forms are still hard. We (the creators of FormKit) thought form libraries were no longer necessary, given the trajectory of... show more
11,705 görüntüleme • 6 ay önce •via X (Twitter)
16 Yorum
Finally!! Haha. I remember you telling me some time ago when this was being cooked up. Welcome to the React forms realm! 😄
Congrats to the React ecosystem on this gem👑
Nice! I don't care for React, but hopefully this sparks some more usage & Pro $$$
for NO.6 schema, do you support it seems popular and futuristic
No, we have our own well established one at this point:
@uptonking2 FWIW, while I'm a strong proponent of Standard Schema and have integrated it into TanStack Form, FormKit's is much more flexible. Think of it less as a strict schema and more of a serializable programmatic instruction set IIRC
@uptonking2 This is accurate. And hi 👋
Still a vue user but hopefully more people will use it, now can we get reactive rendering? :p
Oh? Like what?
Had some issues when schema + data had to be dynamic and we forced a v-if to re-render the form 😅 I think there's a GitHub ticket saying that is not reactive somewhere
Using the same FormKit component for the wrapper form and all inputs seems like an anti-pattern. Have you considered instead using `FormKit.Form`, `FormKit.Repeater`, `FormKit.Text` etc. instead? It would improve readability imo.
Why would it be an antipattern? It's literally how native html works: <input type="text"> <input type="checkbox"> <input type="number"> FormKit smooths out that api to encompass things like <select> and <button> too.
There are two reasons, in my mind: 1. HTML intentionally has a different element for <form> than it does for <input> (and groups of inputs). 2. It's more difficult to reason about component structure at a glance if the same component is used for forms, groups, and inputs Perhaps you would consider at least enabling: <FormKit.Form>, <FormKit.Input>, and < That said, I still think it would be a better DX in React to use FormKit.Text, FormKit.Checkbox, etc. for inputs as well, because React is often scanned visually for top-level components. Your brain only has to pay attention to the props of a specific component if you are diving into a deeper level of abstraction. It's also important to think of how humans (and coding agents) will use the API in practice. Just because the documentation or recommended use of the component is to have the `type` prop directly after the component name, doesn't mean it will be used in that manner. Thinking about it this way, it's easy for developers to footgun themselves by placing the `type` prop later in the props chain, causing readers to have to read the entire prop chain just to understand what a specific formkit component will render as. Using the FormKit.{Element} format prevents this footgun entirely and preserves the at-a-glance scanability of component trees.
If thats a footgun you're concerned about you can wrap them. FormKit doesn't care about component depth, so you can very easily wrap a <FormKit type="form"> as <MyForm> or whatever you want. In practice this has not been a concern for users of FormKit, but again, the flexibility lets you solve the sugar easily.
Does this work with tanstack forms? BTW thankyou
Totally different approach to forms than tanstack forms. Im sure you could get them working together, but they are really quite different. Tanstack forms is great too though :)
