You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In scenarios where there is no network or the server responds with 503 we might suspend all further calls to the server/network until connection has been restored or "retry-after" (if sent) has been passed. Otherwise the user might get flooded with error messages (she can't do anything about).
Multiple related errors should be consolidated into one and present to the user during that time.
Are there any strategies out there how to handle such scenarios with useSWR.
Lets say there is a dashboard with some components and each has their own useSWR. Now the first updates and gets a 503 server response. At that moment it does not make sense for the other 3 components to even try to connect the server, as the response contained a "Retry-After" which has not yet been passed. So I guess all this logic would have to be put into the fetcher used to connect to the server. As soon as the server responds with 503 a promise is created waitForRetry and then all fetchers will attach themselves as resolve continuation of that promise. return waitForRetry.then(fetch(key, ...))
In case the retry results in another 503 the cycle is started again, without ever returning to components fetch.
Same would go for "disconnect" promise, that would register a listener for connectivity and then resolve once connection has been re-established.
While any of those promises exist, the UI could display a banner (with maybe a manual retry override, which would trigger the resolve of the said promises prematurely).
I know vercel has the `retry´ npm package which would come in handy here.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
In scenarios where there is no network or the server responds with 503 we might suspend all further calls to the server/network until connection has been restored or "retry-after" (if sent) has been passed. Otherwise the user might get flooded with error messages (she can't do anything about).
Multiple related errors should be consolidated into one and present to the user during that time.
Are there any strategies out there how to handle such scenarios with useSWR.
Lets say there is a dashboard with some components and each has their own useSWR. Now the first updates and gets a 503 server response. At that moment it does not make sense for the other 3 components to even try to connect the server, as the response contained a "Retry-After" which has not yet been passed. So I guess all this logic would have to be put into the fetcher used to connect to the server. As soon as the server responds with 503 a promise is created
waitForRetry
and then all fetchers will attach themselves as resolve continuation of that promise.return waitForRetry.then(fetch(key, ...))
In case the retry results in another 503 the cycle is started again, without ever returning to components fetch.
Same would go for "disconnect" promise, that would register a listener for connectivity and then resolve once connection has been re-established.
While any of those promises exist, the UI could display a banner (with maybe a manual retry override, which would trigger the resolve of the said promises prematurely).
I know vercel has the `retry´ npm package which would come in handy here.
Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions