T
TanStack7mo ago
eastern-cyan

Philosophy w/ respect to design systems

I saw this statement in the #form chat history:
We do not want you to use form.Field in normal app code, but instead wrap it into your codebase in a design system
Why is this desirable, is it still the stance of the library? Not all inputs are form inputs; the value/onChange may just need to derive from normal state. I'm also not sure I want to tie my design system components to one particular form library. Curious to hear more context!
21 Replies
other-emerald
other-emerald7mo ago
It's even stronger the stance of the library now, using these APIs: https://tanstack.com/form/latest/docs/framework/react/guides/form-composition The idea is that you have three layers of application code, each that builds on the other: - App code - Library design system components - Normal design system components Each layer above can use each layer below without any problems. So you might have:
<MyPage/>
<field.MyTextInput/> // Which pre-binds `onChange` et al
<MyInput/> // Which accepts value and onChange as props
<MyPage/>
<field.MyTextInput/> // Which pre-binds `onChange` et al
<MyInput/> // Which accepts value and onChange as props
Form Composition | TanStack Form React Docs
A common criticism of TanStack Form is its verbosity out-of-the-box. While this can be useful for educational purposes helping enforce understanding our APIs it's not ideal in production usecases. As...
other-emerald
other-emerald7mo ago
The reason you'd want to do this is drastically reduced boilerplate, less thought needed to build out forms and bind elements, and more
eastern-cyan
eastern-cyanOP7mo ago
Thanks! I had read through that page already but couldn't clock the intention of the pre-bound components. I'm at a small startup that has built a lot of logic based around another form-library-not-to-be-named, so just evaluating the cost/benefit of investing in a whole new set of components to represent that middle "library" layer. Seems not too expensive
other-emerald
other-emerald7mo ago
I mean, you're either already doing something like it or your templates are much longer/duplicative than they need to be Form has a higher up front investment though, yes. But it also scales much better with more flexibility and less custom-written code outside of that
eastern-cyan
eastern-cyanOP7mo ago
I think what I'm missing is a global registry for fieldComponents. Does that exist? Or do I need to create each form with createFormHookContext to register the fieldComponents? Although the separate form hooks are helpful for typing the field names correctly, in general I won't expect my field component behavior to change from form to form, so why should I need to register them in each form? I could just be misinterpreting the API though 😅
other-emerald
other-emerald7mo ago
A global fieldComponents registry would break our philosophy on strict typings and generics passsing. However, you absolutely do not need to createFormHookContext each time - you can (and should) do it once for your entire app.
eastern-cyan
eastern-cyanOP7mo ago
Ahh I see, so you wouldn't actually pass defaultValues to the global one like shown in the docs. And each individual form instance or consumer will share the formOptions relevant to the local context. To accomplish the field name typing
other-emerald
other-emerald7mo ago
Wait... Where do you see defaultValues being passed to createFormHook or createFormHookContexts?? I scanned our docs and I don't see it
eastern-cyan
eastern-cyanOP7mo ago
No no, it's just defaultValues is being used in a component called "App" in the first example here which had me a little confused: https://tanstack.com/form/latest/docs/framework/react/guides/form-composition
Form Composition | TanStack Form React Docs
A common criticism of TanStack Form is its verbosity out-of-the-box. While this can be useful for educational purposes helping enforce understanding our APIs it's not ideal in production usecases. As...
other-emerald
other-emerald7mo ago
Ahh, I see it
eastern-cyan
eastern-cyanOP7mo ago
anyway, super excited to adopt these patterns makes a lot of sense
other-emerald
other-emerald7mo ago
Good stuff! Let me know if you run into anything else or if I can help clarify along the way 🙂 BTW, what form library are you potentially migrating from?
eastern-cyan
eastern-cyanOP7mo ago
😢 antd...
other-emerald
other-emerald7mo ago
They ship their own??
eastern-cyan
eastern-cyanOP7mo ago
Yes. It's quite the nightmare. I'm glad to have chatted with you before doing anything too complex. Our product is essentially a CRM for form building, so we have dynamically generated forms with potentially form-initiated form changes. I don't think any other library out there comes close to making that feasible, and I'm sure I will also stress test this one
other-emerald
other-emerald7mo ago
Actually OK this is gonna sound incredibly weird coming from the lead maintainer of TSF
other-emerald
other-emerald7mo ago
But have you considered https://react-ts-form.com/ ?
react-ts-form
react-ts-form
Build maintainable, typesafe forms faster 🏃💨
From An unknown user
From An unknown user
other-emerald
other-emerald7mo ago
I think this actually might suit your needs better than ours Our library is more for highly customized forms that might potentially need one-off validation logic or custom UI stuff et al Schema-based validation would be possible with TSF, but you don't really need to type safety we provide or much other stuff You could build something like React TS Form with TanStack Form's JS core, but it's not something we're aiming to build ourselves
eastern-cyan
eastern-cyanOP7mo ago
Well, we do also have a lot of one-off forms with custom validation logic which is where I was starting with tanstack form. The main problem with our antd implementations for the dynamic forms is the lack of type safety, we have custom utilities just to generate the correct keys when initializing, updating, reading from the form. I'm hoping to design something more resilient with less boilerplate, but it won't be too soon that I can replace the original implementation. I don't have much familiarity with react-ts-form but I'll look into it; are you just saying it would be more difficult or not even possible in tanstack
other-emerald
other-emerald7mo ago
It's possible, but we're just not built for schema-based form validation. Our type safety might be more of a headache than a help But if you give it a shot - let me know how it goes!
eastern-cyan
eastern-cyanOP7mo ago
Interesting. Will do!

Did you find this page helpful?