Get help on Discord

GROQ: Accessing file URLs within block content arrays

12 replies
Last updated: May 3, 2023
So I came across this groq query
// GROQ query
*[_type == 'movie'] {
  title,
  "manuscriptURL": manuscript.asset->url
}

// Then you can use the URL in HTML for example like this:
// <a href={`${manuscriptURL}?dl=`}>Manuscript</a>
for downloading files. However, what if the 
file
is added to your block content? Is it as simple as doing
  "body": body[]{
    ...,
    _type == 'file' => {
      ...,
      "documentUrl": asset->url
    }
  }

AI Update

Yes, your approach is almost correct! When you have a file asset embedded in block content (Portable Text), you need to resolve the asset reference to get its URL. Your query structure is on the right track:

"body": body[]{
  ...,
  _type == 'file' => {
    ...,
    "documentUrl": asset->url
  }
}

However, there are a couple of important considerations based on the discussion from the Sanity community:

Performance optimization: If you need multiple fields from the asset (like size, original filename, etc.), avoid using multiple -> references for the same document. Instead, merge them into a single subquery:

"body": body[]{
  ...,
  _type == 'file' => {
    ...,
    ...(asset-> {
      "documentUrl": url,
      "documentSize": size,
      "documentOriginalFilename": originalFilename
    })
  }
}

Alternative approach using @sanity/asset-utils: Instead of resolving asset->url in your GROQ query, you can use the @sanity/asset-utils library to generate file URLs client-side. This approach is more efficient since you only need the asset reference ID:

"body": body[]{
  ...,
  _type == 'file' => {
    ...,
    // Just include the asset reference, resolve URL client-side
  }
}

Then in your code:

import { buildFileUrl } from '@sanity/asset-utils'

const fileUrl = buildFileUrl(fileBlock.asset, { 
  projectId: 'your-project-id', 
  dataset: 'your-dataset' 
})

Both approaches work, but using @sanity/asset-utils can be more performant since it avoids the extra dereferencing in GROQ. However, if you also need metadata like file size and original filename, you'll still need to resolve those from the asset in your query.

Show original thread
12 replies
Neither 😉
You can generate full URLs to any asset — images and files — using just the asset’s ID, dataset and projectId with this library:

https://www.npmjs.com/package/@sanity/asset-utils
So right now I am doing
    attachments[]{
      ...,
      "documentUrl": asset->url,
      "documentSize": asset->size,
      "documentOriginalFilename": asset->originalFilename,
    }
Is there something for the size and original file name? I am also running into an issue doing 
buildFileUrl(attachment._key, { dataset, projectId })
as I am getting 
Error: Cannot use 'in' operator to search for 'originalFilename' in cc0020b7ff8d
 but it is midnight here so I am probably missing something
Ah. The original file name and size you would need to resolve. And yes additionally resolve inside your block content.
On another note, try to avoid multiple `-&gt;`’s for the same document. That snippet is resolving the same query three times. Take a look at this section on
High performance GROQ
Ahh I should do
// Merge a single subquery into the root level of the result
*[_type == "category"] {
  title,
  "slug": slug.current,
  ...(parent-> {
    "parentTitle": title,
    "parentSlug": slug.current
  }) 
}

Actually it should be this right?
// Return all fields and resolve all fields in all 'categories' references
*[_type == "product" && defined(salePrice) && salePrice < displayPrice]{
  ...,
  categories[]->
}
As I want to return all fields and resolve all fields in my attachments references. So I tried

  "services": *[_type == "service" && references(^._id)]{
    ...,
    attachments[]->
  },
but that returns 
attachments
as 
null
🤔
attachments[]->
should resolve all fields from an array of references. If it’s returning null perhaps you’re targeting the wrong field or it is empty.
🤦‍♂️ it isn't a reference 😆
 attachments: [
    {
      asset: [Object],
      _type: 'file',
      name: 'Senior Connections Resource Guide',
      _key: 'cc0020b7ff8d'
    }
  ],
So I got the 
buildFileUrl
working but just passing in the attachment. However, I want to get the file size if possible as well
You’ll need to resolve that from the asset reference.
Does this query look fine? It gives me what I want but was curious if there is any performance improvements I can make
I’d personally try to cut down on the number of 
…
spread operators that will end up sending you more data than you likely need. But it looks otherwise fine for now!
Ok one more groq question... Seeing as I can figure this issue out... How would I go about using 
buildFileUrl
for a reference in block? So in my query I am currently doing
"body": body[]{
  ...,
  _type == 'file' => {
    ...,
    "documentUrl": asset->url
  }
}
and then passing the URL for the portable text. And this time it does look like it's a reference

{
  asset: {
    _ref: 'file-f4005335534eb49e6edffea0b1596cd211b670e8-pdf',
    _type: 'reference'
  },
  _type: 'file',
  description: 'Maricopa Community Center Senior Programming Calendar for May 2023',
  _key: '96b1944a9636',
  documentUrl: 'MY DOCUMENT URL'
}
However, I would like to cut that 
"documentUrl":  asset->url
out and just use 
buildFileUrl
if possible but it's coming back as 
undefined.undefined
if my query just returns 
body
instead of doing 
...

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?