Cannot use document fields in subscripts locally, but works in groq.dev

[RamZallan]

Describe the bug

Per this slack thread, I noted that I was unable to use fields from a document to fill in subscript values.

To Reproduce

Strangely, this works in groq.dev, but doesn't locally. Geoff mentioned in the Slack thread above that he was similarly unable to get it working. In groq.dev, you can use this data and query to see what I'm looking for, and what doesn't work locally:

[
  {
    "_type": "postGallery",
    "postCount": 2
  },
  {
    "_type": "post",
    "title": "Lorem ipsum"
  },
  {
    "_type": "post",
    "title": "Dolor sit amet"
  },
  {
    "_type": "post",
    "title": "Foo bar baz"
  },
  {
    "_type": "post",
    "title": "Shouldn't be shown"
  }
]

*[_type == "postGallery"] {
  "posts": *[_type == "post"][0...postCount]
}

Expected behavior

groq.dev correctly returns two of the posts:

[
  {
    "posts": [
      {
        "_type": "post",
        "title": "Lorem ipsum"
      },
      {
        "_type": "post",
        "title": "Dolor sit amet"
      }
    ]
  }
]

though this isn't the same locally. Trying a similar query (slightly modified to work with my actual dataset) in Vision, it shows me Query error: subscript ranges must have integer endpoints. Subbing in things like [0...^.postCount], [0...@.postCount] also don't work.

Screenshot

Which versions of Sanity are you using?

$ sanity versions
@sanity/cli             2.7.4 (up to date)
@sanity/base            2.7.4 (up to date)
@sanity/components      2.2.6 (up to date)
@sanity/core            2.7.4 (up to date)
@sanity/default-layout  2.7.4 (up to date)
@sanity/default-login   2.7.0 (up to date)
@sanity/desk-tool       2.7.4 (up to date)
@sanity/vision          2.7.4 (up to date)

What operating system are you using?

MacOS Big Sur

Which versions of Node.js / npm are you running?

$ npm -v && node -v
7.7.5
v12.20.2

[atombender]

This is a deliberate choice to make GROQ simple, as documented here:

Due to parser ambiguity with filters, the following access operators can only take literals, not arbitrary expressions: array element access (e.g. array[0]), array slices (e.g. array[1..3]), and object attribute access (e.g. object["attribute"]).

I agree that it's not obvious, and it's potentially something we can revisit in the future.

The reason that the JavaScript implementation accepts any expression is that it predates this choice.

The official GROQ spec is also not updated yet. It's currently in draft revision, but will reach official status as soon as we've got everything properly aligned. For now, the Sanity.io documentation is the most up to date. Sorry about the confusion!

[atombender]

I'm closing this issue for now.