You could do a single query with one to four subqueries, too (either treating them collectively like an array or busting them out for granular changes).
I would query the categories themselves that match the category document type, and then do a projection inside them called something like "posts" that is another query referencing the "parent" category.
Part of the reason is, you may run into situations where you want them to do mostly the same thing but treat them differently (e.g. you need ten total but want to make sure no more than 4 come from Category B)
Alternately, you could also query all posts matching those categories but I'd be worried it's literally grabbing all of them first under the hood before filtering. I try to think general to specific.
If I couldn't make the query itself work, I'd leave it to my language of choice fetching the data to map them out and sort them.
It's not a focus of my talk Wednesday but in the project I'll be discussing I needed to do that at one point; I had a date field for magazine publication dates and developed an array of years from every doc, boiling it down to uniques. Then, whenever the year in the doc matched the array key, in it went, like mugs in a cupboard.
Side note that the
groq channel is well-suited to ask too, just because they're so fluent and clever. I personally have to pseudocode the queries first to understand what I am trying to do haha
😃