-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
fix: field paths within hooks #10638
Merged
Merged
Conversation
This file contains 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 reverts commit ee9f8b4.
jacobsfletch
added a commit
that referenced
this pull request
Jan 27, 2025
Field validations can be expensive, especially custom validations that are async or highly complex. This can lead to slow form state response times when generating form state for many such fields. Ideally, we only run validations on fields whose values have changed. This is not possible, however, because field validation functions might reference _other_ field values with their args, and there is no good way of detecting exactly which fields should run in this case. The next best thing here is to only run validations _after the form has been submitted_, and then every `onChange` event thereafter until a successful submit has taken place. This is an elegant solution because we currently don't _render_ field errors until submission anyway. This change will significantly speed up form state response times, at least until the form has been submitted. From then on, all field validations will run regardless, just as they do now. If custom validations continue to slow down form state response times, there is a new `event` arg introduced in #10738 that can be used to control whether heavy operations occur on change or on submit. Related: #10638
🚀 This is included in version v3.20.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Field paths within hooks are not correct.
For example, an unnamed tab containing a group field and nested text field should have the path:
myGroupField.myTextField
However, within hooks that path is formatted as:
_index-1.myGroupField.myTextField
The leading index shown above should not exist, as this field is considered top-level since it is located within an unnamed tab.
This discrepancy is only evident through the APIs themselves, such as when creating a request with invalid data and reading the validation errors in the response. Form state contains proper field paths, which is ultimately why this issue was never caught. This is because within the admin panel we merge the API response with the current form state, obscuring the underlying issue. This becomes especially obvious in #10580, where we no longer initialize validation errors within form state until the form has been submitted, and instead rely solely on the API response for the initial error state.
Here's comprehensive example of how field paths should be formatted: