#Does <ClientRouter /> works with static site or is it SSR only?

12 messages · Page 1 of 1 (latest)

viral goblet
#

On dev it's working nicely but when I deploy on Netlify it doesn't work.

frank dustBOT
#

Hi @viral goblet. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

The provided knowledge sources only cover how to deploy Astro to Netlify (static vs SSR vs edge) and how to configure the @astrojs/netlify adapter; they do not mention <ClientRouter /> at all, nor how it behaves on static builds vs SSR builds. [Deploy Netlify]

Because of that, I can’t reliably say—based on these sources alone—whether <ClientRouter /> is expected to work on fully static sites or is SSR-only, nor why it would behave differently between astro dev and a static deployment on Netlify.

What the sources do confirm is:

  • Astro is static by default; no extra config is needed for a static Netlify deploy.
  • To enable SSR/edge behavior on Netlify, you must use the Netlify adapter and set output: 'server' in astro.config.mjs. [Deploy Netlify]
// astro.config.mjs
import { defineConfig } from 'astro/config';
import netlify from '@astrojs/netlify';

export default defineConfig({
  output: 'server',
  adapter: netlify(),
});

If <ClientRouter /> requires SSR, then switching from a static build to output: 'server' with the Netlify adapter would be the necessary step—but this requirement is not stated in the docs we have, so this is only a hypothesis, not something I can confirm from the knowledge sources.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@viral goblet Kapa.ai is still learning and improving, please let me know how I did by reacting below.

viral goblet
#

@frank dust I want the website stay static. Is there's solution to add transitions to Astro static other than view transitions API which still not supported by many browser.

frank dustBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

The knowledge sources only describe Astro’s built‑in View Transitions support via <ClientRouter />, which is explicitly based on the browser View Transitions API. They do not mention any alternative, built‑in transition system for fully static sites that does not rely on that API. [View transitions]

From the docs we have:

  • Astro’s transitions are powered by the new View Transitions browser API. [View transitions]
  • You opt in by adding <ClientRouter /> to the page <head>. [View transitions]
  • Astro lets you control fallback strategies for browsers that don’t support the API, but the details of those fallbacks are not included in the provided excerpts. [View transitions]

The sources do not describe:

  • Any separate, non–View‑Transitions‑API animation system for static sites.
  • Any official Astro feature that would give SPA‑style animated transitions on static output without relying on that API.

So, based on the available docs, there is no documented Astro‑provided alternative for static sites beyond the View Transitions–based system and its (unspecified here) fallbacks.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@viral goblet Kapa.ai is still learning and improving, please let me know how I did by reacting below.

viral goblet
#

@frank dust how to update content collection to content layer api

frank dustBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

To update an existing content collection to the Content Layer API, follow these steps:

  1. Move the collection folder out of src/content/

    For example, move:

    • From: src/content/blog/
    • To: src/data/blog/

    All collections that stay inside src/content/ will continue using the old Content Collections API. Do not move src/content/config.ts; it still defines all collections. [Config ref]

  2. Update the collection definition to use a loader

    In src/content/config.ts, replace the old definition with one that uses a loader (e.g. glob) and remove the type option:

    // src/content/config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  // For content layer you no longer define a `type`
  // type: 'content',
  loader: glob({
    pattern: '**/[^_]*.md',
    base: './src/data/blog',
  }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
  }),
});

export const collections = { blog };

    [Config ref]

  3. Change slug references to id

    Content Layer entries don’t have slug; they use id instead. For example, in a dynamic route:

    ---

// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';

#

export async function getStaticPaths() {
const posts = await getCollection('blog');
return posts.map((post) => ({
// Before:
// params: { slug: post.slug },
// After:
params: { slug: post.id },
props: post,
}));
}

[[Config ref](<https://web.archive.org/web/20241128001717/https://docs.astro.build/en/reference/configuration-reference/#migrating-an-existing-content-collection-to-use-the-content-layer-api>)]

4. **Switch from `entry.render()` to the new `render()` function**

Entries are now plain serializable objects and no longer have a `.render()` method. Import `render` from `astro:content` and pass the entry:

```astro
---
// src/pages/blog/[slug].astro
import { getEntry, render } from 'astro:content';

const post = await getEntry('blog', Astro.params.slug);

// Before:
// const { Content, headings } = await post.render();

// After:
const { Content, headings } = await render(post);
---
<Content />

[Config ref]

These four steps are the complete migration path described in the docs for moving an existing collection to the Content Layer API.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: