Click or tap through swipeable component

[ArinCantCode]

Hi, i have my swipeable component which works great, but in some cases i have buttons under that div on which i detect the swipe and that causes the button to not being triggered when the user taps / click on it.

is there a way to not stop propagation on the swipeable component when my user taps so that the tap also works on elements underneath it?

[hartzis]

@ArinCantCode Thanks for posting the question/issue. I'm genuinely intrigued by this use case and would love to see an example we could work with and test against.

Do you think you could setup a codesandbox example of this use case please?

You could start by forking the example react-swipeable codesandbox if you'd like.

📓 additional note here, we're about to release v6, #185 . I dont think any changes would interact with this issue, but an example codesandbox would additionally allow us to experiment with v6.

UPDATE v6 has been released - https://github.com/FormidableLabs/react-swipeable/releases/tag/v6.0.0

And there is a new codesandbox we can fork from - example react-swipeable codesandbox

[Adonais0]

Hi I'm having the same problem. For example when the carousel item is something like <div><button onClick=()=> console.log("triggered")></button></div> and preventDefaultTouchmoveEvent = true with onTap(e) { e.event.preventDefault() }, the onClick function in the carousel item cannot be triggered. Might be a potential bug.

[kayeew]

Any workaround for this? I have a similar issue in my carousel with ads. The swipes work well but my ads become unclickable. Something like this:

const myCarouselItem = () => {
    ...
    const handlers = useSwipeable({
            onSwipedLeft: onNext,
            onSwipedRight: onPrevious,
            onSwiped: () => setSwiped(true),
            preventDefaultTouchmoveEvent: true,
            trackMouse: true,
    });
    ...
    return (
        <CarouselItem {...handlers}>
            <Ads />
        </CarouselItem>
    )
}

[hartzis]

@kayeew Could you try the new v7 to see if that helps? if not could you try to create a codesandbox.io example that we can use to iterate on?

I'm also starting to suspect that there maybe an issue/bug related to these lines of code when trackMouse and preventDefaultTouchmoveEvent/preventScrollOnSwipe are both enabled 🤔

react-swipeable/src/index.ts

Lines 189 to 196 in 3e417f5

	if (
	cancelablePageSwipe &&
	props.preventScrollOnSwipe &&
	props.trackTouch &&
	event.cancelable
	) {
	event.preventDefault();
	}

@kayeew also could you clarify the sceneario you're seeing a bit more please?

• Are the Ads not clickable only for touch(mobile)?
• Are the Ads not clickable only for desktop(mouse)?
• Are they initially clickable then become unclickable after the user has "swiped"?

[kayeew]

@hartzis

Something like this: https://codesandbox.io/s/react-swipeable-bug-6ej07l?file=/app/test.tsx

I noticed preventDefaultTouchmoveEvent is no longer in v7. The swiping and onclick works well now in my example but is there a way to not trigger an onclick event when user is swiping. The onclick event is currently still triggered on swipe left or right in my example.

[hartzis]

@kayeew Thank you for the example!

I tried it out a bit and I can replicate the issue, but only for a "mouse swipe"/trackMouse.

The issue does not appear to be happening for "touch swipes"/trackTouch.

When I use the example in dev tools mobile mode and on my mobile device everything appears to be working correctly.

Is desktop mouse swiping an important aspect of what you're building? just curious.

📓 Notes:

• I am starting to suspect there is an issue with the confluence of trackMouse and preventScrollOnSwipe
• additionally there appears to be some prioritization or intersection of the onClick browser event and mousedown/mouseup that swipeable could maybe handle
  • This will take some additional exploration

[t-kietzmann]

Hey all, i have a similiar issue. I want to use this package for opening a hamburger-menu with a swipe gesture, i defined a div with 30% width and a full height as "swiping area" - but all buttons on all my pages don't work of course when the layer is on top of them. Is there a workaround to fix this?
Many thanks
Tobi

[jalatiphra]

the issue from t-kietzmann is exactly my issue too
the library works great on visible elements. but something like a drawer / sidebar which is default 100% hidden can only be pulled into the view by defining a div with a handler ontop of the visible content (position fixed) , but this area is overlaping with other visible elements of the default UI . which cannot be clicked with a mouse then.
trackmouse on or off does not matter. its not the fault of the library, its because there is a transparent Div on top of the normal content. - and you cant click "through" that
I have seen this functionality working as expected on reddit for example and i wonder how this is achieved.
the idea of attaching the handler to a div is not covering this usecase. can't we detect the touches on the viewport directly?

https://codesandbox.io/s/react-swipeable-document-swipe-example-1yvr2v
maybe this will help me

yes. that works as i would expect it to.

[hartzis]

@t-kietzmann & @jalatiphra Could you try attaching a listener to the document and that may get your closer to your desired outcome?

https://github.com/FormidableLabs/react-swipeable#how-can-i-add-a-swipe-listener-to-the-document

[Peatral]

I have exactly the same issue as @t-kietzmann and @jalatiphra.

Attaching a listener to the document works as one would expect but creates a whole new set of problems. While checking if the initial x position is in a certain range of the screen is easy, dialogs are way worse. Because dialogs pop over the whole page and don't prevent the event from firing, you are able to swipe open the menu with a dialog open, which is definitely something that should be prevented. When using an invisible div, this wouldn't be a problem, but when using the document, I now have to use a context to track if any dialog was opened and block the hamburger menu based on that. That solution works fine, but compared to the invisible div where it would work out of the box it just seems a little unnecessarily complicated.

Using a div that does pass through mouse events would be the preferred solution by far.