Web app features > Fetch data > Svelte

[GauBen]

Hey!

I feel like the current "Fetch data" snippet does not do Svelte justice as there is a special {#await} tag for that matter. The whole snippet can be shortened to:

<script>
  // Can still be imported from a file to keep the structure
  async function fetchData() {
    const response = await fetch("https://randomuser.me/api/?results=3");
    const { results } = await response.json();
    return results;
  }
</script>

{#await fetchData()}
  <p>Fetching users...</p>
{:then users}
  <ul>
    {#each users as user}
      <li>
        <img src={user.picture.thumbnail} alt="user" />
        <p>
          {user.name.first}
          {user.name.last}
        </p>
      </li>
    {/each}
  </ul>
{:catch}
  <p>An error occurred while fetching users</p>
{/await}

I will open a PR if this change is accepted

[benmccann]

In reality though, we wouldn't encourage that code either, but to use SvelteKit: https://kit.svelte.dev/docs/load

The "Router link" and "Routing" examples demonstrate using SvelteKit. I think this one probably should too for consistency and to follow best practices

[ysk3a]

Any plans adding sveltekit snippets instead of svelte? I was hoping to get some more examples from here for sveltekit fetching data.
While i'm still learning sveltekit, i am trying to figure out how to fetch 'personal' or 'auth'ed' data from api (i have spring boot running on mini server machine) for the client using the sveltekit app, which is in csr/spa mode (it is using electron/tauri/browser since main audience is clients that need internal business app). Most examples I've found seem to do everything ssr which is confusing to me on the proper sveltekit way of fetching data when sveltekit is not using ssr.

Or if this site might not be the place for this type of snippets, i'd love to hear from the community on how they handle these cases or resource to use.

[matschik]

If we include meta frameworks, it would be too much work to maintain it across all frameworks.
Component Party focus on the frameworks themselves, not their ecosystem.
We just included routing to show a preview of the main feature of meta frameworks and to showcase them.

The documentation of meta frameworks is the place to go.

[benmccann]

Going back to the original discussion then. @matschik said in #186 (comment):

The Fetch data example is too much different from other frameworks. It's also a great way to show how to reuse code in Svelte 5. In real world app, await syntax is rarely used to fetch data for a lot of reasons: see Svelte TanStack query for instance.

I suppose it helps for comparing frameworks if they're written in the same style, but at the same time the code as it's written now doesn't seem how you'd write it idiomatically in Svelte to me. I don't know if I've ever seen anyone use stores to track fetch state in this manner before in Svelte. I'm not super familiar with TanStack query or why they made the design choices they did. I believe that library also supports React and so my naive guess would be that it was written that way to mirror the React version rather than because it's how someone really familiar with Svelte would write it. I'd be curious to hear the reason why you say await should be avoided in the real world.

[matschik]

The main reason is to have a better experience when comparing Svelte fetch data snippet with others frameworks.
The second reason is, when you want to handle your query state only client side, I end up doing something similar to TanStack query. That's why Svelte Query was made originally instead of reinventing the wheel: https://github.com/SvelteStack/svelte-query
Then they merged this work into TanStack Query via @tanstack/svelte-query.

In short, this snippet is for client data fetching only, and the best way to handle client data fetching state I know is a pattern similar to @tanstack/svelte-query. This method is used into the other frameworks to have a much better comparison. It's not fair to have 2 files in the other frameworks and only 1 file for Svelte snippets.

And for Svelte 5, it's an opportunity to show one of the main reason Svelte 5 was made: more simple reusable code.

[sacrosanctic]

It's not fair to have 2 files in the other frameworks and only 1 file for Svelte snippets.

A quick glance at the snippets from other frameworks show that some of them only use 1 file.

[Pierstoval]

I think the argument from @GauBen still stands: if at some point we develop a "fetch" method for the frontend part, I would also recommend using the {#await ...} keyword and make it more straightforward.

If at some point this project starts showcasing different methods for meta frameworks, especially when it's about backend code, then it's an entirely new category of study. It may not fit on the project at all (because it's... well... backend and not frontend?).

But even then, for synchronization purposes, one may at some point need to fetch data from the client anyway, so a clean fetch example is really important to simplify the code, make it more self-explanatory, and use the features provided by the said framework