-
-
Notifications
You must be signed in to change notification settings - Fork 70
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
Indexes as keys break components behaviour #116
Comments
I tried to keep track of keys on my side but I encountered another problem Calling Which prevents me from doing something like
since the following will still have the deleted value, but the associated will be deleted https://codesandbox.io/s/react-final-form-field-arrays-mrl4s |
It seems that queuing keys handling in a microtask allow the key handling to take place between the "bad" and the "good" render |
I'm having issues from this morning too with the same things. |
https://codesandbox.io/s/react-final-form-field-arrays-mrl4s works cause I queued key handling in a microtask, which is not something I want to do https://codesandbox.io/s/kx8qv67nk5 looks like its working, but the issue is present, it's just that the inputs handle well if they are bein updated instead of being deleted Also, I just discovered the data Field api in final-form which is not exposed in react-final-form. If it was, we could simply do something like
(the data prop is read once on field register, so the id will be stable forever) |
I think I'm on the wrong path, the id should somewhere in the |
Could you explain how https://codesandbox.io/s/kx8qv67nk5 is broken? |
Also, isn't this related? |
https://codesandbox.io/s/react-final-form-field-arrays-tc2tk Open the codesandbox console, add 2 customer with different values, then delete the first => it should not trigger the useEffect but it does |
Does not look like it |
The best workaround so far seems to handle keys manually in microtasks as seen in https://codesandbox.io/s/react-final-form-field-arrays-mrl4s
|
@erikras Any idea why there is an incorrect render just after calling |
After investigation of those 2 renders, there seems to be a bug of synchronization of field states https://codesandbox.io/s/react-final-form-field-arrays-3t4ol step to reproduce :
You will see that the form state and the fields value are not in sync If it was not for this bug, manually managing my keys would be possible |
I see now. I reverted to:
Also, I used your solution with microtasks. Thanks for the exhaustive explanations! For now I'm sticking to this, until I find out if it really isn't caused by: |
I noticed that even though I was using explicit versioning, the resolved dependencies in my package-lock also contained the same versions of final-form-arrays and react-final-form-arrays as you had in sandbox. Probably due to my lack of initial deeper investigation in package-lock or some other unknown issues. I also faced issues with validation and was constantly reverting to older versions. Your solution still works for me as I haven't bumped version yet 👍 Thanks for the update! I'll try updating soon! |
UPDATE : After implementing in real life the manual handling of keys for fields array, I can say it works, most of the time, but It would be much simpler, less error prone and edge cases would be covered if key management was built in react-final-form-arrays. |
My solution to also handle initial data :
|
The most fundamental use-case for this package is adding and removing data-rows. It's a little surprising that such core functionality isn't handled internally. |
After almost half a year, I have found a solution to this problem that allows for testing the initialValues that includes using useMemo for the initialValues and passing manually values instead of fields to method that also manually stores the keys and indexes for reference. |
I'm curious about your solution, can you provide a gist ? |
Hey, here are some crucial parts of my solution:
Unfortunately, my code includes much more utility methods and they contain a lot of business logic that is intersecting with the UI beahvior, but the basic solution should be visible here. first package resolution that was working:
My current working package versions from package-lock:
|
my solution is
|
@erikras i have same problem! it seem that, the officel demo everything is fine. final-form-arrays@1.1.2 is fine. but when i update version of libs, i got the same problem! sorry for my poor english! look forward to your reply,thanks! |
Indexes as keys work great until each array element's component renders different sub-fields. Then all sorts of weird things start to happen when rearranging or deleting items, as described in this issue. I came to the conclusion that I needed final-form to maintain a unique ID for each array element for use as a React key, then found this issue and it really seems like this is the way to go. I'd love to see |
Are you submitting a bug report or a feature request?
a bug report
What is the current behavior?
If i have an array of two fields, and remove index 0, then component at index 0 is updated with value of component at index 1 and component at index 1 is deleted.
What is the expected behavior?
If i have an array of two fields, and remove index 0, then component at index 0 is deleted.
Exemple
Sandbox Link
Any example of this lib has this issue
https://codesandbox.io/s/kx8qv67nk5
What's your environment?
Other information
Clearly the problem here is that indexes are used as keys.
Maybe final-form-array could create unique keys at push and keep track of them during other operations and provide this key in FieldArrayRenderProps.
We could not rely either on value ref for maintaining the index => key mapping.
The text was updated successfully, but these errors were encountered: