Making `EntityMapper` more flexible

[cBournhonesque]

What problem does this solve or what need does it fill?

In my networking library I have frequent use for mapping Entities from the server-world to the client-world, and vice-versa. I created my own EntityMapper trait

pub trait EntityMapper {
     /// Map an entity
     fn map(&self, entity: Entity) -> Option<Entity>;
}

but realized later that Bevy has its own trait.

However bevy's EntityMapper has some limitations:

• it can only call get_or_reserve, which maps the entity OR generates a new one. In my use-cases, I only need to map the entity or return a None if I could not do the mapping
• because of this, creating the EntityMapper needs access to the World, which is overly complicated in my use-case (since I don't need to generate new entities if the entity is missing from the mapping)

The reason why I cannot just use my own EntityMapper trait is that I want to implement it for the components Parent and Children, and both do not provide any mutable access to the inner entity stored inside them, so I cannot actually perform any entity mapping. Would it be possible otherwise to provide mutable access to the value of Parent or Children?

What solution would you like?

• Have a new function get(entity: Entity) -> Option<Entity> on the EntityMapper that simply tries to perform the mapping, but otherwise doesn't generate a new Entity
• Have a way to get an EntityMapper without needing any World access it new entity generation is not needed
• Have public mutable access to the Parent and Children's inner vluaes