False Positive Error on Field[`name`]
When using
mode="array" and iterating over each item, the name field must be a nested item of the array field and cannot simply be the array item's index. (https://github.com/nickhudkins/reimagined-umbrella/blob/main/src/main.tsx#L92). This is somewhat related to type safe SubForms, and the overall form composition story, so it's possible that casting this as any is fine for now and we'll figure out a better API later?GitHub
reimagined-umbrella/src/main.tsx at main · nickhudkins/reimagined-u...
Contribute to nickhudkins/reimagined-umbrella development by creating an account on GitHub.
15 Replies
absent-sapphireOP•6mo ago
The general goal I am going for is to create a re-usable Array field. I ALWAYS will have Add + Delete + Move on all items, for any entity, and currently this happens to create a pretty intense amount of verbosity / repetition.
stormy-gold•6mo ago
I’ve asked about this before but didn’t really get much of an answer sadly :/ seems like we’re not treating array elements as fields in tanstack form. This is quite different than RHF and other form libraries that do support them.
absent-sapphireOP•6mo ago
Generally, the ability to build composable pieces of forms with tanstack forms leaves a bit to be desired. I still trust the library to get the API right over other options, but :\ it does create some really awkward components I think most of the "problems" are really type safety. The stuff WORKS
My goal really is to be able to define subforms for SHAPES of data, not fields of
defaultValues I likely could just "lie" and use withForm , provide fake defaultValues and then provide another layer to actually use the field or something like that
I don't know. I hope to not be building forms for the rest of my life, and I'm trying my best to automate the (insert non jesus-appropriate-word) out of it, but that requires composability. lolstormy-gold•6mo ago
Yeah on our projects we have reusable FieldArray builders that rely on the ability to treat array elements as their own entities that can have errors, we're currently refactoring to TSF and now have to create essentially a hidden 'field' within array[idx].root to target errors.
A part that's a bit confusing is APIs like form.getFieldValue(array[idx]) returns the array element but the type definition might be incorrect since it actually doesn't accept array[idx], but it will accept array[idx].subField...
absent-sapphireOP•6mo ago
I think it's JUSTTTT types. I think the actual behavior is correct :\
stormy-gold•6mo ago
Not necessarily though, if I'm not mistaken, if you treat array[idx] as a field, the fieldMeta will actually not be populated, at least it didn't work in runtime as expected
absent-sapphireOP•6mo ago
OHHHHHHHH, yes yes that is true
you cannot treat it as a field, but it will properly provide you the value at the index.
stormy-gold•6mo ago
Yeah methods like form.getFieldValue('index[idx]') do work at runtime though complain about the type.
absent-sapphireOP•6mo ago
yep 😦
stormy-gold•6mo ago
I'm not sure if we should rely on that as I'm not sure that's intended or could be dropped in the future though. I'd hope not. Hence why I'm a bit hesitant to just type it as any or as DeepKeys<TFormData>
absent-sapphireOP•6mo ago
You and me both. When types are wrong I don't assume it's fine, I assume the author meant that it's unsupported.
stormy-gold•6mo ago
Yup
Hope its a bug with the type definitions, I suppose we could start a discussion about it
absent-sapphireOP•6mo ago
I've been working on an alternate utility to be able to generate field path names but get autocomplete etc... I am using a Proxy object. I'll publish it in just a moment
absent-sapphireOP•6mo ago
absent-sapphireOP•6mo ago
You create an instance of it, and then access properties as though you have your full object. The result of doing so is a dotted-path & bracket-notation string that matches the path you access.
I've found it to be quite a pleasure to use rather than a huge union of strings