Do you think the Svelte API / pattern of use could be improved?

[ispyinternet]

I would argue that the use of context to save the Client reference is brittle and potentially confusing due to svelte requiring that you call this code at a very specific place/time in the component code.

// component
<script>
import { queryString } from 'query.graphql.js'

const todosQuery = query({ query: queryString })

$: todos = todosQuery({ pause: true });
const execute = () => todosQuery().then();
</script>

I was trying to visualise a setup, where perhaps you construct your own client, and then use it to prepare all your queries / mutations etc. So the client exports 3 methods, query, mutate, and subscribe, that you could use similar to the gql tagging function on your .graphql schemas:

// includes/urql.config.js 
import { SvelteClient } from '@urql/svelte;
const client =  new SvelteClient( { constructor_args })

export default client; 
export { client.query as q, client.mutate as m, client.subscribe as s }

// graphql/queries.js
import { q } from 'urql.config.js'
export const todos = q`
  query {
        todos {
          id
          text
          complete
        }
      }`;

// component
<script>
import { todos } from 'query.js'

const execute = () => todos.update({ new_args});
</script>

{#if $todos.fetching}
  Loading...
{:else if $todos.error}
  Oh no! {$todos.error.message}
{:else if !$todos.data}
  No data
{:else}
  <ul>
    {#each $todos.data.todos as todo}
      <li>{todo.text}</li>
    {/each}
  </ul>
{/if}

<button on:click={execute}>Execute</button>

[ispyinternet]

I might add that this has been thought out in the context of a larger sapper app

[kitten]

We opt not to wrap urql's Client ever because that introduces confusion around what the client is and what its methods currently are. That being said our Svelte bindings are purely experimental and stand-ins as there are (imho) deep problems with Svelte's reactive model, to the point where most code just opts to use await, which isn't optimal.

What you're describing however is already possible. You can actually use query directly without instantiating it first into a separate variable for instance. The reason why this is done currently is precisely because of Svelte's shortcoming in how subscribables are handled

The problem is that whenever it changes it loses all its state and currently we've "hacked" around with a small trick. If you instantiate the query first and then use it separately with another call, we're able to actually preserve the state as we want to.

This may change though as we think about what the final API should look like. It's pretty likely we'll actually just drop this and "blame" Svelte's (probably intentional) limitations on why our bindings won't be as fully-featured as the ones for React/Preact 😅

[kitten]

@ispyinternet No, this isn't about memoization and a history per se, instead it's about having a coherent change from one state to the next. This stream here shows the state changes very clearly, scan being like a reducer over time: https://github.com/FormidableLabs/urql/blob/8c74924c1d49588f265cbc3776e98fbff4995199/packages/react-urql/src/hooks/useQuery.ts#L69-L96

@frederikhors I wouldn't say that at all. In my opinion, Svelte's reactivity and state models are deeply insufficient and flawed compared to component-wide state via hooks. Neither is satisfactory and in fact in both models there are state changes and events that we cannot observe; with React we cannot observe the exact time a render cycle is interrupted and in Svelte we cannot react to and observe changes over time at all cleanly. The latter is in my opinion a lot more severe

[ispyinternet]

Thanks @kitten. Another question, not sure how you handle this, if it’s just left to user land, but if your binding query params to template vars, depending on how those input changes are emitted (eg keyups on an input - I assume the user should implement the pause here), but do you do any debouncing / atomising of the template variable changes to prevent firing off a splatter of similar requests? Hope that question’s not too dumb in the context of this library!?🤷

Yes that code snippet you sent, just getting my head round it, learning wonka!

[ispyinternet]

Hi @kitten ok so... I hope what I have done will amount to something! I've had to learn typescript along the way - which I'm totally sold on, I would NOT have been able to do this without the IDE type errors!

So the theory - svelte stores maintain the references in the same way your react hooks do and any changes to the underlying stores will propagate to the final query through the use of derived stores.

We have:

Request

• provides GraphQLRequest
• changed by: query, variables
• Code: https://gist.github.com/ispyinternet/12e2311a74f57d7f83e7b17ee0c28ea4
• Notes: I've asked a question in the source code here - do I need to check the request key as you do in react?

Context

• provides OperationContext
• changed by: pollInterval, requestPolicy (more dependencies can be added)
• Code: https://gist.github.com/ispyinternet/ad28499a98350227f819196271f64773

Source

• provides Source<OperationResult<T>>
• changed by: request, context
• Code: https://gist.github.com/ispyinternet/8bd7b1eb307f0a6ead3fe8ca656c8c62

Query

• provides: Source<OperationResult<T>
• changed by: source
• Code: https://gist.github.com/ispyinternet/05372d2963b301108c43a9447c578e43
• Notes: Orchestrates changes to the stores, sets intial state and manages pausing, allows us to attach reactivity in svelte template using for example: $: $todos.bind( { variables: { nextToken, maxItems }})

The reason I asked the question about debouncing / atomising of underlying changes, is because, in these examples, where changes to things like query, variables and context are made synchronously, they will trigger multiple updates on the derived store - I can't reason what happens in this scenario, wonka will just quickly recreate the request and unsubscribe to the previous / kill any network request - do I need to add some logic here to prevent multiple network requests being created (debounce) - do you see / understand what I am trying to convey?

It would be great if you could look over them, I'm not 100% sure about the last one query.ts - have I constructed the wonka stream correctly? I'm getting a type error I can't fix:

Cheers!

[ispyinternet]

Just realise that reexecuteQuery will not necessarily re-execute the query (only if something in context changes)!

I will look into this - any thoughts? I could trick the context store into changing with a pseudo variable (incrementer or something)

[kitten]

The comment below could be of interest; since we have a new stable API we'll ship for Svelte.

do I need to add some logic here to prevent multiple network requests being created (debounce) - do you see / understand what I am trying to convey?

No, the cancellation is pretty transparent and cheap. We'd choose not to interfere with debouncing or other time-related logic and would instead opt for predictability. It's typically not a problem if a query rapidly changes. If it is identical to the last one then the dedupExchange will also just let the first one through and any further cancellation isn't necessary. If the previous operation is cancelled this just flows through to the fetchExchange.

[kitten]

So to bring this thread to a more satisfying conclusion; I've fast-tracked the development of a new Svelte bindings API in #1016.

This API should protect the users more rigorously from misusing the reactivity model that we had before, and should appear much more intuitive. It also irons out several bugs that we found while experimenting with different APIs.

This is still not 100% perfect, but it's the closest we can get to an idiomatic Svelte API that also feels right for urql and GraphQL.

[ispyinternet]

I think one thing that I've noticed is that this wouldn't really subscribe and this is also what I'm mostly unsure about

yh probaly the bit I was unsure about.

the query store if you prefix with $ in the template should return the value of subscribe.

see this proof of concept, cascading changes to derived store, plus noop (i.e. retain references/state) if updating to same value:

https://svelte.dev/repl/a67c9d37aee348d988e8c30f60a139d9?version=3.28.0

[kitten]

Yea, I mean, the reactivity is fine, but what I don't see is bind being the right approach here? So basically why I went with the operationStore in the upcoming implementation is because that means that we don't have to pass mutable variables, but we pass a container that also owns the changes, which means there's only one source of changes to worry about

[ispyinternet]

That I will have to go away and think about! Cheers!

[ispyinternet]

This is still not 100% perfect, but it's the closest we can get to an idiomatic Svelte API that also feels right for urql and GraphQL.

@kitten why?

[ispyinternet]

Yea, I mean, the reactivity is fine, but what I don't see is bind being the right approach here? So basically why I went with the operationStore in the upcoming implementation is because that means that we don't have to pass mutable variables, but we pass a container that also owns the changes, which means there's only one source of changes to worry about

Yh, tbf, I think bind was the wrong choice of word, nothing was binding, it was just updating the values in the underlying stores.

Essentially similar solutions, in your solution, I',m pretty sure you can write:

$: $todos.variables.skip = skip; // whenever skip changes either from external or within, the query gets triggered.

For posterity I got mine working with: https://gist.github.com/ispyinternet/05372d2963b301108c43a9447c578e43 !

I will argue my api is a little more succinct as you don't need to expose the operationStore to the end user, query sets all the stores up for you.

<script>
import {  query } from '@urql/svelte';
import { todos as query } from './graphyql/todos';

let pause = true;
const todos = query({ query, pause })

$: todos.execute({ pause }); 
</script>

<button on:click="{() => pause = false}">Run Query</button>

{#if $todos.fetching} etc...

Anyway I only got query working, and I don't have the inclination to work out mutations or subscriptions!

Thanks for the time and great work!