New property to force swiping in a single direction

[leodido]

Referring to discussion in #4 I added a new property - i.e. single-direction to force the swiping to work only in the same direction eventually specified by swipeLeft or swipeRight property.

When single-direction property is set on <paper-swipe> the component can only swipe towards the edge chosen.

This PR does NOT introduce any breaking change.

I also added two demo blocks.

[motss]

@leodido So basically you want the following behavior, am I right?

_New behavior:_

swipeLeft	swipeRight	Expected result
0	0	no swiping is allowed (which is equivalent to disableSwipe is set
0	1	ONLY swipe to the right
1	0	ONLY swipe to the left
1	1	Can be swiped to either side

where 0 equates false while 1 equates true

_Old (or current) behavior:_

swipeLeft	swipeRight	Expected result
0	0	Can be swiped to either side
0	1	ONLY swipe to the right
1	0	ONLY swipe to the left
1	1	No support for this

where 0 equates false while 1 equates true

[leodido]

Hi @motss, not exactly.

I think it is correct that this component always swipe (except when user explicitly disables it), since it's called <paper-swipe>.

Simply it should also be able to constrain the swiping direction (1st aspect). Indeed now there is not a way to disallow entirely the swiping in the opposite direction. This was the reason for the introduction of the singleDirection property.

In #4 I was referring to the meaning of swipeLeft and swipeRight properties. Infact they currently simply refer to the edge to which the swipeable container pins at when swiping (2nd aspect).

I think this is the current behavior.

swipeLeft	swipeRight	Container edge to which it pins at	Swipes to left	Swipes to right
0	1	right	yes	yes and pins
0	0	both	yes and pins	yes and pins
1	0	left	yes and pins	yes
1	1	both	yes and pins	yes and pins

Rather the behavior I'm trying to introduce (and to complete) with this PR is.

Assuming singleDirection is not set (i.e. false).

leftPeek	rightPeek	Container edge to which it pins at	Swipes to left	Swipes to right
0	1	right	yes	yes and pins
0	0	both	yes and pins	yes and pins
1	0	left	yes and pins	yes
1	1	both	yes and pins	yes and pins

Assuming singleDirection is set (i.e. true).

leftPeek	rightPeek	Container edge to which it pins at	Swipes to left	Swipes to right
0	1	right	until reaches the left edge	yes and pins
0	0	both	yes and pins (singleDirection not applicable)	yes and pins (singleDirection not applicable)
1	0	left	yes and pins	until reaches the right edge
1	1	both	yes and pins (singleDirection not applicable)	yes and pins (singleDirection not applicable)

What do you think about?

If you agree I could proceed with another commit.

[motss]

@leodido I like the idea of disallowing the element to swipeable element to left when swipeRight is set and vice versa. As you know, the current one will move the swipeable element back to its original position while you're dragging it to the opposite direction. That is totally intended to indicate that you're not allowed to swipe to the opposite direction no matter how hard you try to but the current outcome is like what you mentioned (you can swipe to both direction but the swipeable element is pinned at, say right when swipeRight is set).

This is my proposal and feel free to leave comments:

• Change the name of singleDirection to noOppositeSwipe (is this better?)
• Instead of having another method _directionAllowed, maybe we can modify somewhere so that you can still swipe to the opposite direction but you don't see the swipeable element moving at all as the swipeable element has been restricted to just one direction, left or right. Your approach works fine except you didn't account for the situation where the user might want to swipe to the opposite direction first. When swipeRight is set, you try to swipe in the opposite direction first which is left then you will soon realize that you can no longer swipe to the right unless you trigger the _upHandler event to release tracking. In short, users are allowed to swipe to either direction but the drawer is allowed to move in ONLY one direction. This might be a better one:

swipeRight	swipeLeft	noOppositeSwipe	swiping direction allowed	swipeable element
0	0	x	both	swipe to either side and pin, noOppositeSwipe does not apply here.
0	0	x	both	swipe to either side and pin, noOppositeSwipe does not apply here.
0	1	0	both	swipe to left and pin, but can be dragged to the right with a maximum distance defined by slideOffset and back to original position once released.
0	1	1	both	swipe to left and pin, cannot move even a bit in the opposite direction.
1	0	0	both	swipe to right and pin, but can be dragged to the left with a maximum distance defined by slideOffset and back to original position once released.
1	0	1	both	swipe to right and pin, cannot move even a bit in the opposite direction.
1	1	x	both	swipe to either side and pin, noOppositeSwipe does not apply here.
1	1	x	both	swipe to either side and pin, noOppositeSwipe does not apply here.

• If possible, please help me to remove the iron-resizable-behavior import, iron-resize event listener, and the _resize method.

[leodido]

• [x] Agree for noOppositeSwipe, very good name.

• [x] Get rid of IronResizableBehavior

• [x] Locally I removed IDE files (i.e., .idea/ commited folder) and inserted them into .gitignore. I think they should not be in the repo. Can I commit this change?

• [x] Since the track event is on the host and not on the swipeable content I think we should restrict it. E.g., when dragging/swiping on the orange part (see demo) the drawer should not respond. Locally I've a working solution. If you agree I commit it.

• [x] Regarding your table. If I not misunderstood it, beyond little details, we perfectly have same idea. Here we are!

• [ ] Your idea of slideOffset is a good one ..

• [x] ~~Yes _upHandler should be triggered.~~ You're right.

  The track event must be not ignored when user drags (without releasing pointer) in the allowed direction after having dragged in the opposite and disallowed direction.

[motss]

Locally I removed IDE files (i.e., .idea/ commited folder) and inserted them into .gitignore. I think they should not be in the repo. Can I commit this change?

Much appreciated. Thanks.

Since the track event is on the host and not on the swipeable content I think we should restrict it. E.g., when dragging/swiping on the orange part (see demo) the drawer should not respond. Locally I've a working solution. If you agree I commit it.

Worth taking a look.

[leodido]

Hi @motss I think here we are. What do you think?

We can posticipate you good idea about slideOffset.

P.S.: Probably, to fire a opposite-edge event make sense. P.P.S.: Also investigating a debounce on (some or all event handlers) can make sense.

[motss]

@leodido Thanks for the update.

• [x] ~~Yes _upHandler should be triggered.~~ You're right.

The track event must be not ignored when user drags (without releasing pointer) in the allowed direction after having dragged in the opposite and disallowed direction.

Steps to repro this issue (Assuming on a touch device):

1. Create a paper-swipe and set swipeLeft and noOppositeSwipe to true.
2. A paper-swipe that is allowed to be swiped to the left is created and it is not allowed to move towards the right at all.
3. Drag the paper-swipe to the right (which is the opposite direction) without lifting your finger up then drag it to the left and see if there is any movement. If no, this behavior is incorrect as the paper-swipe cannot be moved at all at this moment even though it's still in the tracking stage not yet trackend.
4. Finger off the screen then try dragging it to the left then to right and see if any difference. (The paper-swipe should be able to move left and right without the finger leaving the screen and this is the correct behavior).

[motss]

P.S.: Probably, to fire a opposite-edge event make sense.

Why is this needed?

P.P.S.: Also investigating a debounce on (some or all event handlers) can make sense.

Is it because of performance issue?

[leodido]

Why is this needed?

Could be useful for the user to detect when _curPos is null/0 ?

Is it because of performance issue?

Yes.

Steps to repro this issue (Assuming on a touch device):

1. Create a paper-swipe and set swipeLeft and noOppositeSwipe to true.
2. A paper-swipe that is allowed to be swiped to the left is created and it is not allowed to move towards the right at all.
3. Drag the paper-swipe to the right (which is the opposite direction) without lifting your finger up then drag it to the left and see if there is any movement. If no, this behavior is incorrect as the paper-swipe cannot be moved at all at this moment even though it's still in the tracking stage not yet trackend.
4. Then try dragging it to the left then to right and see if any difference. (The paper-swipe should be able to move left and right without the finger leaving the screen and this is the correct behavior).

I cannot repro the issue ... It is not clear to me, please help/explain. The only "limitation" I found is: User tries to swipe towards right, suppose event.detail.dx (distance from first track event pos) is 22, until the event.detail.dx is -22 (user is now dragging towards left), the handler does not start. When event.detail.dx is -23 is moves towards left.

[motss]

The only "limitation" I found is: User tries to swipe towards right, suppose event.detail.dx (distance from first track event pos) is 22, until the event.detail.dx is -22 (user is now dragging towards left), the handler does not start. When event.detail.dx is -23 is moves towards left.

Is this limitation found before or after this PR?

I cannot repro the issue ... It is not clear to me, please help/explain. I already tried my best to explain though. Let's give it another try.

This element as the name implied is able to swipe to either side of the screen and it goes off the screen and never come back or disappear just like any swipeable cards or notifications that you can probably find on iOS and Android.

To add more functionalities for the user to customize the swipeable behavior, there are a few things introduced:

1. slideOffset - the minimum distance you swipe to make the swipeable element to move itself all the way to the edge of the screen and it can go off the screen or show a portion of itself from the edge defined by peekOffset.
2. swipeLeft and swipeRight to limit the direction that swipeable element can be swiped to. However, the swipeable element will kind of bounce back to its original position while swiping in the opposite direction like so:

A few things aim to fix in this PR:

1. Add a new property noOppositeSwipe to totally eliminate the bounce back effect while swiping in the opposite direction.
2. Limit the distance of the swipeable element can move while swiping in the opposite direction using slideOffset so that a) it can preserve the bounce back effect and b) to correct the behavior as the current one user can actually swipe the entire thing off the screen but it will come back later on which get the user into thinking that why can't it swipe in that direction.

[leodido]

Hey @motss I'm back.

So, in summary what this PR misses is:

• [x] Limit the distance the swipeable content can move towards the opposite direction to slideOffset.

It is correct?

---

Some considerations on this topic. The property slideOffset refers to the numbers of pixels needed to trigger auto-slide to the edge. Why to use it also to limit the bounce in the opposite direction? In this regard, we may introduce a second property (e.g., oppositeBounceOffset or simply bounceOffset) to give the user the ability to handle exclusively this concept. What do you think? Furthermore: the bounce effect in the case of noOppositeSwipe is set should be restricted to the opposite direction or also to the primary direction?

[motss]

slideOffset is adequate. By default, we need to drag at a distance beyond the value of slideOffset and release the draggable panel. It will slide all its way to the edge. So we should limit the distance in the opposite direction instead of allowing users to drag it beyond the slideOffset if noOppositeSwipe is true.

Furthermore: the bounce effect in the case of noOppositeSwipe is set should be restricted to the opposite edge or also to the primary edge? Opposite edge? primary edge?

[leodido]

Hey @motss, have you seen the last commit?

[leodido]

\ping @motss

[motss]

@leodido Might need some time to review.

[leodido]

ping @motss