What problem does this solve or what need does it fill?
As it stands there can only be one component hook per component.
While this is an acceptable limitation for most components, it is very limiting when working with relationships, as Bevy's relationship implementation uses component hooks to set things up and enforce invariants.
What solution would you like?
With the introduction of components as entities (#23988) we could reasonably model this with relationships
world.spawn((
Component,
related!(ComponentHooks[
(OnAdd, ComponentHook(|_world, _ctx| {})
(OnAdd, ComponentHook(|_world, _ctx| {})
])
));What alternative(s) have you considered?
Do nothing
Keep things as they are, it's not a massive deal that relationships can't have custom component hooks, but it might make things trickier if we want to introduce more built-in component hooks
Alternative relationship design
Change the design of relations around component hooks, so that they do not take up the only component hook slot.
Additive hooks
Weaken the "one hook" constraint, by only allowing "additive" hooks, chaining together function calls but only storing a single function pointer.
Make defining hooks for relationship types Just Work by automatically converting e.g. derive macro hooks into this form.
Additional context
#12647 was opened previously intending to do the same thing but was closed since the cases described were already covered by observers, but I don't believe relationships were mentioned during the conversation.
What problem does this solve or what need does it fill?
As it stands there can only be one component hook per component.
While this is an acceptable limitation for most components, it is very limiting when working with relationships, as Bevy's relationship implementation uses component hooks to set things up and enforce invariants.
What solution would you like?
With the introduction of components as entities (#23988) we could reasonably model this with relationships
What alternative(s) have you considered?
Do nothing
Keep things as they are, it's not a massive deal that relationships can't have custom component hooks, but it might make things trickier if we want to introduce more built-in component hooks
Alternative relationship design
Change the design of relations around component hooks, so that they do not take up the only component hook slot.
Additive hooks
Weaken the "one hook" constraint, by only allowing "additive" hooks, chaining together function calls but only storing a single function pointer.
Make defining hooks for relationship types Just Work by automatically converting e.g. derive macro hooks into this form.
Additional context
#12647 was opened previously intending to do the same thing but was closed since the cases described were already covered by observers, but I don't believe relationships were mentioned during the conversation.