MrGVSV / bevy_proto

Create config files for entities in Bevy
Other
239 stars 25 forks source link

Properly handle nested schematics #62

Open sleepy-kitten opened 1 year ago

sleepy-kitten commented 1 year ago

Currently nested schematics are really restrictive.

// works
#[derive(Component, Reflect, Schematic)]
#[reflect(Schematic)]
pub struct Foo {
    bars: Vec<Bar>,
}

#[derive(Component, Reflect, Schematic)]
#[reflect(Schematic)]
pub struct Bar {
    duration: f32,
}
// does not work
#[derive(Reflect)]
pub struct DurationInput(f32);

impl From<DurationInput> for Duration {
    fn from(value: DurationInput) -> Self {
        Duration::from_secs_f32(value.0)
    }
}

#[derive(Component, Reflect, Schematic)]
#[reflect(Schematic)]
pub struct Foo {
    bars: Vec<Bar>,
}

#[derive(Reflect, Schematic)]
#[reflect(Schematic)]
pub struct Bar {
    #[schematic(from = DurationInput)]
    duration: Duration,
    #[schematic(asset)]
    handle: Handle<Baz>,
}

While the first example works, as soon as you add more complex types to Bar such as a Handle or Duration like in the second example, serialization will fail because the #[schematic] attributes are not respected. Another issue is that Bar has to derive Component, which might not make sense in a context where it is only used inside of Foo and not as a component itself.