Remove ComponentStorage and associated types

[james7132]

Objective

When doing a final pass for #3362, it appeared that ComponentStorage as a trait, the two types implementing it, and the associated type on Component aren't really necessary anymore. This likely was due to an earlier constraint on the use of consts in traits, but that definitely doesn't seem to be a problem in Rust 1.76.

Solution

Remove them.

---

Changelog

Changed: Component::Storage has been replaced with Component::STORAGE_TYPE as a const.
Removed: bevy::ecs::component::ComponentStorage trait
Removed: bevy::ecs::component::TableStorage struct
Removed: bevy::ecs::component::SparseSetStorage struct

Migration Guide

If you were manually implementing Component instead of using the derive macro, replace the associated Storage associated type with the STORAGE_TYPE const:

// in Bevy 0.13
impl Component for MyComponent {
    type Storage = TableStorage;
}
// in Bevy 0.14
impl Component for MyComponent {
    const STORAGE_TYPE: StorageType = StorageType::Table;
}

Component is no longer object safe. If you were relying on &dyn Component, Box<dyn Component>, etc. please file an issue to get this change reverted.

[alice-i-cecile]

Nice! Does this mean that we can store Box<dyn Component> without specifying an associated storage type finally? That would be really cool if so.

[james7132]

I don't think so. Actually I think that was the reason why it's still that way. Associated consts make the type not object safe. However, do we want to support Component trait objects? I don't think we can do anything with it, not even downcast.

[alice-i-cecile]

I don't think so. Actually I think that was the reason why it's still that way. Associated consts make the type not object safe. However, do we want to support Component trait objects? I don't think we can do anything with it, not even downcast.

Yeah, it's fundamentally not object safe. I'd still maybe like an object-safe subtrait for Bundle at some point for a "if X, insert bundle A, otherwise bundle B" but I don't think that's vital (and this change is orthogonal to it).

[christianlarrabure]

I was relying on

Box through the following methods:

pub trait SaveableComponent: bevy::prelude::Component<Storage = TableStorage> {
    fn to_json(&self, oidb: Res<ObjectIdMap>) -> Option<serde_json::Value>;
    fn from_json(
        &mut self,
        json: serde_json::Value,
        commands: &mut EntityCommands,
        oidb: &Res<ObjectIdMap>,
    );
    fn db_component_type(&self) -> SaveableComponentTypes;
}

pub fn to_component(&self) -> Box<dyn SaveableComponent> {
...
}

Is there an alternative to this now? I was using this type to selectively save some of my objects. My use case is very unique; I am making a text-based MUD game. So the normal saving methods that exist in the Bevy community are not appliable to me. I had to develop my own methods for it! Any help appreciated so that I can migrate to 0.14.

[alice-i-cecile]

Do scenes work for you? I don't see any particular reason why the typical reflection-based approach wouldn't be applicable in a text-based game.

Anyways, maybe make a Discussion so this can be seen more broadly?

[christianlarrabure]

We have a system which saves it to SQL, I believe that the one that is used saves it to a file? Is there any documentation I can review on the matter? I've been using the ECS more than other parts, so I am not so familiar.

[alice-i-cecile]

Scene::write_to_world_with is the core bit you need. There's an example for scenes, but it's not particularly useful for you. Instead, I'd recommend digging into the source there and getting a sense of how the type registry and reflection is used to list and then serialize components.