How to limit boilerplate when trying to maintain consistency in the world ?

[LegoBrickOnFire]

Preface: I am a bevy beginer, so I might be doing some crazy things.

I am trying to make a game with a grid of tiles. These tiles can be identified with a 2d coodinate.
When a tile is added to the world, there are two things that should be done and I am currently using the same solution for both.

1. book-keeping, I want an index from coordinate to entity
2. spawning an adequate sprite at the correct location

Small description of my data model. I have the following components that can be added to a Tile entity:

• Tile: with some description of what that tile is
• TileCoord: defines where it is
• Sprite: the sprite for representing that tile
• Transform: To place the tile

Right now I am keeping track of new additions with a system in the Update schedule. So the contract of the system function is (here for the sprite-adding-system):

fn insert_new_tile_sprite(
    mut new_tiles_query: Query<
        (Entity, &TileCoord),
        (
            Or<(Added<TileCoord>, Added<Tile>)>,
            With<Tile>,
            Without<Sprite>,
            Without<Transform>,
        ),
    >,
    mut commands: Commands,
) {...}

This works, but I feel like this pattern can get dirty quickly, this is why I am asking for your feedback.
Specifically, it is really heavy to have to use many Or<Added<...>,...> and With<...> to be really sure that the state will be correct no matter in which order the components were added. If I need to do that for large bundles, that code is going to be huge.

Additionnal remarks/questions:

1. I could merge the TileCoord and Tile together. Yes, but is it not a general principle with ECS to feel very free to split the data into the smallest components? If I should still merge them, are there general guidelines for when data should NOT be split up?
2. I know that I didn't code any system that add the components in weird orders, so I don't have to be so careful. True, But it's supposed to be the magic of ECS to be able to freely add systems coded independently. This feels like technical debt that is not good in bigger projects.
3. Maybe I should not use a regular system for this. What is better suited then?

[RobWalt]

You can use type aliases:

type AddedTile = Or<(Added<TileCoord>, Added<Tile>)>;

this also promotes reuse. Another example then:

type AddedTileWithoutSprite = (
            AddedTile,
            With<Tile>,
            Without<Sprite>,
            Without<Transform>,
        );

[gwafotapa]

I don't know enough about your game but this combination of filters feels weird to me. Do you sometimes spawn tiles without Tile but with TileCoord or vice versa ? Why the Without filters ? Like you said I imagine you're being unnecessarily careful.

Your system adds components to newly spawned entities. There are one issue with doing it this way. There will be a latence between when a tile is spawned and when it gets all its components that you will have to handle with some ordering. I would say a hook or a one-shot system is better suited for this.

As for grouping TileCoord and Tile together that depends. First of all, it means you're envisioning never using TileCoord for entities other than tiles (You won't have game pieces on your tiles for instance). Then I would say it's a matter of taste. I decide depending on the use I have for them. If they're mostly used independently, I keep them separate. That communicates intent clearer when you query for TileCoord rather than Tile intending to access its coords field. On the other hand, if I find myself always querying for both, it's a good sign they belong together. In your particular case, I would keep them separate. As you said Tile is descriptive, basically a marker component. You can use it in query filters while using TileCoord in query data.

[LegoBrickOnFire]

Thank you for the answer. As I better understand bevy and ECS in general I will become less overly careful. I will look into hooks and one-shots for this.