Filtered observers

[alice-i-cecile]

What problem does this solve or what need does it fill?

When working with lifecycle observers (OnAdd, OnRemove, OnInsert and OnReplace), simply watching for changes to a single component type is often too broad. Instead, it's common to want to filter for the addition / removal of a component and the presence of another component.

What solution would you like?

Add another generic F to Trigger, which ensures that entities match that filter before observers are triggered targeting that entity.

What alternative(s) have you considered?

This can be worked around now by adding a second query to your observer, and checking if the target entity is comtained in the query. This is heavy on boilerplate for such a common pattern, and wastes work by dispatching events and repeatedly regenerating the query.

We could instead add a generic F: QueryFilter filter to OnAdd and other lifecycle observers , defaulting to (). If this generic is set, verify that the target entity matches the provided filter before triggering the observer.

On reflection, I like this solution less than modifying Trigger, as it's less general / powerful and requires more duplication. It's also less consistent with the existing B: Bundle generic, which is found on Trigger, not on e.g. OnAdd.

Additional context

#14649 is related but distinct.

#15325 proposes a change to the first generic.

Discussed on Discord with @maniwani and @NiseVoid.

[alice-i-cecile]

@cart has proposed the addition of "multi-event observers", which would cover similar patterns.