-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Suggested / related components #16246
Copy link
Copy link
Open
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-DocsAn addition or correction to our documentationAn addition or correction to our documentationC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-DocsAn addition or correction to our documentationAn addition or correction to our documentationC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!
What problem does this solve or what need does it fill?
Required components are great for explaining the relation between components when the relationship is mandatory, but aren't great when it's optional.
We've seen this come up in Bevy itself, with various texture atlas components being fully optional, but being intended to work with both UI images and sprites. Similarly, we could split a lot of fields off of
Node(previouslyStyle) by simply making them have no effect when they're missing. It would be really nice to have a standardized and tooling friendly way to explain these links.To take an example from one of my crates:
ActionStateandInputMapare intended to work together, but you can useActionStatewithout anInputMap(great for AI). It would be nice to be able to document that edge in a structured and straightforward way.What solution would you like?
A parallel
Componentannotation to therequires, calledsuggests. To start, this just generates documentation for theComponenttrait.Afterwards, this should store runtime information for tooling. This will allow us to draw a graph of components and their relationships.
Downstream crates should be able to augment the list of suggested components for components they don't own, to show where they hook into existing primitives.
Primarily, this generates documentation using
What alternative(s) have you considered?
We could manually document these, but a) it's more tedious to remember to do b) this can't be automatically discovered by tooling.
Additional context
Raised on Discord and was broadly popular there!