Remove or replace event listeners.

Discussion Ask a question
,
1

Hello. I’ve created a wrapper for $w that disables adding of multiple event listeners to element, so for example, every new onClick will rewrite previous one, instead of adding new. (wraps all methods where name starts with ‘on’). This way you can delete or replace event listeners.

https://github.com/skorokhod-andrii/wix-event-wrapper

Let me know if you find any bugs. Pull requests are welcome.
P.S.
If this package suddenly will stop working, without your changes in code site, then Wix probably changed something under the hood. If this happens, please add comment to this thread or create an issue in github and I will fix it ASAP.

5 Likes
2

@andriis , This is nice, and it’s working. I’m wondering if there’s a way to delete an event listener completely (so for example, in case of onClick() when you hover over an element the cursor won’t act as if it’s clickable).

3

Unfortunately it’s not possible now. I usually fix hover problem with the hack. By putting hidden svg or box on top of element.

4

Yes. But if you use this overlay hack (which I’m aware of, but not fond of), there’s no longer a reason to use your library to “delete” an onClick listener.
Anyway, it may be useful for other scenarios. Thank you!

I hope Wix Team will make a simple solution for it one day.
It shouldn’t be so complicated (but I guess it’s just not at the top of the priority list :slight_smile:

1 Like
5

That’s actually 2 problems. First is eventListener, seconds is css styles. Because under the hood it’s cursor: pointer css property forces us to use this hack, not unability to remove event listener.

6

Got you. I hope one day Wix will give us more control over such features (but indeed it’s not top priority).

1 Like
7

Very cool, I’ll have to play with this.

If I have one suggestion it would be to change the $ object to something more unique so it’s not identical to JQuery and gives people false hope.

1 Like
8

Hello. @skmedia . Thanks for suggestion. I’ve also thought about it, but failed to choose good namespace for it :slight_smile: I was thinking about $e. Anyway since it’s exported as default, any name could be used.

9

@andriis I like $e much better! Currently wanting to test this on a Calendar app, but a data query parameter failure in published seems to be sabotaging my $e loop…

Will let you know how it goes once I figure out why only preview mode is working.

UPDATE: Everything is fixed now, except $e is failing to remove click event listeners. They are set in a loop intended to display the item’s link in the text at the top. However, when an item displays a month instead of a calendar item, I want to remove the click event so it does nothing.

I could use href instead, but it would be kind of annoying for the entire site to reload when an item is clicked, instead of simply changing directory.

10

@skmedia Hello. Thanks for using it :slight_smile:
I think that you are trying to remove eventListener from wrong itemId. It should be
$e(‘#kalItem’ + e) not $e(‘#kalEvent’ + e)

11

@andriis Total D’oh moment! Working flawlessly now, I’ll see if I can’t find some excuse to test the repeater code as well. Thanks!

1 Like
12

@andriis I’ll be testing the repeater code on a client’s site soon, but quick question:

Is there such a thing with Corvid as JQuery’s $.fn list that makes it possible to add methods to the selector? Or would you basically just have to do something similar to what you did and completely deconstruct the selector’s properties/methods and build it back up again first?

13

Sorry, @skmedia .
I completely missed notification of this message.
Nope. You can add a feature request for this though. I’m a little bit skeptical of adding methods to $w by yourself, because it could end up like mootols and Array.flatten. read more

14

@andriis Thanks, Andrii. I think it’s a problem that could be entirely avoided if people are responsible with naming schemes for their methods. Presumably if you install a package, it’s because you want its functionality, not for how much the method names click with you - but I guess it was a different time. JS is constantly inching closer towards functional programming anyway, so it’s not a huge deal.

15

Hello. Recently Wix changed the structure of returned element object a little bit, so for some sites, which were already affected by this change, this code will not work.
I’ve made small changes in git repo, that fixes the problem. So I suggest to copy this code to your project again.
P.S.
If someone is curious what had happened, it used to be, that event listeners were methods in prototype chain of returned object. But not they are methods of returned object.

//was
TextElement{
	__proto__: {
		onSomething() {}
		__proto__: {
   			onViewportEnter(){ }
		}
	}
}
//now
TextElement {
	onSomething(){ }
	onViewportEnter(){ }
}
16

Does the new code support both structures (=has back computability)?

17

@jonatandor35 yes.

1 Like
18

Another one braking change is added in the new viewer, that affects this wix-event-wrapper.

Now $w(‘something’) will return same object every time. It used to be different object.
I’ve made changes in repo again so it will work for old and new version of viewer.
Side effect of this change, so in the new viewer it is possible to add your own methods and attributes to returned element.

19

Nice side effect. Thanks you.

1 Like
20

Hello! @andriis this syntax doesn’t seems to work either:

$e(‘#something’).onViewportEnter(() => {
//
})

If I change the $e for $w, works smoothly.

Could you please help me?