The code generator is not compatible with svelte-apollo 0.4.0

[bradphelan]

The signature of query from svelte-apollo has changed between the versions so the code generator doesn't work with 0.4.0

0.3.0

declare function query<TData = any, TCache = any, TVariables = any>(client: ApolloClient<TCache>, options: WatchQueryOptions<TVariables>): QueryStore<TData>;

0.4.0

export function query<TData = unknown, TVariables = unknown>(
	query: DocumentNode,
	options: Omit<WatchQueryOptions<TVariables, TData>, "query"> = {}
): ReadableQuery<TData>

[ticruz38]

Yes, also svelte-apollo 0.4.0 does not let you pass in the client to the query. This is annoying for sapper project :/
Not sure how to tackle this, I will somehow adapt the generator to version 0.4.0 and add a peer dependency for the version that uses 0.3.0

[ticruz38]

All things considered, I'm going to wait before I move to svelte-apollo@0.4.0, all it does is force you to use the context to forward the apollo-client, it doesn't provide performance enhancement or anything.
The generator makes it transparent on how we handle the client (either context or singleton)
Using the context does break Sapper compatibility, I'll update when a workaround is found, I'll take care that my update does not change how you handle the request in your components.

[bradphelan]

Isn't there also a change in what query returns from 0.0.3 to 0.0.4 from a promise of a store to just a store. I have to check again but I know I got confused by something like that as well.

[bradphelan]

I think you also need a way to pass in the query options. With these you can control error handling behavior.

[bradphelan]

( by the way I didn't say thanks for writing the library. It's nice to have something specifically for svelte so thankyou )

[ticruz38]

Exactly, your points are valid!
I could make smth where you pass options along with the variables in the same object.
We could get rid of the promise by adding a few lines in the generator.
We could also depend on apollo directly, this would make update more seamless between apollo and svelte, as the mechanism around wrapping apollo for svelte is quite simple and could be handled entirely by the generator.
One would only have to care about writing its queries in a .gql file and use them in its .svelte files from the generated code as described in the example folder.

[bradphelan]

I suspect if you can bypass "svelte-apollo" and depend on apollo directly then less problems will arise in the future as the dependency chain is shorter.

[ticruz38]

The package does not depends on svelte-apollo anymore, it returns observable instead of promises, and let you pass all the options possible together with the variables.

[bradphelan]

I think the documentation on your landing page is wrong.

<ul>
{#each t?.data?.transactions || [] as transaction}
    <li>Sent transaction from {transaction.from} to {transaction.to}</li>
{/each}
</ul>

should be

<ul>
{#each $t?.data?.transactions || [] as transaction}
    <li>Sent transaction from {transaction.from} to {transaction.to}</li>
{/each}
</ul>

ie: missing $ is front of the t on the each line

[bradphelan]

Thanks for updating the library so quick. I'll try in the next couple of days to take it for a spin.