3 ms·
I suspect that using Promise.all() helps greatly with this.
by mark242 10y ago
I suspect that using Promise.all() helps greatly with this.
- mbrock 10y agoThe way I've done it is to just have an array of commands and a simple queue thing that keeps retrying its head element until success, triggered by connectivity change or manual user retry. (This was also useful when our backend had random issues causing 500s sometimes.) A command has both an AJAX request and a state updating function. It's really easy with a React-like framework because you can just apply the command queue's state changes as part of the main view render, without actually modifying the main state.
- mark242 10y agoYeah, look into using Promise.all. You're probably looking at a good few hundred lines of code reduction. What you're describing as a "command" (request / state update) is just a promise with a map function applied. Your "simple queue thing" can just be an array that you fire Promise.all at.
- mbrock 10y agoCan you serialize a promise to localStorage? How do you deal with network failure in the middle of the promise array?
- mark242 10y agoIf a promise in the array is rejected, Promise.all (which returns a promise) rejects with (supposedly) the first rejected promise, but that's extremely hard to predict if you have two promises which could reject. Serializing a promise to localStorage; I get what you're trying to do, you want to have a worker pick up exactly where it left off when you left the app. This is where a service worker would help you. I suppose you could write some kind of durable mailbox a la Akka, only running in the browser.
- mbrock 10y agoYeah, these kinds of issues were why I decided to manually manage an array of serializable commands instead of using Promise.all. Also showing the state of the queue (Sims-style, or just a number of pending changes) is easier when you control the queue yourself.