How Can I Insert/Remove a Custom Component With ComponentId?

[zicklag]

I'm trying to understand how to insert a custom component I've registered with world.init_component_with_descriptor().

All component insertions are handled through the Bundle trait now, and I see new docs on Bevy main branch that say you should not implement Bundle ( like ever, is the impression I get from the wording ).

A lot of the other APIs that might be used for insertion are private, so that leaves the only way I can see to insert a custom component to be implementing the Bundle trait.

But it also feels like there should be much easier ways to do certain things like, for instance, removing a component from an entity by passing the ComponentId. I think that function could be 100% safe, and actually useful in scenarios where you want to remove all the components from an entity.

Inserting custom components wouldn't be safe in any way I don't think, but there should still be a way to do it, and probably without implementing Bundle.

Maybe we can create a CustomComponent struct that implements Bundle and is something like this:

struct CustomComponent<T> {
    /// The ID of the component to insert
    component_id: ComponentId,
    /// The component data
    data: T,
}

We could make it's constructor unsafe and then implement Bundle on it.

The unsafety of the constructor would be centered around the fact that T much match the underlying layout that the component with the given ComponentId was registered, if I'm getting that right.

---

Anyway, any thoughts?

[jakobhellermann]

#5602 adds the methods insert_by_id(ComponentId, OwningPtr<'_> and insert_bundle_by_ids(Vec<ComponentId>, impl IntoIterator<Item = OwningPtr<'_>>). Would that work for you?

To do that the PR also splits the Bundle trait into the part that just needs to read the value (used for insertion) and the rest that currently requires statically knowing the component types.

[zicklag]

Yes, that would cover insertions fine!

I'd still need the ability to remove components with the ID, but that could be a separate change.

[DJMcNab]

Your belief that

struct CustomComponent<T> {
    /// The ID of the component to insert
    component_id: ComponentId,
    /// The component data
    data: T,
}

Could implement Bundle is precisely the reason that the docs say to never ever implement Bundle - implementing it is an attractive nuisance.

The design of the Bundle trait is (currently) such that the style of API you suggest cannot work; each CustomComponent<T> would instead need to be statically associated with a single component id, which isn't possible.

[zicklag]

The design of the Bundle trait is (currently) such that the style of API you suggest cannot work;

Ah, I see, my implementation was not possible because component_ids has no &self parameter. The Bundle trait can only depend on static type information in its implementation.

Edit: That also makes it seem more reasonable that the docs say not to implement, because there's no good reason to implement. The only use-case would be dynamic scripting-type scenarios like I'm in, but it's not even useful for that because it's stuck to the Rust type system.