How can you avoid repeated references? (supporting the ... spread operator)

[maxijonson]

Hello! I'm new to GROQD, and we're evaluating the possibility of integrating it instead of our manual query builder (which isn't on the same type-safe level as GROQD).

While reading through Sanity's "High Performance GROQ", I stumbled upon this recommendation, which recommends you spread (...) projections that use the same reference.

Instead of this:

// Slow, repeated subquery
*[_type == "category"] {
  title,
  "slug": slug.current,
  "parentTitle": parent->title, 
  "parentSlug": parent->slug.current
}

Do this:

// Merge a single subquery into the root level of the result
*[_type == "category"] {
  title,
  "slug": slug.current,
  ...(parent-> {
    "parentTitle": title,
    "parentSlug": slug.current
  }) 
}

Right now, whenever I need to grab a specific property in a complex matter, I can just start a new q and get it done. Here's how I would build the first unoptimized example with groqd:

q("*")
  .filterByType("category")
  .grab$({
    name: q.string(),
    slug: q.slug("slug"),
    parentTitle: q("parent").deref().grabOne("title", q.string()),
    parentSlug: q("parent").deref().grabOne("slug.current", q.string()),
  })

In the 2nd example, there is more than 1 property that should share some kind of logic to prevent 2 references to "parent". I was wondering if this technique is something that can be implemented with the current version of GROQD?

[scottrippey]

Great question! Unfortunately, this is not currently supported by GroqD.
we've considered ways to add this support, and we're open to suggestions.

Below, I'll post some of our proposed suggestions. Let us know what you think , and please propose your own ideas if anything comes to mind!

[maxijonson]

I haven't really thought about a suggestions before since I have literally less than 24h of experience with groqd so far haha but I like the idea of the utility you posted.

[scottrippey]

Suggestion: Spread Key

.grab({
  '...': q("parent").deref().grab({
    parentTitle: ['title', q.string()], 
    parentSlug: ["slug.current", q.string()],
  })
});

However this doesn't allow for "multiple" spreads. We might have to expand this to support an array, which gets inconvenient:

.grab({
  '...': [
    q("parent").deref().grab({ etc }),
    q("user").deref().grab({ etc }),
  ]
})

This can also be challenging when we support "fragments", because this key could get overridden instead of merged.

[maxijonson]

Yeah I thought about the spread key, but then realized it wouldn't support multiple spreads like you said. Didn't think of the array though, that would work if it came to this suggestion!

[scottrippey]

Suggestion: spreadable utility

.grab({
  ...q.spreadable(
    q("parent").deref().grab({
      parentTItle: ['title', q.string()],
    })
  ),
  ...q.spreadable(
    q("user").deref().grab({
      userName: ['name', q.string()],
    })
  ),
})

Pros:

• Understandable
• Javascript's ... spread operator is being used, so it's very similar to the Groq syntax
• Works well with "fragments" and composition of queries

Cons:

• Extremely tricky to infer correct result types
  • But we have implemented something similar with q.conditional, so it can be done

[maxijonson]

I think I like this one better simply because it's behind a utility and not something we need to be aware of for this particular use-case (in the case of the spread key).

However, would spreading the result of q.spreadable mean that the underlying result could be also written by hand as well? Since this use-case isn't supported by groqd right now, I'm guessing it would require more changes to groqd's parsing flow, rather than just adding a utility.

[maxijonson]

Suggestion: adding a parameter to grab

Right now, the second parameter of grab are for conditional selections. grab could support a 3rd parameter for "re-used" references. Not exactly sure how it would work behind the scenes, but the way I would intuitively use it is like this:

q("*")
.filterByType("category")
.grab({
    title: q.string(),
    slug: q.slug("slug")
}, 
{}, 
[
    [
        q("parent").deref(),
        {
            parentTitle: (parent) => parent.grabOne("title", q.string()),
            parentSlug: (parent) => parent.grabOne("slug.current", q.string())
        }
    ]
]);

Here, "simple" properties like title and slug are grabbed normally and we leave {} because we're not using conditionals. The third parameter is an array of arrays where each element (arrays) specify the base query at the first index and the second index is the properties to grab, which receives the first index's query as parameter to complete it's grab.

I think this would eliminate the need to add more logic to the existing way groqd parses the 1st argument (for '...' spread key and q.spreadable utility).

An example with more than just 1 of these would look like this:

q("*")
.filterByType("category")
.grab({
    title: q.string(),
    slug: q.slug("slug")
}, 
{}, 
[
    [
        q("parent").deref(),
        {
            parentTitle: (parent) => parent.grabOne("title", q.string()),
            parentSlug: (parent) => parent.grabOne("slug.current", q.string())
        }
    ],
    [
        q("subcategories").filter().deref(),
        {
            title: (subcategory) => subcategory.grabOne("title", q.string()),
            slug: (subcategory) => subcategory.grabOne("slug.current", q.string())
        }
    ]
]);