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

[feature] Expose newly created items list in confirmChange #112

Open
JeffWatson0 opened this issue Dec 11, 2023 · 6 comments
Open

[feature] Expose newly created items list in confirmChange #112

JeffWatson0 opened this issue Dec 11, 2023 · 6 comments

Comments

@JeffWatson0
Copy link

Description
Issue: Using the provided props users are able to prevent dragging of items, however we cannot prevent the re-ordering of items.

Feature Request - expose the new list of items in the confirmChange function. Allow consumers to use this data when evaluating a change.

Additional context
Will provide a PR for this change 😄

@primetwig
Copy link
Owner

hi. you can simply check if new parent is the same as current parent, then it is reordering, so you can prevent that. does that make sense?

@JeffWatson0
Copy link
Author

Hi @primetwig, thanks for getting back to me so quickly!
Thanks for the suggestion - your solution works great for nested children.

However, I am not able to find a way to make it work when reordering top-level items.

For my use case, I want to "hardcode" item A at index 0, but allow items B and C to move. I use the disableDrag function for item A (which works perfectly!)
Ex: Start

A
B
C

The problem happens when I try to move B to index 0.
Ex: After Moving B

B
A
C

props to confirmChange: dragItem = Item B, destinationParent = null

For these top-level item changes, the destinationParent is always null. There is nothing sent to confirmChange that can tell me a little more context about the other items that have changed, so we can asses the validity of the move.

@primetwig
Copy link
Owner

I see. It looks like destination index or the whole path (like in onChange) would help. Let me check what I can do...

@JeffWatson0
Copy link
Author

JeffWatson0 commented Dec 12, 2023

May I suggest you simply move the confirmChange call to after creation of the "new" items, and include the complete new items in the confirmChange signature?

Edit: like onChange would be perfect! 👍

@primetwig
Copy link
Owner

primetwig commented Dec 12, 2023

the thing is that moving item into position may have several options as to final result and I need to consider all of them.
example:

  • A
  • B
    • C

when you move A over B, it checks if it is allowed to put A into B, but in case it is not – it should also check if it is allowed to swap A with B, thought it does not check that.
so I need to handle that in the first place which will also give me (and you) more info in confirmChange in the end.

@JeffWatson0
Copy link
Author

PR open here: #113

Thanks for this library!

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

2 participants