Alpine: How to prevent inner elements from triggering mouse events?

[mikebronner]

Consider the following: https://jsfiddle.net/cshoypu8/2/

What ends up happening is that the HTML elements within the photoRight element call the drag function. How can this be avoided? And why are they responding in the first place -- isn't the event handler only added to the photoRight element?

[muzafferdede]

you can use pointer-events: none css way to avoid any pointer events. If you are using tailwindcss you can apply pointer-events-none class to those elements.

[mikebronner]

That's not a full solution in this case. I need to listen to different events in on the inner elements unrelated to this functionality. I'm asking more for clarity as to why things aren't behaving the way I would expect, rather than finding a work-around. Thanks though @muzafferdede :)

[ryangjchandler]

This is the nature of JavaScript events. See this codepen: https://codepen.io/ryangjchandler/pen/ZEbbZmG

Clicking the button inside of the <div> will cause the handler to be triggered (check the console).

When the button is clicked, an event is fired from the button but it bubbles up through the DOM and the handler attached to the div will react.

To stop the button from propagating upwards, you can add @click.stop to it. This calls event.stopPropagation() which will prevent bubbling.

In your case, you can add the event listeners to your nested elements using @click.stop="methodName()" and the events won't bubble up.

Let me know if you have any more problems! :)

[muzafferdede]

since he needs to use mousedown event, x-on:mousedown.stop='methodname() is the right way?

[ryangjchandler]

since he needs to use mousedown event, x-on:mousedown.stop='methodname() is the right way?

Exactly that. If one of the nested elements needs it's own mousedown event listener, but mousedown.stop should work fine.

I'm on mobile so formatting might be a bit off, sorry!

[mikebronner]

I had tried that. It seems the problem is the opposite in that the x-on:mousemove event is being registered on that element, but also on its child-nodes. This is what is confusing. I understand bubbling up, but this almost seems like bubbling down.

[ryangjchandler]

I had tried that. It seems the problem is the opposite in that the x-on:mousemove event is being registered on that element, but also on its child-nodes. This is what is confusing. I understand bubbling up, but this almost seems like bubbling down.

Interesting. I've got a PR ready to submit tomorrow that adds a new .self modifier for event listeners. It will only run the handler if the event target matches the element it was registered for (same as Vue's implementation). I think that might solve your problem.

In the meantime before it's merged and tagged, I'll see if there's another option :)

[ryangjchandler]

I've mentioned this issue in the PR above. I think this will solve your problems, let's hope it gets reviewed & merged soon :)

[mikebronner]

Yea, my work-around so far was to check if the event target matches the desired ref element. Seemed a bit clunky. Your PR sounds good.

[ryangjchandler]

Yea, my work-around so far was to check if the event target matches the desired ref element. Seemed a bit clunky. Your PR sounds good.

Yeah, I had a use case for the .self modifier and realised it didn't exist so it makes sense to add it. Hopefully it helps you out! Have a good one :)

[ryangjchandler]

Hi @mikebronner , hopefully we'll see the .self modifier in core soon. I'll be sure to update this issue if it gets merged in. Hope it hasn't been _too_ much of a problem for you :)

Also going to add the enhancement label to this issue, since it discusses an improvement to the project.

[ryangjchandler]

Hi @mikebronner, v2.3.0 has just been released with the new .self modifier so hopefully you can use that now for your project. I'm going to close this issue aswell, let me know if you have any problems :)