Possible API Change

[kesne]

After thinking about this more, I think that potentially our query API could be simplified.

Rather than making the result of calling getQuery implement Promise<T> for the network fetch, and Readable<T> to access the data, we could make it Readable<Promise<T>>, where it will initially trigger a network fetch, and subsequently be updated with a resolved promise containing the updated store data.

We can also have the result implement Promise<T> if it is desirable to get data once, and not subscribe to store updates.

Example code

Before:

{#await query}
    <p>...waiting</p>
{:then}
    <ul>
        {#each $query.allFilms.edges as edge}
            <Movie movie={edge.node} />
        {/each}
{/await}

After:

{#await $query}
    <p>...waiting</p>
{:then data}
    <ul>
        {#each data.allFilms.edges as edge}
            <Movie movie={edge.node} />
        {/each}
{/await}

Downsides

I can think of two main downside of implementing this API:

• It deviates from the API of getFragment, where you you access data through Readable<T> .
• This API does not provide the ability to peek into the initial cached value, and you must wait for the initial fetch to resolve before accessing data. This could also be resolved by exposing a new API for this behavior.
• This will be very likely be slightly less performant.

Considerations

• We need to verify that the scheduler will not briefly flash in the pending state when we set the store to a resolved promise. If this becomes an issue, we could use a non-spec synchronous .then for store updates.