Skip to content

Commit a5e85d0

Browse files
committed
add chapter for renderers
1 parent 155bfce commit a5e85d0

File tree

1 file changed

+35
-1
lines changed

1 file changed

+35
-1
lines changed

proposals/0048-container-api.md

Lines changed: 35 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -82,6 +82,7 @@ but eventually each route must be rendered using the same data, which are:
8282
- `AstroContainer::create`: creates a new instance of the container.
8383
- `AstroContainer.renderToString`: renders a component and return a string.
8484
- `AstroContainer.renderToResponse`: renders a component and returns the `Response` emitted by the rendering phase.
85+
- `AstroContainer.addServerRenderer`: to programmatically store a renderer inside the container.
8586

8687
### `create` function
8788

@@ -126,14 +127,47 @@ It will be possible to tweak the container APIs with options and such. The `.cre
126127
```ts
127128
type AstroContainerOptions = {
128129
streaming: boolean;
129-
renderers: AstroRenderer[];
130+
renderers: AddServerRenderer[];
130131
astroConfig: AstroUserConfig;
131132
}
132133
```
133134
134135
The `astroConfig` object is literally the same object exposed by the `defineConfig`, inside the `astro.config.mjs` file. This very configuration
135136
will go under the same schema validation that Astro uses internally. This means that an invalid schema will result in an error of the `create` function.
136137
138+
#### Add a renderer
139+
140+
Adding a renderer can be done manually or automatically.
141+
142+
The automatic way is meant for static applications, or cases where the container isn't called at runtime. The renderers maintained by the Astro org will expose
143+
a method called `getContainerRenderer` that will return the correct information that will tell the container **how to import the renderer**. The importing of the renderer is done via a function called `loadRenderers`, exported by a new virtual module called `astro:container`:
144+
145+
```js
146+
import { getContainerRenderer as reactRenderer } from "@astrojs/react";
147+
import { getContainerRenderer as vueRenderer } from "@astrojs/vue";
148+
import { laodRenderers } from "astro:container";
149+
import { AstroContainer } from "astro/container";
150+
151+
const renderers = loadRenderers([
152+
reactRenderer(),
153+
vueRenderer()
154+
]);
155+
const container = await AstroContainer.create({ renderers })
156+
```
157+
158+
The manual way is meant for on-demand applications, or cases where the container is called at runtime or inside other "shells" (PHP, Ruby, Java, etc.).
159+
The developer is in charge of **importing** the server renderer and store it inside the container via `AstroContainer.addServerRenderer`:
160+
161+
The renderers maintained by the Astro org will ship proper types for importing server renderers.
162+
163+
```js
164+
import reactRenderer from "@astrojs/react/server.js";
165+
import vueRenderer from "@astrojs/vue/server.js";
166+
167+
const container = await AstroContainer.create();
168+
container.addServerRenderer({renderer: reactRenderer});
169+
container.addServerRenderer({renderer: vueRenderer});
170+
```
137171

138172
### `renderToString` and `renderToResponse` options
139173

0 commit comments

Comments
 (0)