Querying nested attributes in Sanity.io model and upgrading to the latest API version.

Hi! I have the following model:• A

company

with an array of

team

objects (no references, only nested objects) called

companyTeams[]

• Each

company

and

team

has their own unique

slug

I'm trying to write a query where I filter by both

company.slug.current

and

team.slug.current

, but I'm not able to get the

$teamSlug in companyTeams[].slug[].current[]

filter to work. I've tried all combinations (

slug[].current

,

slug.current[]

,

slug[].current[]

), and if I create a new string attribute for the

team

objects called

slugString

, I get the following filter to work as intended:

$teamSlug in companyTeams[].slugString[]

Is it not possible to filter by a sub-sub-attribute, i.e.

slug.current

, with the

in

operator?
See the attached screenshot for my current workaround using `slugString`:

slug

is an object like

{"current": "foo"}

? If so, you should be able to use:

We realize that the semantics of the

[]

operator can be confusing! Think of

[]

as being “map over”. So

a[].b

is equivalent to JavaScript

a.map(val => val.b)

.

The

[]

operator becomes a flattening operator if added to the end of an array, which means that something like

parents[].children

returns an array of arrays (i.e. each parent’s children as a nested array), but

parents[].children[]

returns a flat array of all the children.

Thanks for the clarification! However,

$teamSlug in companyTeams[].slug.current

still returns

{}

I'm using the v1 API version btw

You should be using

v2021-03-25

. The array handling is very buggy in v1.

The new version also has much better performance.

Ahh, I wasn't aware of that. Will try the new version now. Any breaking changes from v1 to

v2021-03-25

?

Yes, some: https://www.sanity.io/changelog?platforms=GROQ

Scroll down to “Breaking changes from v1 to v2021-03-25”

The breaking changes are mostly fixes 🙂

Perfect, thanks for the help!

Everything worked as expected now – and super-easy upgrade –

null

vs.

{}

return value was the only breaking change for us

Great!