Segmented ENTITY_TYPE_list:* cache tags

> The 3rd one is the key one -- the first two can be done with just the single entity cache tags.

Note quite, not if you consider pagers for example. If you are on page 2, changing an entity on page 1 to cause it to no longer be in the current list will change page 2 as well. Otherwise we'd indeed only need to invalidate the list cache tags on new entities.

Also, I'm not convinced that this is saving enough code to be worth it. Obviously this is a developer oriented feature, writing a postSave() method on your entity type is just a few lines of code and sometimes logic involves more than one field. In our project, we have different cache tags if entities are promoted or not, and published specifically is also about the change as well, you also want to invalidate the tag if an entity is *unpublished*, just going by field value would invalidate the wrong one.

Moving to core, but I'm not sure we can do better than the bundle tag generically for the reasons @berdir hinted at, it gets very complicated very fast.

I do wonder though if we want to consider bringing https://www.drupal.org/project/views_custom_cache_tag → into core, which in turn could be used with ECA for sites to define their own logic for invalidation. Also feel like there might be another issue covering this.

Open to bringing that into core. One idea I had recently around that is that tag based invalidation plugin could have 3 modes, the regular list cache tag, attempting to detect and showing them and finally being able to manually customize them.

🐛 Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate Needs work is the issue I couldn't place earlier, it would be close to the 'detect' mode in #6.

Yes exactly, but I can't see that we will get that ever 100% right, so I think a semi-automatic mode that you need to opt in and see what it will do would be important for that.

Yeah something like that sounds good to me.

It'd be easy enough to detect a top level filter on a node type, but much less if you then have a relationship to an entity reference field pointing to nodes with a filter on a specific field without any specific references to bundles that could make the entire logic wrong.