Debugging / Inspecting EventEmitters

As I explore Phaser 3 I am finding many cases where I need to respond to an event and I often find it hard to figure out if there is an event already being emitted for it and if so, exactly what the name of said event is. Documentation on this can be difficult to navigate or even just not yet there (given it is all still WIP).

When I look at the EventEmitter class itself, I see it can list all the registered listeners which is nice, but what I need to know is what events is it actually emitting. So far, the only consistent way I’ve found to find this out (short of it being documented) is by searching for something like ‘.emit(’ in the source code of the object in question.

Is there a better way? Is there some way I could override the emit() function to log the event name to the console as it emits? I would want to do this with other objects, not ones that I myself have created and with existing instances of said objects. For example, I have an existing GameObject made using a scene factory and I want to tap into its emit() method so it will log what it does.

Ultimately just longing for a quicker way to figure out what all these ‘events’ are that are already flying around so I can find the perfect one by inspection rather than having to dig through the code or wait for better documentation!

Thanks!
Seth B.

At the moment, looking through the source code is probably your best bet. I don’t rely on the documentation too much but I’ve heard several times that it doesn’t explain events well enough.

Currently, events are being refactored to use separate modules for the event names. This should, as far as I know, make it much easier to tell which events exist, even without using the documentation. This change will be in Phaser 3.16, which is planned to come out before the end of the month.

1 Like

Thanks for the reply! That sounds encouraging. I will try taking a look at some of the current deb branch changes to see what the refactor looks like. I’m excited for 3.16 even more now (this plus the ScaleManager will be very welcome!)

Seth B.

This is a good idea and I think this is exactly the method you would use.

Also v3.16 will document tons of events, maybe all of them.

1 Like