Feature request: Provide tag to query that causes it to be invalidated by any ID

[elramus]

Unless I'm missing something, there's a scenario that's not really possible to cover well using the current tag system. I want to provide a tag to a query endpoint that declares it can be invalidated by a tag type of any ID.

Let's say users can have lists of widgets saved to their account. Then we have a widget searching page where user can do a widget search and get back results of which lists have that widget on it.

How would I tag this? We'd probably start with a LIST tag for the user's overall list of widget lists.

{ type: 'WidgetList', id: 'LIST' }

But we also know that users can change around the widgets on their existing lists, so we'd want to also get the specific tags of the lists we get back, something like this:

[
  { type: 'WidgetList', id: 'LIST' },
  ...response.map(widgetList => ({
    type: 'WidgetList',
    id: widgetList.id,
  }),
]

So far all well and good, except for one scenario: let's say user has lists A, B, and C. They search for some widget and get back lists A and C in the results. So we store the tags for A and C. Then user goes and adds the widget to list B. Because that wasn't in our response, we don't have any way to know to nuke this search result query.

Is this what the "general" tag is for, like just { type: 'WidgetList' }? The problem there is that my addWidgetToList mutation would need to explicitly invalidate { type: 'WidgetList' }. That would be too broad because it would also clear { type: 'WidgetList', id: 'foo' }, { type: 'WidgetList', id: 'bar' }, etc.

In summary, we currently have the ability to nuke all tags of a type regardless of ID in a mutation via the general tag, but sometimes I need the opposite: the ability to be nuked by all tags of a type regardless of ID in a query. According to the tag invalidation behavior table, this isn't currently possible.

In other words, I feel like it should be this:

Possible workaround would be to pass all of user's widget list IDs into the initial search request, or provide them in the API call response, so that we can exhaustively tag the query with all list IDs. That feels yucky though.

Any guidance on this scenario?

Thanks for all the great work over the years on this package!