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

Add rotateOnDrag prop to give ability to disable rotation on drag #73

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

cgat
Copy link

@cgat cgat commented Nov 23, 2021

Add rotateOnDrag prop

The current rotation on drag implementation (web) works decently for smaller-sized cards like in the demo, but gets fairly janky for larger cards, especially when using the mouse on desktop.

This option allows the consumer to opt out of rotating on drag.

I've forked the demo to create a comparison: https://github.com/cgat/react-tinder-card-demo/tree/cgat/react-tinder-card-demo

Here's the demo. The first example is the current version of react-tinder-card. The second version is my update to react-tinder-card with the rotateOnDrag option set to true (default value). This should mostly be the same, but is also used to demonstrate a couple other fixes I added don't break things. The 3rd version is my update with rotateOnDrag set to false.
https://share.getcloudapp.com/xQujoXoG

To see what react-tinder-card looks like with bigger cards, I changed the card sizes in chrome inspector.
https://share.getcloudapp.com/d5u6X7qp

Haven't been able to test the react native change, but in theory it should work as well (likely less of an issue on native though)

cgat added 5 commits November 23, 2021 10:26
Originally, this line was setting `display` to `block` on restore. This assumed that the consumer of the `TinderCard` was using `block` to begin with. By simple removing the inline style, we allow the consumer to define what `display` property to use.
Removing `transform` from inline styles is preferrable to setting to 'none', as this is less prescriptive to the consumer.

`transition` is being removed rather set to `10ms` as this will presist on the element after you drag it again. In other words, the first time you drag a card, there will be no transistion on the transform, but after animateBack is trigger, transistion 10ms will presist, which in incurs performance overhead and makes the dragging process laggy.
The current rotation on drag implementation (web) works decently for smaller sized cards like in the demo, but gets fairly janky for larger cards, especially when using the mouse on desktop.

This option allows the consumer to opt out of rotating on drag.
@LinusU
Copy link
Collaborator

LinusU commented Nov 24, 2021

Could you run npx standard --fix and npx ts-readme-generator to fix all linting errors and update the API docs in the readme?

@cgat
Copy link
Author

cgat commented Nov 24, 2021

@LinusU done. Sorry I missed that.

@3DJakob
Copy link
Owner

3DJakob commented Nov 24, 2021

Hello @cgat! Thank you for contributing to this project. Your addition to this project looks great!

I only have one thought though. Maybe we should instead have implemented a prop called something like rotationMultiplier which would have multiplied the rotation. In that case you could still disable rotation by setting it to zero but you could also try to simply reduce the motion if you wanted to. What do you think about that? I think it would allow for more customisation while keeping the prop count the same.

@cgat
Copy link
Author

cgat commented Nov 24, 2021

@3DJakob yup, that works too. Updated.

This prop aside (which I think is a valid tool to tune the rotation for bigger cards), I do think there is an underlying performance issue while dragging. The movement of the card lags behind the movement of the cursor. This is especially the case with rotate. The calculations are pretty basic though, so I'm not sure what's causing it. Updating transform values like rotation and translate shouldn't cause the lag though. I guess this is more of a conversation for issues. One thing that crossed my mind is that multiple handleMove events will be executing in parallel, but all of them use the same lastLocation closure, so they are competing to update the value.

Anyway, thanks to the contributors

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

Successfully merging this pull request may close these issues.

3 participants