No promises with Svelte's queryStore or mutationStore?

[arthur5005]

I've been playing around with urql's bindings for svelte, and while I appreciate the use of stores for derived state, I'm surprised there's no way to use them and get a promise for a given query/mutation.

All I'm looking to do is call an event on my component when the query/mutation completes (in my case, emit an event to close a modal after you've saved the details).

I can subscribe to the store on state changes, but it feels like a leaky abstraction, having to subscribe store construction, unsubscribe on component destruction, etc.

Am I missing something or is this an area for improvement?

Thanks!

[kitten]

There's some issues and discussions around this asking the same question

Essentially, what you want to do is use the client directly if you need an imperative call, e.g. await client.mutation(...) or client.mutation(...).toPromise()

Keep in mind please that if you do client.query(...).toPromise() that's a sign of a problem most of the times. Transactual/Imperative queries should be very rarely needed and won't reactively update. It's either a sign that a mutation should be used or that you might be overcomplicating some things.

In your case though, it sounds like you're just issuing a mutation imperatively.

[arthur5005]

Hey @kitten,

Appreciate the feedback - always a gift. I did eventually resort to using the imperative style as in my case I was using a mutation and needed to know when the mutation had completed. This was so I could close the modal for the user upon completion of the mutation.

Ultimately, the mutationStore's derived state variables are still helpful for reactive display of state, such as fetching, errors etc. but not having the promise available for the explicit signalling of completion has me tracking all these variables myself, and repeating underlying aspects of the readable store (which yes, describes the problem of using imperative vs declarative)

While I appreciate the adherence to an api that guides users to the correct form, I'm left wondering if a small expansion of the API is worth exploring given it's not possible to use the store and know the boundary of the query/mutation.

And thanks again for getting back to me, I really do appreciate your feedback on this.