Skip to content
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

issue: Two useFieldArray instances are not able to modify the same array #11973

Closed
1 task done
bolencki13 opened this issue Jun 5, 2024 · 2 comments
Closed
1 task done

Comments

@bolencki13
Copy link

Version Number

7.51.5

Codesandbox/Expo snack

https://codesandbox.io/p/sandbox/divine-shape-4s2zy9

Steps to reproduce

  1. Go to code sandbox link
  2. Click on "Remove 0 (same useFieldArray WORKS)". Observe the 0th element in the list be removed
  3. Click on "Remove 0(separate useFieldArray DOES NOT WORK)". Observer nothing is removed from the list

Expected behaviour

I would expect any instance of useFieldArray referencing the same list to be able to modify said list.

What browsers are you seeing the problem on?

Chrome

Relevant log output

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@bolencki13 bolencki13 changed the title issue: Two useFieldArray are not able to modify the same array issue: Two useFieldArray instances are not able to modify the same array Jun 5, 2024
@BrendanC23
Copy link

The docs say this about using multiple field arrays:

Each useFieldArray is unique and has its own state update, which means you should not have multiple useFieldArray with the same name.

I think this is working as intended. Can you just pass the fieldArray to <JobActions />?

@bolencki13
Copy link
Author

This seems like a bit of a design flaw. One of the benefits of a context is to prevent passing props down the chain. While in the minimal example above it might make sense to pass this instance around, in a more complex real world example it seems like an anti-pattern having to create an instance top level and pass it down multiple branches various levels.

I'd like to understand the design choice, is there a particular reason for this requirement?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants