-
-
Notifications
You must be signed in to change notification settings - Fork 448
feat(core): field meta API #1216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
harry-whorlow
wants to merge
1
commit into
TanStack:main
Choose a base branch
from
harry-whorlow:meta-api-2
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+135
−14
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -484,6 +484,7 @@ export type FieldInfo<TFormData> = { | |
any, | ||
any, | ||
any, | ||
any, | ||
any | ||
> | null | ||
/** | ||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fulopkovacs
so this works nicely, but the issue is if I do something like
form.state.fieldMeta.name
I can't infer the user defined meta.Do you have any suggestions on how to get it to form? I've tried a few things but can't get it to work. 🙃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, this does seem to be complex problem. I spent about 2 hours thinking about it, but couldn't come up with a solution.
Here's what I see now
Up until this point we had no need to infer the type of a field's
meta
, because it was the same for all of them (isDirty
,errorMap
, etc.). Because of this, it was enough to create a genericAnyFieldMeta
type that we could use in the methods ofFormApi
, likegetFieldMeta
:Compare this to the
getFieldValue
method, where the return type depends on the specific field whose value we're looking for:DeepValue
receives the name of the field (TField
) as a type argument and uses it to get the type of the returned value from the form's data (TFormData
).I think
DeepValue
has access to the type of the field's value, because you initiate theFormApi
class with it:How to solve this problem?
In order to have a proper
FormFieldMeta
type instead of a genericAnyFieldMeta
type in theFormApi
class, we need to define the field'smeta
types during the initialization of theFormApi
class.So it could look something like this:
Ofc, it would be better to only pass down the types of the field's custom meta properties, and define those later.
Honestly, this is not the best possible API we could have, but the best one I could come up with at 0:37 🤣...
If the
FormApi
is aware of the possible meta fields mapped to field names, then we can have a type likeFormFieldMeta<TFormFieldMetaData, TField>
, whereTFormFieldMetaData
is the type offieldMeta
in the example above, andTField
is the name of the field.Bad news
I'll be away from the keyboard for 4 days from today (maybe I can be still reached today, but definitely not from tomorrow). 😢 You probably have more questions/comments, feel free to write them, and I'll answer when I'm back!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fulopkovacs I was thinking the same thing, I think there was a small dwindling light of hope that perhaps it was just my inability to code. Maybe I've just sold myself short...
Given your suggested answer would it also make sense to have a baseMetaExtension too? I ask this because of #715 where a proposed solution was to store a Ref in the meta. Which makes sense to me, but having to add the Ref meta to every field, especially if you have a lot of fields could result in lots of boilerplate.
I'll have a poke around in the mean time, enjoy the time away from the keyboard 🤟
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably did! 🤣
🤔 Hmmm, do you image the API look like this 👇 ?
After reading the discussion you mentioned (#715), I understand why we would need something like this, and I support it, but I still have a weird feeling about it for some reason. Maybe I'm just not fond of the name
baseMetaExtension
. What do you think about something likedefaultCustomFieldMeta
? From what I understand now, we would have to assign default values to the shared custom field meta properties when we create the form, so a name withdefault
in it sounds fitting, plus it looks similar todefaultValues
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fulopkovacs sounds good to me, if it's cool with you I'll spin the defaultCustomFieldMeta into its own separate PR and get that out as it seems #715 is asked every other week.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new PR would depend on this one, right? In that case, we can create a new PR, but we could also just put some info about these changes into the description of this PR, and reference it whenever someone asks about this issue. I prefer the latter, but feel free to go with the new PR if you want to.
But even before that, could you bring up this proposed API (
defaultCustomFieldMeta
or whatever we'll go with) in the Discord too? I'm fine with it, but maybe other maintainers have different ideas!There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fulopkovacs actually... you've got a good point it would. we shall keep it as one then... and yes I will drop it into the discord.