-
-
Notifications
You must be signed in to change notification settings - Fork 481
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
Register only once for useField hook #727
base: main
Are you sure you want to change the base?
Conversation
Can you see if this is still a problem after |
@erikras [email protected] with 3000 fields ~7-8s [Edit - 4/6/2020] Could you explain the reason behind why notifications on register matters? Maybe I'm not understanding the case that you were trying to cover. Still, I was make all the unit test pass without calling to notify subscriptions. Thanks. P.S. I'll update this PR after your feedback, because I'm not sure with my changes |
@erikras Any recommendations? |
@erikras |
@ra2dev What is the status of this PR. It will be really useful to me, because I have a form, separated in different tabs? @erikras Since FF is not actively maintained, can to transfer rights to anyone who wants. |
@Dragomir-Ivanov |
Thank you @ra2dev , and sorry for the late response. |
Hi, I'm trying to address an issue describe here on issue #667 to improve performance on initial registration of the field.
Also there's a final-form PR that goes with this change: final-form/final-form#319
Again, to describe the findings, with
useField
hook, it was usingregisterField
to register for the first time to get the initial values synchronously, then unregister to throw away the initial subscription to get the initial state, then register again for subscribing to the subsequent updates to the form. And each time it registered, it fired off notify subscription on all previously registered fields and for the current subscription. So, if you are trying to render 100 fields on the screen, that's 2 registration per field and 10100 or n(n + 1) notifications.So I wanted to separate the registration and subscription to make sure that registration and initial state is calculated during that registration, and subscribe in a separate call to the field states. With this change, I've reduced the number of notifications to 0, and only registering the field once. Another side effect of this change was the fix for this issue as well: #639. The change I made does not unregister the field when it's unmounted.
But..., since I wanted to make sure that it works with currently supported behaviors, I did introduced
keepFieldStateOnUnmount
property touseField
/Field
to make sure that the current logic of removing/unregistering the field on unmount still works.