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

Overriding sorting behavior #77

Open
oyeanuj opened this issue Mar 12, 2017 · 10 comments
Open

Overriding sorting behavior #77

oyeanuj opened this issue Mar 12, 2017 · 10 comments

Comments

@oyeanuj
Copy link

oyeanuj commented Mar 12, 2017

Hi @JakeSidSmith, sorry, I forgot to create an issue to continue our discussion in #71 but here it is now :)

To recap, in my use case, if a user drops an item in between others, it sorts the list but if the item is dropped on top of another, I can perform a different operation. So, to do this, I would need to know if an item is dropped on top of another ( or within certain boundaries of the new item and then not calculate new position in this case), or above or below the other (calculate new position in this case).

So, as I see it, the cleanest way, in terms of API might look something like this -

  1. A prop, lets say sortZoneLimitPercent passed to Reorder that indicates what % area of the item to limit the dropzone to. So, by default, today that is 100%. If it is passed as 60, that means the top and bottom 20% of the item would not be considered as 'sortZone`.

  2. An additional prop added to onReorder and onReorderGroup callback that indicates whether the item was dropped within the boundaries of an item, or outside, i.e. if sortZone is true or not.

Thoughts?

@JakeSidSmith
Copy link
Owner

Ah, I didn't realise you'd need a specific droppable area. Can't use margins between them? I guess styles should remain separate from functionality, so adding some way to configure this would be good.

Although you can achieve something similar with CSS: https://jsfiddle.net/fr7syq3d/

@JakeSidSmith
Copy link
Owner

Actually, scratch that CSS, that'd also mean you could only drag by clicking inside the droppable area... :|

@JakeSidSmith
Copy link
Owner

I'll have a think about possible ways to do this and try to get it into v3. :)

@oyeanuj
Copy link
Author

oyeanuj commented Mar 12, 2017

Yes, I realized that having a droppable area makes it configurable and more reusable, given that we anyways have a default of 100%. Also, +1 to not using CSS for this as it is really functional :)

@champeng
Copy link

champeng commented May 3, 2017

+1 👍

@champeng
Copy link

champeng commented May 3, 2017

If it is passed as 60, that means the top and bottom 20% of the item would not be considered as 'sortZone`.

@oyeanuj I think passing 60 would mean that top and bottom 30% would be the only place for sorting the list i.e. top and bottom 30% should be considered as sortZone and middle 40% would be considered for drop over existing element.

@oyeanuj
Copy link
Author

oyeanuj commented May 3, 2017

@champeng Yes, you are right! I meant top and bottom would be considered sortZone and middle area would be dropZone.

@JakeSidSmith Any other thoughts since your last comment? 😄

@JakeSidSmith
Copy link
Owner

JakeSidSmith commented Aug 6, 2017

@oyeanuj sorry, been pretty busy with other projects / new version of react-reorder.

Something I have been using a bit in v3 is data attributes for new features. I could add something that looks for data-drop-zone and checks this element for collisions if one is found. This way you can completely configure which area of your items should be allowed drops.

@oyeanuj
Copy link
Author

oyeanuj commented Aug 6, 2017

@JakeSidSmith Thanks for the response! So, if the attribute is set, then the library checks for collision? And then that would imply the need for some props to determine collision boundaries?

@JakeSidSmith
Copy link
Owner

@oyeanuj you'd set the data attribute on an element inside one of your items, and then it'd check for that, and check for collisions against that element, rather than the root node of an item.

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