Document "dynamic" component pattern including type safety

[lloydjatkinson]

Background

A popular pattern is to render different components based on some value. This value could be from an API call, CMS data, or user selection. Common use cases include page builders where users pick content blocks (image, blockquote, heading), or CMS sections where editors choose layout types, or pages in a multi-step wizard.

Literature and examples

1. How to render dynamic component defined in JSON using React
2. Render React components dynamically based on a JSON payload
3. How to use dynamic components in Astro
4. Alternative way to dynamically render React components coming from an API

Previous discussions

1. https://discord.com/channels/830184174198718474/1221252100911140864 (a thread)
2. https://discord.com/channels/830184174198718474/830184175176122389/1221262480366632970 (a reply to the thread but in another channel)

Implementation

Using the article demonstrating the pattern with Astro as a reference, some initial attempts are shown that contain several downsides (long repetitive switch for example) before finally arriving at exactly the same type of pattern shown in the Discord threads and all the links to articles.

I consider this to be important enough to be documented and feature in the Astro docs, @sarah11918 suggested the https://docs.astro.build/en/reference/astro-syntax page.

Important

This pattern works with JS or TS, but is definitely enhanced when using TS. Perhaps, if deemed necessary, two docs additions could be made 1) a new entry on https://docs.astro.build/en/reference/astro-syntax with a link to 2) an a new entry on https://docs.astro.build/en/guides/typescript/ to discuss type safety.

When it is used with TypeScript I think that any code shown in the docs should be type safe. I think the article demonstrating the pattern with Astro as a reference sort of covers this with it's example of {...rest} and keyof typeof but this should be checked by someone.

[OliverSpeir]

Worth making note that if any of the components in the component map have imported styles ( either imported in component script or <style> tags ) those styles will be included regardless of whether those components actually get used

direct rendering scripts (astro v5) fixed scripts, but styles remain an issue there's a few roadmap discussions about it but here's one withastro/roadmap#664

[sarah11918]

Thanks for making this, Lloyd!

I think the Lucky Media article's examples feel about the right length for what we currently have on that page, e.g. 3 different UI blocks that you might want to render.

Would someone like to propose a code sample similar to that one? About the same length, and with a common use case?

We are always saying that we'd love to have tabs to show JS/TS in docs 😅 . So a good first start could be to provide both a JS and TS example of the pattern.

As for the text of what goes with this, we'd could probably get away with a minimal description to start:

Dynamic Components

• Astro needs to know which component you want to render ahead of time, so you have to render <AnActualComponent /> , and not <{randomComponent} />
• You can, however, create a dynamic component (are we "naming" this? kind of component?) that itself renders a <Template /> component, which through props can be specified as one of a given list of possible components
• (Oliver's) caveat: This pattern requires importing into your dynamic component all possible components that might be rendered. This also imports every component's styles, not just the component that is eventually rendered. (Some kind of advice here? Anything they can do to mitigate? or just be aware?)

Does this feel about right? Does someone feel confident they could draft something to get this party started?

(Note: This is maybe feeling like something that might eventually end up on the Components guide page? But let's stick to creating an example first, wherever it goes, and see what happens!)