-
-
Notifications
You must be signed in to change notification settings - Fork 23
Description
We can detect component addition / removal by overriding the onAdd / onRemove methods in our component class. However, by doing that our components become effectively more than simple data objects. Sure, we could include a reference to another handler for these events in the component and then call that handler's methods instead, but that kind of defeats the purpose of data only component classes. I expect this to also make serialization / deserialization harder when non serializable data is involved.
In my use case I am using a physics library that uses physics bodies which require manual cleanup logic when they get removed. My only option right now is to detect the removal via the onRemove method in the component to trigger the cleanup logic that depends on state stored outside of the ECS. In general I think it's a good design if systems (more broadly code that manages components) depend on components not the other way round.
I tried to use the family onRemove hook but noticed that these hooks get called after the component was removed already so I cannot use it for clean-up.
So what I propose is to add methods similar to the family onAdd / onRemove hooks that would internally register to ComponentsHolder and provide the component as a parameter when called.