Add Reflect derive to Events and contained types

[alice-i-cecile]

Objective

The Events containerr should be reflectable, in order to make dev tools that examine its state more useful.

Fixes #13148.

Solution

• Add a Reflect derive to Events, gated behind the bevy_reflect feature
• Add Reflect to the contained types to make everything compile.

[ItsDoot]

Looks good for the most part.

[ItsDoot]

Should this be a ReflectValue instead? 🤔

[alice-i-cecile]

Hmm. It's definitely value-like. I can make that change if others think it's useful.

Suggested change

	pub struct EventId<E: Event> {
	#[cfg_attr(feature = "bevy_reflect", reflect_value]
	pub struct EventId<E: Event> {

[MrGVSV]

I think it depends. Do we ever want to access the id? If so, then we should probably leave it as is.

Although, I believe you will need to ignore the PhantomData.

[alice-i-cecile]

Yeah, you'll want to access the ID. I'll ignore the PhantomData.

[ramon-bernardo]

@alice-i-cecile thanks, its works!

use bevy::prelude::*;

#[derive(Component, Reflect, Default)]
struct Position;

#[derive(Event, Reflect, Default)]
struct MoveEvent;

#[derive(Resource, Reflect, Default)]
struct Houses;

fn main() {
    App::new()
        // Position
        .register_type::<Position>()
        // MoveEvent
        .add_event::<MoveEvent>()
        .register_type::<MoveEvent>()
        // Houses
        .init_resource::<Houses>()
        .register_type::<Houses>()
        // Systems
        .add_systems(Startup, startup)
        .run();
}

fn startup(registry: Res<AppTypeRegistry>) {
    let registry = registry.read();
    for i in registry.iter() {
        println!("{:?}", i);
    }
}

output:

TypeRegistration { type_info: Struct(StructInfo { type_path: TypePathVtable { type_path: "bevy::Houses", short_type_path: "Houses", type_ident: Some("Houses"), crate_name: Some("bevy"), module_path: Some("bevy") }, type_id: TypeId { t: 262497429019092159181105962761250037597 }, fields: [], field_names: [], field_indices: {} }) }
TypeRegistration { type_info: Struct(StructInfo { type_path: TypePathVtable { type_path: "bevy::Position", short_type_path: "Position", type_ident: Some("Position"), crate_name: Some("bevy"), module_path: Some("bevy") }, type_id: TypeId { t: 79962707724654762771215367196927044087 }, fields: [], field_names: [], field_indices: {} }) }
TypeRegistration { type_info: Struct(StructInfo { type_path: TypePathVtable { type_path: "bevy::MoveEvent", short_type_path: "MoveEvent", type_ident: Some("MoveEvent"), crate_name: Some("bevy"), module_path: Some("bevy") }, type_id: TypeId { t: 175823575746073673475871982974340081787 }, fields: [], field_names: [], field_indices: {} }) }

[MrGVSV]

Looks good! I think the one thing we might want to consider adding is a method on App to more easily register these events and their resources into the type registry.

[alice-i-cecile]

Looks good! I think the one thing we might want to consider adding is a method on App to more easily register these events and their resources into the type registry.

Agreed. Ideally we'd register the type during add_event, but without specialization that would require a Reflect (or equivalent) bound on Event. Ultimately this feels like a question for #13111.

[SkiFire13]

Is it intended to expose the events_a/events_b split of the Events resource and the internal EventSequence type?

[alice-i-cecile]

This seemed like the least intrusive solution at the time. This doesn't seem like a particularly dangerous implementation detail to provide backdoor access to, while ensuring that inspectors still work easily with events.