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 systemWhy 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•7mo 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:
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•7mo 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-cyanOP•7mo 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•7mo 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-cyanOP•7mo 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•7mo 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-cyanOP•7mo 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•7mo ago
Wait...
Where do you see
defaultValues
being passed to createFormHook
or createFormHookContexts
??
I scanned our docs and I don't see iteastern-cyanOP•7mo 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•7mo ago
Ahh, I see it
eastern-cyanOP•7mo ago
anyway, super excited to adopt these patterns makes a lot of sense
other-emerald•7mo 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-cyanOP•7mo ago
😢 antd...
other-emerald•7mo ago
They ship their own??
eastern-cyanOP•7mo 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•7mo ago
Actually
OK this is gonna sound incredibly weird coming from the lead maintainer of TSF
other-emerald•7mo ago
other-emerald•7mo 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-cyanOP•7mo 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•7mo 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-cyanOP•7mo ago
Interesting. Will do!