fix example src/components/MarkdocFigure.astro in markdoc.mdx

[mrienstra]

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>

[netlify]

✅ Deploy Preview for astro-docs-2 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	13425f5
🔍 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.

[astrobot-houston]

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.

[TheOtterlord]

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>

[mrienstra]

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 ![A picture of a cat](/cat.jpg) 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.