bevy_reflect should probably expose a reflected graph or tree data structure.

[maxwellodri]

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

Trees/Graphs are a really common data structure in Game Dev (think anything from animation blend trees to pathfinding to bevy's own scheduler). Sooner or later bevy itself is going to need this as well, such as for any kind of node editing inside a future bevy editor.

Trees/Graphs are the only kind of 'core' data structure that aren't reflectable. While most graphs are often stored as two arrays internally for performance, this isn't particularly nice to work with directly. And so it would be nice if any reflection impl took this into account.

What solution would you like?

For now I would consider implementing reflect (by deriving it) on the types in the petgraph library. Its already a part of the bevy dependency chain (direct dependency of naga and so bevy_render/wgpu depend on it).

In the long run a custom reflect impl with a new trait (Graph?) might make developing things like node editing in the future easier to work with. I'd imagine the way forward looks something along the lines of either a new trait for Graph-like reflection or exposing a bunch of methods for working with them and just representing them as a two List types.

What alternative(s) have you considered?

1) Let users roll their own - not the nicest since bevy will eventually run into this problem itself. 2) Use another library besides petgraph or implement a graph data structure in something like bevy_utils directly

Additional context

Initially discussed https://discord.com/channels/691052431525675048/1000062489993695364

[CGMossa]

I'm using petgraph. It is not ideal. And it needs a ton of love. But I don't know if it is feasible for bevy to create a competing crate. It will take so much churn.