Async data

[Rich-Harris]

Been refactoring https://svelte.technology — inching towards a more declarative/universal way of handling routing etc.

One thing that stands out is that there's really no good way for components to declare their own data dependencies in a universal way. So you have to have a dedicated handler per route, in case you need to do something like fetch a blog post's JSON.

It would be nice if that stuff could sit in the component itself. You'd still have to handle data fetching differently between server and client, but at least you'd be able to declare all your routes declaratively (up to a point, anyway).

Maybe something like this:

<script>
  export default {
    preload (params) {
      if (isServer) { // TODO figure out what this actually looks like...
        return require(`../public/blog-posts/${params.slug}.json`);
      } else {
        return fetch(`/blog-posts/${params.slug}.json`).then(r => r.json());
      }
    },

    data (preloaded) {
      return {
        post: preloaded
      };
    }
  };
</script>

This only really works for top-level components — it could get pretty crazy if you had something like this:

{{#if foo}}
  <ComponentThatPreloadsStuff/>
{{/if}}

Thoughts?

[PaulBGD]

How I handle it in a large project is I generate the state that the route uses on the server (from redis, MySQL, other APIs, etc) then pass it as JSON through a script element. That ensures that both SSR and the client are receiving the same state.

[Rich-Harris]

That makes sense for the initial load — how do you handle client-side route changes?

Not sure I got the API quite right above, I don't think there's a great way to instantiate the component if it's set up like that, we probably don't want new Component to behave any differently. Something like this could work:

BlogPost.preload({ slug: 'components-with-async-data' }).then(post => {
  new BlogPost({
    target,
    data: { post }
  });
});

// generalised
Promise.resolve(Component.preload ? Component.preload(params) : {}).then(data => {
  new Component({ target, data });
});

This only really works for top-level components — it could get pretty crazy if you had something like this:

We might actually need to solve this problem, now that I think about it. For example, the component that defines the /blog/:slug route on https://svelte.technology contains a <Page> with a nested <BlogPost> component. It would be nice if <Page> was responsible for getting the value of hashed (the hashed filenames of bundle.js and main.css) and <BlogPost> was responsible for turning the slug into a post — the component that contains both shouldn't have to worry about either.

Any good examples of how other frameworks have solved this?

[PaulBGD]

Honestly, is there anything preventing us from using redux + redux thunk? Seems to handle that case quite nicely. In theory if #469 ever gets implemented we could have svelte-redux or something to have first class support for redux as a library.

[Rich-Harris]

What would that look like in practice (i.e. from the point of view of writing the code that lives inside your route handlers on both server and client)? I'd be wary of hitching our wagon to a specific state management tool, that's a holy war I don't really want to pick a side in!

Besides, it seems that the hardest problem here isn't implementation so much as design.

[PaulBGD]

What this issue seems to be is a way for a component to load data before it's mounted. A clean way to solve that is #469 but the current way to solve it is to use any state management library + just a if check if the data is loaded.

[Rich-Harris]

#469 is purely about element-level lifecycle hooks, do you mean a different issue?

By 'if check' do you mean in the template, as in {{#if foo}}...{{/if}}? That can work in the client (though it's not ideal in all circumstances — you might want to preload data for the new view before destroying the old one) but less so on the server. I might have misunderstood you?

[PaulBGD]

I might be confused what this is suggesting. Isn't it passing data to a component to load before the component is mounted?

[Rich-Harris]

At a high level it's just saying that there needs to be an idiomatic way within the component definition to express asynchronous data dependencies, that applies in both server- and client-side contexts

[briancray]

Is this just as simple as checking if data returns a promise? If so wait for it to resolve before mounting? Perhaps combine that with a mountRequiresData boolean so the user can return a promise for async data but still have it mount if desired?

[TehShrike]

In my mind this is very strongly something that should be implemented with dynamic components (#640).

As long as the dynamic component API is expressive enough, people can pick from a few general-case async-loading components, or make one that fits their specific case.

[Rich-Harris]

@TehShrike was that a response to this comment on Gitter? I think it's a different problem to that of async data. I should make a separate issue for <:Async>, Gitter not the right place for it

[TehShrike]

Oh, sure, that's another case that I think should be handled entirely by dynamic components instead of adding new syntax.

But no, I really do think that async loading of data is also definitely something that should be achievable/achieved with dynamic components.

[aubergene]

Just an idea, can data (and computed) accept a promise and then add a way of switching based on the state of the promise to the templating?

{{#pending foo}}
Loading foo...
{{#then foo}}
Foo has a value of {{foo}}
{{#catch foo}}
No foo this time
{{/foo}}

<script>
  export default {
    data () {
      return {
        foo: () => fetch(url).then(d => d.json())
      };
    }
  };
</script>

and then call it like

<ComponentThatLoadsStuff url="//foo.com?post=123"/>

[Rich-Harris]

@aubergene Dude! I think you're onto something here.

Elsewhere in Svelte (and Handlebars generally), # and / (opening and closing blocks) are symmetrical (see #if...elseif...else.../if), so it would probably be more like this...

{{#pending foo}}
  Loading foo...
{{then value}}
  Foo has a value of {{value}}
{{catch err}}
  No foo this time (because {{err.message}})
{{/pending}}

...but I think the idea of solving this problem with syntax is brilliant. Maybe pending is the wrong name, since that's just one possible state. Maybe await?

Could also have a shorthand like this, if you didn't care about pending/error states:

{{#await foo then value}}
  Foo has a value of {{value}}
{{/await}}

One thing to think about: often, you might want to preserve the previous value until the new one has resolved, for example a list of autocomplete suggestions (you don't want them to disappear each time you type a character):

<input list='suggestions' bind:search>

{{#await suggestions}}
  <span>loading...</span>
{{then value}}
  <datalist id='suggestions'>
    {{#each value as suggestion}}
      <option>{{suggestion}}</option>
    {{/each}}
  </datalist>
{{catch err}}
  <span class='error'>could not get suggestions!</span>
{{/await}}

<script>
  export default {
    computed: {
      suggestions: search => fetch(`/suggestions.json?q=${search}`).then(r => r.json())
    }
  };
</script>

How might we express that idea — that we want the 'loading...' text initially, but thereafter we should preserve the resolved value until another one resolves?