I tried to do something similar by creating sections strategies : #24607
I wonder if we should build a "target selector" for front-end card so it can be reused in different place (to achieve something similar to entities-card)

I think it would be somewhat tricky to come up with a one-size-fits-all selector that could work for any type of card, given that the things we select need to be munged in a list with other items that vary based on the type of card (entities card has entities and labels intermixed with other special row types), and each selected item may or may not need its own submenu to configure properties that may differ from card to card.

As (and if) we keep expanding labels to more use cases, I would just focus on making sure there are at least good helper functions that minimize the overhead, but I don't think of a good UI design that can handle all that special behavior.

Even for now this is just a yaml-only thing, but might revisit UI improvements if this is favorable.

I do think this could/should use the same syntax as the filter in #24607.

That way we dont have to re-invent the wheel.

Also, if we are going forward with this, we also need to update the size logic of the entities card, as now every item in entities renders 1 row, and with this PR and item in entities could render multiple rows.

I wonder if we should instead add strategy support to the entities card, maybe that is overcomplicating things, but...

I do think this could/should use the same syntax as the filter in #24607.

Not sure how that maps to entities-card syntax exactly. Something more like this?

entities:
  - sun.sun
  - type: filter
    filter:
      label: weather
  - type: filter
    filter:
      label: air_quality

yes, exactly that

Funny thing is, we had something like this at the beginning of Lovelace, and we then decided to remove it 🙃

Also, if we are going forward with this, we also need to update the size logic of the entities card, as now every item in entities renders 1 row, and with this PR an item in entities could render multiple rows.

I thought perhaps we would just ignore it. I thought size was only determined directly from the config, without hass. Similar to how history card doesn't know the right size either, since it doesn't know how it will load. I didn't think we would defer it until we load all the registry and do all the calculations.

Maybe we should, as it is only for the masonry view...

Renamed and replaced type: label with type: filter, to better match the other syntax. label is the only supported key under filter for now, you can let me know if that's sufficient.