Is there any way to not run in parallel mutations queued during offline?

[darkartur]

I am writing todo-list-like app that supposed to work offline. I have mutation where I toggle todo-item (boolean flag).

While offline I can toggle it several times, and then when app go online result is unpredictable because all mutations run in parallel.

Is there any way to control that behaviour: run sequentially or ideally have ability to discard mutations based on queue state?

[kitten]

We currently don't have a way to do this. The reason is a bit more "obscure" so to speak, but generally, we anticipated that in several cases there'd be mutations that would have to be run in series, regardless of the offline queuing or anything else.
However, that means there should be an exchange that queues "conflicting" mutations. But we have never really gotten around to implementing one 😅

[alan-bradbury]

Doesn't this make offline mode unusable for most real world scenarios?

[Psvensso]

@kitten Any more thoughts on this one?
When replaying the queue to the server it's very important that the order is preserved in many cases.
Is it a valid approach to to just have one open http call at a time and take the latency cost?

[Psvensso]

I ended up writing a custom "QueuedFetch" that runs fetch in sequence.

One bad thing is that i need to read the body to detect if it contains any "mutations" and if it does i use the queued version so that normal queries can go in paralell, gets an overall perf hit for that so i think next step could be some throttle detection or something else to figure out that its trying to replay a big queue or else just let them pass.

This could probably have been done in a much cleaning way in a exchange but this was very unintrusive and simple for us to implement. This at least works for some of the simpler use-cases for us.

type ReqFunc = () => Promise<void>;

export class QueuedFetch {
 private queue: ReqFunc[] = [];
 async processQueue() {
   if (this.queue.length > 0) {
     const fetchFunction = this.queue[0];
     await fetchFunction();
     this.queue.shift();
     this.processQueue();
   }
 }
 addToQueue(func: ReqFunc) {
   this.queue.push(func);
   if (this.queue.length === 1) {
     this.processQueue();
   }
 }
 async doFetch(
   url: RequestInfo | URL,
   options?: RequestInit,
 ): Promise<Response> {
   return new Promise((resolve, reject) => {
     const fetchFunction = async () => {
       try {
         const r = await fetch(url, options);
         resolve(r);
       } catch (e) {
         reject(e);
       }
     };

     this.addToQueue(fetchFunction);
   });
 }
}

/// In the provider
const fetchQueue = new QueuedFetch();
const client = createClient({
       fetch: (url, options) => {
         if (
           options.method === "POST" &&
           typeof options.body === "string" &&
           options.body.indexOf("mutation") > -1
         ) {
           return fetchQueue.doFetch(url, options);
         }
         return fetch(url, options);
       }
       //.... other options removed for clarity
     });

[kitten]

I forgot to copy this here, since this is the higher thread SEO/search-wise, but I'd highly recommend not to implement control flow logic via fetch polyfills.
It obviously won't apply across different transports and will prevent you from also integrating logic into different parts of your control flow i.e. other exchanges, as it makes things less composable and predictable.

Writing a custom queue as an exchange sounds scary, but ultimately doesn't involve a lot of code.
There's a sample here: #2347 (comment)