Repository navigation
Add serde support to bevy_dev_tools inspection types - #25866
Conversation
da5cbae to
950d43f
Compare
950d43f to
3a89acc
Compare
Nilirad
left a comment
There was a problem hiding this comment.
The implementation seems correct, apart from some rough coners on the inspection type fields that are difficult to judge on without real usage feedback (e.g. whether we should serialize "ComponentId", or serialize spawn_details but deserialize it back to None). Those concerns are very difficult to validate in a vacuum, so I don't block on that.
One thing to note is that despite what mentioned in the PR message, serialization for inspection summary types has not been added yet. This can easily be done in a followup PR, so I don't block on that. You can just remove the mention from the PR message.
Overall, it looks ok, and it looks very similar to the work I did months ago on feathers_inspector. Approved!
Thanks! Fixed the description, the summary serde derives ended up in #25883 alongside the BRP methods |
Stacked on bevyengine#25866. Review the last commit only pls! # Objective Part of bevyengine#23013. Expose the inspection backend over the Bevy Remote Protocol so remote tools get labels, metadata, display strings and structured values from one call instead of assembling them from raw queries. Ported from feathers_inspector, phase 5 of the upstreaming strategy there. The BRP module was originally written by @Nilirad. # Solution Seven instant methods in a new inspection methods module, registered with the other defaults. - `world.inspect` for an entity, `world.inspect_component` and `world.inspect_component_type` - `world.inspect_resource` and `world.inspect_all_resources` - `world.summarize` for entity, archetype and resource counts - `registry.component_metadata` for the type map clients cache Structured values are always on for remote replies. Unknown type names return a new error code. Serde derives for the world summary types are here too since they were waiting on the serde PR. Not exposed: the cached variant of inspect, multi-entity inspection and fuzzy name lookup, which wait on bevyengine#25010 and bevyengine#25028. # AI disclosure This is part of the inspector upstreaming series. When I started it, I worked out the goals and scope with Alice and used AI to split the working Jackdaw and feathers_inspector code into small reviewable pieces. For this one, AI did the mechanical port of the BRP verbs into `bevy_remote` and wrote the tests, and I reviewed the code and had it double check for problems. That turned up two things. CI never enables the `client` feature, so the new integration tests (and the client's own round trip tests from bevyengine#25837) would have compiled empty, which is why `bevy_remote` now lists itself as a dev-dependency with `client` on. CodeQL also flagged test assertions that printed whole JSON replies as cleartext logging, so those messages are gone.
Objective
Part of #23013.
The inspection types can be built and displayed but not sent anywhere. Remote tooling needs them as JSON, and an editing client needs the actual field values, not just a display string.
Ported from feathers_inspector, phase 4.3 of the upstreaming strategy there. Builds on #25823 and #25845.
Solution
Serde support for the inspection types behind the
serializefeature, plus structured values.withhelpers for component id, archetype id, debug name, storage type, the metadata map and spawn detailsserialized_valueon component and resource inspections, filled through the typed reflect serializer when the newinclude_serialized_valuesetting is onserde_jsonand the ecs, platform and utils serialize featuresThe two error types with a static string variant are serialize only. Spawn details serialize as tick and location and deserialize to none.
AI disclosure
AI assistance was used to help port these changes and to plan this upstream series from our existing Jackdaw functionality. All changes were reviewed by a human before submission.