Container APIs

[ematipico]

Summary

An API for rendering components in isolation:

// Card.test.js
import Card from "../src/components/Card.astro"
import astroConfig from "../src/astro.config.mjs";

const container = await AstroContainer.create()
const response = await container.renderToString(Card);
// assertions

Links

• Rendered RFC
• Stage 2 Proposal
• Stage 1 Proposal

[bluwy]

As a data point, currently Astro's programmatic APIs are experimental too but doesn't have the experimental_ prefix, so I'm biased that we don't need to prefix these and only add an @experimental jsdoc tag. Curious to hear what others think about this.

[matthewp]

Discussed this sync and we decided to keep the prefix.

[matthewp]

Have you found use-case for passing the astroConfig yet? I'm worried about getting bug reports when people try to pass through vite config and other non-supported stuff.

What do you think about instead raising the relevant config values up to the AstroContainerOptions level. That would be stuff like trailingSlash.

[ematipico]

What do you think about instead raising the relevant config values up to the AstroContainerOptions level. That would be stuff like trailingSlash.

I don't think that would work easily. These options, internally, are used to create a manifest. If we pass these options when rendering a component, it would mean generating a new manifest every time we attempt to render a component, and then discard that manifest. We have to be careful not to override the existing manifest, because the manifest is tight to the lifetime of the instance of the container.

[matthewp]

Not when rendering, AstroContainerOptions is the name of the options passed to AstroContainer.create().

[ematipico]

Oh, I misunderstood what you meant. Yeah we should be able to provide the individual options.