Better handling of 'global' events from scripts

[yaustar]

There have been many forum posts over the years of users changing scenes or destroying entities that have scripts subscribed to global events such as mouse or touch input but forgetting or not knowing that they have to unsubscribe to them.

ie: https://forum.playcanvas.com/t/screen-to-world-undefined-when-switching-scenes/16592/7

I was thinking maybe there should be a script API that can handle subscribing to these events and automatically unsubscribe if the script is destroyed.

e.g

this.subscribe(this.app.mouse, pc.MOUSE_DOWN, someCallback, this);

I don't like that it adds another way to subscribe to an event though. Any ideas on how we can this more simpler to use and less error prone?

[yaustar]

Alternatively, (and I'm not keen on this either) is for the event handler to check the object type of the scope and automatically add an on destroy callback on the script to remove the subscription.

However, this relies on the scope being passed and extra bespoke logic on the event handler.

[Maksims]

I believe regardless of solution, it is an education issue, as destroying resources to clean up is a known concepts in realtime applications.

Unfortunately in engine event emitter does not return event handlers when subscribed. Which would simplify this:

let evt = app.on('event', callback);
// ...
evt.off();

I would start from modifying default script and add this:

MyScript.prototype.destroy = function () {
    // called when script is destroyed
    // remove related resources and references
    // and unsubscribe from external events
};

Something as we do with swap method, which being there, tells people about script behaviour.

[LeXXik]

Thanks to @Maksims, this is now supported by the engine, so we can probably close this.

[kungfooman]

AFAIK no, @yaustar's listen/unlisten PR never made it, so we still don't have automatic event "unlisten"-ing - but @Maksims' PR makes it way easier to implement now

[yaustar]

I closed my PR as it was discussed that adding a new API for events for scripts potentially made it less cohesive since there would be 2 ways to listen to events.

A 'silence' or some way to 'pause' event listening on the event handler may need to be added to handle disabling/enabling the script