Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly handle nested schematics #62

Open
sleepy-kitten opened this issue Oct 5, 2023 · 0 comments
Open

Properly handle nested schematics #62

sleepy-kitten opened this issue Oct 5, 2023 · 0 comments

Comments

@sleepy-kitten
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant