@pawan Sorry about the delay…I might be able to best illustrate with query examples (which may or may not be accurate in their own right, so correct me if need be).
Query 1
getUser {
posts @cascade {
content
reactions(filter: {
type: {in: ["thumbs_up", "clap"]}
}){
type
user {name}
}
}
}
I think this query gets me only posts that have either thumbs up OR clap reactions. I believe it also sorts out reactions that don’t match the filter.
Query 2
getUser {
posts @cascade {
content
reactions(filter: {type: {eq: "thumbs_up"}}, or: {type: {eq: "clap"}}) {
type
user {name}
}
}
}
I think this query gets me the same thing as the first.
Query 3
getUser {
posts @cascade {
content
reactions(filter: {type: {eq: "thumbs_up"}}, and: {type: {eq: "clap"}}) {
type
user {name}
}
}
}
This wouldn’t return anything since the rules are mutually exclusive (as are the values).
So what I want is (I think) is a new input type on connected sets for contains/includes functionality, so I can build a query similar to Query 1 in that it filters for posts with thumbs_up AND/OR clap reactions, but additionally returns all reactions.
The idea is that we often want to have cascading filters on computed properties of a connected set (contains, length, and every are the generic List methods that come to mind), the same way we do for values of singular fields. In my use case, I might have many posts with claps and many posts with thumbs_ups, but only a few with both that I want to retrieve for a client. The functionally equivalent block would be something like:
if (arr.contains((reaction) => reaction.type == "clap") && arr.contains((reaction) => reaction.type == "thumbs_up")) {
return arr;
}
It might look something like this:
getUser {
posts @cascade {
content
reactions(contains: {type: {eq: "thumbs_up"}},
and/or: {contains: {type: {eq: "clap"}}}
) {
type
user {name}
}
}
}
I am all for making my work arounds not needed, but it is just how we learned to cope with some of the limitations in the meantime.