show these 'fully qualified paths' for bevy_remote's rpc

[alphastrata]

Objective

It is not obvious that one would know these:

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": [
    "bevy_animation::AnimationPlayer",
    "bevy_animation::AnimationTarget",
    "bevy_animation::graph::AnimationGraphHandle",
    "bevy_animation::transition::AnimationTransitions",
    "bevy_audio::audio::PlaybackSettings",
    "bevy_audio::audio::SpatialListener",
    "bevy_core_pipeline::bloom::settings::Bloom",
    "bevy_core_pipeline::contrast_adaptive_sharpening::ContrastAdaptiveSharpening",
   **... snipping for brevity ...**
    "bevy_ui::ui_node::Node",
    "bevy_ui::ui_node::Outline",
    "bevy_ui::ui_node::ScrollPosition",
    "bevy_ui::ui_node::TargetCamera",
    "bevy_ui::ui_node::UiAntiAlias",
    "bevy_ui::ui_node::ZIndex",
    "bevy_ui::widget::button::Button",
    "bevy_window::monitor::Monitor",
    "bevy_window::window::PrimaryWindow",
    "bevy_window::window::Window",
    "bevy_winit::cursor::CursorIcon",
    "server::Cube"
  ]
}

Especially if you for example, are reading the GH examples because:

If you for example expand these things, due to the number of places bevy re-exports things you'll find it difficult to find the true path of something.
i.e you'd probably be forgiven for writing a query (using the client.rs example):

$ cargo run --example client --  bevy_pbr::mesh_material::MeshMaterial3d | jq
{
  "error": {
    "code": -23402,
    "message": "Unknown component type: `bevy_pbr::mesh_material::MeshMaterial3d`"
  },
  "id": 1,
  "jsonrpc": "2.0"
}

which is where

bevy/crates/bevy_pbr/src/mesh_material.rs

Line 41 in 8d9a00f

pub struct MeshMaterial3d<M: Material>(pub Handle<M>);

would lead you to believe it is...

I've worked with bevy a lot, so it's no issue for me, but for others... ?

However, running this new example:

$ cargo run --example list_all_paths --features="bevy_remote" | jq | rg MeshMaterial3d
...
 "bevy_pbr::mesh_material::MeshMaterial3d<bevy_pbr::pbr_material::StandardMaterial>",

Solution

• another example.

Testing

Yes, I ran them. and have been using the output from for the last hour or two.

---

Showcase

Instead of encouraging this:

cargo run --example client --features="bevy_remote" -- bevy_pbr::mesh_material::MeshMaterial3d

We could suggest something like this:

cargo run --example list_all_paths --features="bevy_remote" | jq '.result[] | select(contains("Material"))'

NOTE: ReflectSerialize isn't a thing on MeshMaterial3d, nor indeed on many of the paths that one might explore on the list of returned 'things', but the point should still stand...

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[alphastrata]

👍🏽

[alice-i-cecile]

Hmm. I can see why this would be useful, but I think it's probably better suited as a doc test in the module docs.

[alphastrata]

Hmm. I can see why this would be useful, but I think it's probably better suited as a doc test in the module docs.

Am I correct in thinking that if they are here [in examples] they're scraped for the docs, but not the other way around?

Happy to move them though. @alice-i-cecile whatever you want to do is fine with me.

[alice-i-cecile]

Examples getting scraped is a good argument, but Bevy's examples are already rather numerous. I'd like to reserve them for teaching things that must be interactive / rendered, so let's move this information into the docs.

[BenjaminBrienen]

Examples being visual examples only will help delineate that and it makes sense, since examples are shown on the website as a "look at this". Although, many crates don't have anything to do with visuals and might benefit from bigger examples that aren't well suited to a doc test.

[alice-i-cecile]

Although, many crates don't have anything to do with visuals and might benefit from bigger examples that aren't well suited to a doc test.

Yeah, things that demonstrate end-to-end usage patterns can be valuable to teach in examples too! But small snippets / notes like this should just go in the docs.

[alphastrata]

Although, many crates don't have anything to do with visuals and might benefit from bigger examples that aren't well suited to a doc test.

Yeah, things that demonstrate end-to-end usage patterns can be valuable to teach in examples too! But small snippets / notes like this should just go in the docs.

I will move them over the weekend. --standby

[alphastrata]

We thinking something like this:

i.e have them on the BrpRequest docs? or something more... prominent?