Get help on Discord

What does an ellipsis (...) mean in a GROQ query?

21 replies
Last updated: Feb 8, 2021
What does 
…
mean in a groq query like this… it is groq right?
export const pageQuery = `
  ...,
  content {
    ...,
    main {
      ...,
      modules[] {
        ...,
        ${moduleQuery}
      }
    }
  }
`;
being used here as well

const queryDraft = `*[_id == "${document}"]  {
    ...,
  }`;
AI Update

Yes, that's GROQ (Graph-Relational Object Queries), Sanity's query language! The ... is called the ellipsis operator (or spread operator), and it's used in projections to include all fields from a document.

What it does

The ... expands to include all fields from the current document or object you're querying. Think of it like JavaScript's spread operator, but for GROQ queries.

In your examples:

*[_id == "${document}"] {
  ...,
}

This returns all fields from the matching document. The ... says "give me everything that's in this document."

export const pageQuery = `
  ...,
  content {
    ...,
    main {
      ...,
      modules[] {
        ...,
        ${moduleQuery}
      }
    }
  }
`;

Here you're using ... at multiple levels to include all fields at each level, plus you're explicitly expanding nested objects like content, main, and modules[].

Why use it?

The ellipsis operator is super useful when you want:

  • All existing fields plus some custom ones
  • To avoid listing every single field manually
  • To override specific fields while keeping everything else

Important quirk: Order matters!

The ... is always evaluated first, regardless of where you put it. This means if you write:

{
  title: "Override",
  ...
}

The ... is evaluated first, then your title override applies. But to avoid confusion and unintended overrides, it's best practice to put ... at the beginning:

{
  ...,
  title: "Override"
}

This makes it clear you're starting with all fields, then modifying specific ones. Check out the official GROQ pipeline components documentation for more details on how projections work!

Show original thread
21 replies
I might be wrong, but I think it means that you'll get all of the content available for that query, but you can specify parts of it (in your case, you call it a model query)
user J
Okay, i was thinking that. Couldn’t find it in explicitly stated in the docs. thanks
Thanks Karin! Admittedly, it's a bit hidden in the docs :
A bare 
...
 is syntactic sugar for 
...@
, i.e. it inserts all attributes from the currently iterated element into the projection. For example, 
{..., "key": "value}
 generates an object with all of the object's original attributes in addition to the generated 
key
 attribute.
If multiple keys with the same name are given, then the latest key wins. The only exception is with the bare 
...
 syntactic sugar mentioned above, which is always evaluated first regardless of its position in the projection. For example, the projection 
{"name": "someName", ...}
 will replace the original 
name
 attribute of the object, if any.
Thanks Karin! Admittedly, it's a bit hidden in the docs :
A bare 
...
 is syntactic sugar for 
...@
, i.e. it inserts all attributes from the currently iterated element into the projection. For example, 
{..., "key": "value}
 generates an object with all of the object's original attributes in addition to the generated 
key
 attribute.
If multiple keys with the same name are given, then the latest key wins. The only exception is with the bare 
...
 syntactic sugar mentioned above, which is always evaluated first regardless of its position in the projection. For example, the projection 
{"name": "someName", ...}
 will replace the original 
name
 attribute of the object, if any.
user M
I’m trying to figure out why my queries are returning this object
when I’m trying to get this
Anything that references a document like page, product, collection, etc. It just returns a reference instead of the actual data. I’m tyring something like this, but it doesn’t return what I thought it would :
export const moduleQuery = `
  _type == 'productSlider' => {
    ...,
    products[] {
      ...,
      sanityProduct->
    }
  },
  _type == 'nestedPages' => {
    ...,
    page[] {
      ...,
      linkedPage->
    }
  }
`;

export const pageQuery = `
  ...,
  content {
    ...,
    main {
      ...,
      modules[] {
        ...,
        ${moduleQuery}
      }
    }
  }
`;
  const queryDraft = `*[_id == "${document}"]  {
    ...,
  }`;

  const queryPreviewPage = `*[_id == "${document}"]  {
    ${pageQuery}
  }`;
A few things to check:• Have you verified the module 
_type
names are correct and at the correct level of nesting?• Are 
sanityProduct
and 
linkedPage
actual field names inside those modules?• Does it work if you fully write out one of those queries?
using 
modules[] {}
is going to apply to everything within the modules array, right?
Correct 🙂
the objects im trying to get data from looks like this in the array
children: []
content: {images: {…}, main: {…}, shopify: {…}}
id: "93f8bcec-cd61-5e70-a515-1b6566d1ab31"
internal: {type: "SanityProduct", contentDigest: "148f4f057c418c84a59164fe2784bdb8", counter: 507, owner: "gatsby-source-sanity"}
parent: null
_createdAt: "2021-01-13T08:12:57Z"
_id: "1716036108354"
_rev: "7x5hkJBuoJKga49kaU2D2o"
_type: "product"
_updatedAt: "2021-02-03T06:11:56Z"
I’m trying this query, you were right about double checking names, but still nothing

 _type == 'productSlider' => {
    ...,
    products[] {
      ...,
      product->
    }
  },

does that query make sense?
But i’m just getting a ref string back because the expanding reference isn’t working
aiight
do previews
aiight
on about
You could try 
products[]->
instead of 
products[]
,or 
_type == "product" => @->
inside of 
products[]
.
okay products[] -> did work! Could I do a more general one and do modules[] -> and just get all teh data from every module?
It works, thank you!

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?