Fix for Svelte 5 timing bug in SVAR Svelte DataGrid documentation

[joelparkerhenderson]

When I run this tutorial code: https://docs.svar.dev/svelte/grid/getting_started/

Then Svelte throws a 500 error.

As far as I can tell, there's a mount timing issue in Svelte 5 that's causing the grid to fail. What I see is if I edit the page HTML then the grid loads, then if I reload in the browser, the grid fails with a 500 error.

This fix solves it for me. Is there a better way? Thank you.

<script>
    // Import the SVAR Svelte DataGrid
    import { Grid } from "@svar-ui/svelte-grid";

    // Apply the SVAR prebuilt theme named Willow.
    import { Willow } from "@svar-ui/svelte-grid";

    const columns = [{
            id: "id",
            width: 50,
            header: "Id",
            footer: "Id",
        },
        {
            id: "name",
            width: 100,
            header: "Name",
            footer: "Name",
        },
    ];

    const data = [{
            id: 1,
            name: "Alice",
        },
        {
            id: 2,
            name: "Bob",
        },
    ];

    // Fix for Svelte 5 and SVAR Svelte DataGrid.
    let mounted = $state(false);
    import { onMount } from "svelte";
    onMount(() => { mounted = true; });
</script>

<!-- Apply the SVAR prebuilt theme named Willow. -->
<Willow>
    <!-- Wait for the data to be loaded because of timing. -->
    {#if mounted}
        <!-- Render the SVAR Svelte DataGrid. -->
        <Grid {data} {columns} />
    {/if}
</Willow>

[Natasha-eng]

Hello @joelparkerhenderson ,
SvelteKit tries to render components on the server by default, but the SVAR Grid is a client-side library that relies on the DOM and browser APIs, which aren't available during SSR. This can cause mounting errors (like the 500 error on reload) because the grid tries to initialize before the page is fully hydrated on the client.
Your fix with mounted state and onMount is a good workaround, it delays rendering until the component is mounted on the client, avoiding the SSR conflict. However, there's a more straightforward and recommended way to handle this for client-side libraries like SVAR Grid.
You can disable SSR for the specific page where you're using it. This ensures the component only renders on the client, turning it into a single-page application (SPA) behavior for that route.
export const ssr = false;
If you add export const ssr = false to your root +layout.js, your entire app will only be rendered on the client, which essentially means you turn your app into an SPA.
Please check the example:
https://stackblitz.com/edit/sveltejs-kit-template-default-mpkt1fmm?description=The%20default%20SvelteKit%20template,%20generated%20with%20create-svelte&file=src%2Froutes%2F%2Bpage.js,src%2Froutes%2F%2Bpage.svelte,src%2Froutes%2FGrid.svelte&title=SvelteKit%20Default%20Template

[joelparkerhenderson]

Thanks for the reply. What would it take to add these two solutions to the SVAR DataGrid documentation?

I believe this can help more developers try SVAR DataGrid successfully.

The SvelteKit 5 documentation emphasizes SSR by default, and I do want the speed for much of the app, so I'm keen to do SSR when possible. For my specific goal, SSR with caching is ideal because the page changes once per day for all users, so SSR caching is a large speed up.

Much appreciated.

[Natasha-eng]

We will investigate this further and possibly provide a fix or update to the documentation to address SSR-related timing issues more comprehensively.