docs
docs copied to clipboard
fix example `src/components/MarkdocFigure.astro` in markdoc.mdx
Had src: ImageMetadata | string; but no string handling
Alternate solution would be to remove | string from type, I instead opted to use the pattern shown in the example directly above.
Without these changes, pnpm astro check results in:
error ts(2322): Type '{ src: string | ImageMetadata; alt: string; width: number; height: number; }' is not assignable to type 'IntrinsicAttributes & Props'.
PS: was tempted to make this a slightly more "kitchen sink" example, by throwing in an example of <slot/> (also functionally a nice thing to have, if someone reading the docs actually has a use for this particular component):
---
import { Image } from "astro:assets";
interface Props {
src: ImageMetadata | string;
alt: string;
width: number;
height: number;
}
const { src, alt, width, height } = Astro.props;
const hasCaptionSlot = Astro.slots.has("default");
---
<figure>
{
typeof src === "string" ? (
<img {src} {alt} {width} {height} />
) : (
<Image {src} {alt} {width} {height} />
)
}
{
hasCaptionSlot && (
<figcaption>
<slot />
</figcaption>
)
}
</figure>
Deploy Preview for astro-docs-2 ready!
Built without sensitive environment variables
| Name | Link |
|---|---|
| Latest commit | 13425f55c2c2d7c0685b5887cef130445815decb |
| Latest deploy log | https://app.netlify.com/projects/astro-docs-2/deploys/682b99c919f3ea0008083bed |
| Deploy Preview | https://deploy-preview-11716--astro-docs-2.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify project configuration.
Lunaria Status Overview
π This pull request will trigger status changes.
Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.
Tracked Files
| File | Note |
|---|---|
| en/guides/integrations-guide/markdoc.mdx | Source changed, localizations will be marked as outdated. |
Warnings reference
| Icon | Description |
|---|---|
| ποΈ | The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied. |
Thanks @mrienstra.
I went about reproducing this, since I remembered remote images only using a string for src. And yes, it's unfortunately just a weird type conflict, because strictly defining src (as a string or ImageMetadata) works fine.
This should probably be reported as a bug, since the best case is fixing this conflict. Making a note of what we might want to do if this isn't considered a bug though:
We can define Props as an intersection between Image props and custom props like caption.
---
import { Image, type LocalImageProps, type RemoteImageProps } from "astro:assets";
type Props = (LocalImageProps | RemoteImageProps) & {
caption: string;
}
const { caption, ...imageProps } = Astro.props;
---
<figure>
<Image {...imageProps} />
{caption && <figcaption>{caption}</figcaption>}
</figure>
Nice work-around, @TheOtterlord!
Do you want to open an issue (on main astro repo) for this or shall I?
Perhaps we should close this PR and open a docs issue to discuss the right solution. As I noted above, the example above this -- see https://docs.astro.build/en/guides/integrations-guide/markdoc/#custom-image-components -- uses a similar pattern. This prior example also kind of implies you need to make a custom image component if you want  in .mdoc files to use the <Image /> component (or "Astroβs Image Service API" as it us explained elsewhere) to optimize your local images -- I'm pretty sure this works "out of the box" in .mdoc files, like it does in .md files ( https://docs.astro.build/en/guides/images/#images-in-markdown-files ), but I'll have to double-check this... That would be a weird omission.
Perhaps we should close this PR and open a docs issue to discuss the right solution.
Because this took a turn from the original intention, and because of how long this has been open without activity, I'm going to accept this decision to close it, and welcome a docs discussion! (If no one filed an issue with the main astro repo, then I also welcome you to do that!)