Open Autsider666 opened 1 month ago
Coincidentally @eonarheim, @jyoung4242 and I were just discussing something like this. Good timing.
I don't think it should assume the owner is an actor, because entity + component = actor. Additionally components may need to emit events themselves so I wouldn't want them to simply alias everything to the owner. But forwarding update events from the entity would be good, since those are on all entities, and providing overridable onXYZ update methods like actors do.
It also would be better to extend or implement EventEmitter rather than just add an on method, as users may want to use once, off, etc. This would allow the component to emit its own events too.
It also would be better to extend or implement EventEmitter rather than just add an on method, as users may want to use once, off, etc. This would allow the component to emit its own events too.
You gave me an idea: What if we (de)register ((un)pipe) the component EventEmitter on the EventEmitter of the owner during onAdd/onRemove?
Calling (and maybe, in a later version, replacing?) onAdd/onRemove with component events would make it even better (because consistency)
The pattern we've been using other places is composition w/ method forwarding (inconsistently). (The ColliderComponent
is an example)
public events = new EventEmitter()
I don't think it should assume the owner is an actor, because entity + component = actor. Additionally components may need to emit events themselves so I wouldn't want them to simply alias everything to the owner. But forwarding update events from the entity would be good, since those are on all entities, and providing overridable onXYZ update methods like actors do.
Totally agree @mattjennings, we are of the same mind here.
You gave me an idea: What if we (de)register ((un)pipe) the component EventEmitter on the EventEmitter of the owner during onAdd/onRemove?
I think this is a totally resonable thing to do. ColliderComponent
does this manually to manipulate the shape of the event, but we can probably change this up and pick a single target/shape
Hmmm, no clue why, but the code that I posted at the start doesn't do anything in 0.29 for some reason. Weird...
Context
Having to manually manage all the listeners/subscriptions from listeners applied during
onAdd
and removed duringonRemove
takes a lot of time (in total at least) and can easilly be done wrong, causing all kinds of unexpected side-effects.Proposal
I've experimented with a few setups so far and this one is the easiest to use so far, but there's a lot of room for improvement.
There are a few points where my example would need some TLC:
Actor
. I guess it's 99% of the time correct for most people, but maybe split theon
function intoonActor
andonEntity
?on
function name is technically consistent with the event handling everywhere else, but it implies the existence ofoff
andemit
and it's not fully communicating the functionality of "add listener duringonAdd
and remove it duringonRemove
"event.owner
would be useful, but I ended up never using it + it's quite ugly.An example of how I used this code: