How to use Astro or NextJS <Image> with fields.document and fields.image

[tordans]

We are struggling to setup a Keystatic Astro projects that automatically optimizes user uploaded images.

The scenario: A user uploads a 5 MB screenshot in a fields.document or a "hero image" (fields.image).
We want this image to be optimized by the Astro <Image> component during the static side generation step of the build.

BUT, it looks like that is not possible? Astro <Image> only allows external URLs or module imported images. We can work around this, like Simons video does, by using the public folder. BUT, that breaks cache busting and the images do not get optimized anymore (which is likely why it is not recommended by the Astro docs).

We managed to get a Test going with NextJS <Image> and the "hero image" use case (fields.image). However, we did not get the fields.document + <Image> working in NextJS. And also, we where looking forward to using Astro to create a nice, static site (which does not seem to be a target use case for the app directory).

Is there a way to get this working?
What are practical workarounds? (The public folder not a solution…)

[simonswiss]

Hey!

I did some exploration on Astro Assets + Keystatic images (both fields.image and inside a component block) on a live stream yesterday.

The stream is very long and I get stuck on a lot of various (and unrelated) things — but essentially I got it working with a mix of:

• defining the directory property of the fields.image to the assets folder, , and the publichPath to the relative path to the assets folder (../../assets/...).
• defining the directory of component blocks to the assets folder as well, but the publicPath to /src/assets/... (because it needs to match Astro's dynamic imports with imports.meta.glob).

For component blocks I used the technique described here to import all images and access the correct keys with the bracket syntax, as explained here:

https://docs.astro.build/en/recipes/dynamically-importing-images/#_top

Because the imports from imports.meta.glob will have paths starting with /src/assets, the publicPath must match for those to correctly map to the import object.

https://www.youtube.com/watch?v=2SjCSvl8p8g

You can fast forward to the end of the stream if you want to see the working solution :)

I cannot share the code for it because it's based on a design that is sold on ThemeForest — but I might make a minimal reproduction or write an organised guide.

[JohannaPeanut]

Hey!

Thank you! We made everything work the way you described! Also the componentBlocks finally work with images!!

That <Image> takes a specific object as src prop, but we got a string from keystatic and that Astro complaint that „Image's and src parameter must be an imported image or an URL“ (what we new that we could not provide) was the basic problem.
So to turn our image into this kind of metadata, we have to define a zod type in content/config.ts. Eventhough we read this line in the Astro docs we did not try this for a while as we thought this file is for validating and not for transforming any data..

It would definitely be helpful to find that somewhere more present in the keystatic docs - it's an Astro thing but crucial for keystatic to work with Astro (and image optimization).

I hope the flies have left you alone by now :) Thanks again!

[noahflk]

Thank you @simonswiss

Maybe this is something worth including in the official Keystatic documentation?

[jjaimealeman]

It would definitely be helpful to find that somewhere more present in the keystatic docs - it's an Astro thing but crucial for keystatic to work with Astro (and image optimization).

Agree with this.

[simonswiss]

I just wrote a new recipe for this on the documentation site :)

https://keystatic.com/docs/recipes/astro-images

[simonswiss]

Using Astro assets and the component with Keystatic is sorta tricky, so I wrote a new recipe on just that for the docs website 👼

https://keystatic.com/docs/recipes/astro-images

It covers uses cases for both "standalone" images (stored in frontmatter), and images inside a content component. Because both approaches are quite different 😅