Repository navigation
Implement retry in case of error #667
Description
🚀 Feature Proposal
Implement a new "retry" option in @loadable/component.
Motivation
We monitor our errors with Sentry and we see quite a lot of errors coming with lazy-loaded components. Indeed, on flaky network, it's easy to have a request aborted and the component is never loaded. In our applications, we have started to wrap all dynamic imports passed to loadable with a retry function such as:
const Example = loadable(() =>
retry(
() => import('./Example'),
{ retries: 3 }
)
)where retry is a simple function:
type Options = {
retries?: number
interval?: number
exponentialBackoff?: boolean
}
// taken from https://dev.to/goenning/how-to-retry-when-react-lazy-fails-mb5
export function retry<R>(
fn: () => Promise<R>,
{ retries = 3, interval = 500, exponentialBackoff = true }: Options = {}
) {
return new Promise<R>((resolve, reject) => {
fn()
.then(resolve)
.catch((error) => {
setTimeout(() => {
if (retries === 1) {
reject(error)
return
}
// Passing on "reject" is the important part
retry(fn, {
retries: retries - 1,
interval: exponentialBackoff ? interval * 2 : interval,
}).then(resolve, reject)
}, interval)
})
})
}Example
const Example = loadable(() => import('./Example'), {retries: 3})Pitch
I'm wondering if this is something that could be directly implemented as part of loadable.
Activity
[-]Implement retry in case of chunk error[/-][+]Implement retry in case of error[/+]theKashey commentedon Dec 7, 2020
Good point. As a matter of fact - our own Sentry is filled with the same reports.
ValentinH commentedon Dec 7, 2020
If you agree, I'd be happy to work a PR.
theKashey commentedon Dec 7, 2020
That could be a little complicated as right now errors are just thrown, expected to be handled on the nearest ErrorBoundary.
The question - should network problems be still reported (so the error has to be thrown), or in case they are retry-able loadable can swallow them?
ValentinH commentedon Dec 8, 2020
I don't know if you are able to differentiate network errors from other kinds of errors when using dynamic imports. Do you know?
Regarding errors just being thrown at the moment, if the retry is optional, we could still retry all errors as it would not be a breaking change. What do you think?
theKashey commentedon Dec 9, 2020
You can, but that is abstraction leaking, so you should not try to differentiate.
This moment can alter the implementation a lot. Providing ErrorBoundary with built-in retry mechanism and built-in reporting can be a better solution, and actually can be done right now. Well, almost - such error boundary cannot distinguish LoadableError from any error coming from within loaded content. So we are circling back to the problem of "how to differentiate"
ValentinH commentedon Dec 9, 2020
I might be missing something but I think the retry function I shared in my issue is only retrying errors related to the dynamic import, not errors within the loaded component.
By the way, I deployed it on our main app in production and almost all the ChunkLoadError are gone.
theKashey commentedon Dec 9, 2020
If only error boundary could detect chunk loading error (thrown by loadable) - then it can do retry.
Wrapping
importwith any extra code is breaking SSR. There is an update to a babel plugin to make that impossible as well.ValentinH commentedon Dec 9, 2020
What do you mean by "breaking SSR"? We use this technique on an SSR application and I didn't notice any issues. 🤔
sosnomIntent commentedon Dec 10, 2020
Hello!
Facing the same issue from some time. I would like to try @ValentinH solution, will let you know when it will be tested it on production in my project
stale commentedon Feb 9, 2021
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
ValentinH commentedon Feb 9, 2021
I think this issue is still relevant. My last question was not answered actually.
19 remaining items
ValentinH commentedon Sep 28, 2021
@YPCrumble you need to use a generic signature. I have updated my original message with what you are looking for 😉
YPCrumble commentedon Sep 28, 2021
@ValentinH worked perfectly, thank you @ValentinH !!!
divyanshu013 commentedon Nov 17, 2021
This issue is still problematic, if it's not prioritized / fixable at the moment can we link this in the docs? Discoverability of this solution can help future users from wasting few hours hopefully.
stale commentedon Apr 16, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stale commentedon Jun 19, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
YPCrumble commentedon Jun 19, 2022
Not stale
mattleonowicz commentedon Jul 19, 2022
Funny how I also did the exact same thing with retry and it works.
I'm not sure if it should really be incorporated in this library though, its easier to maintain one simple library than a do-all giant.
An entry in the docs would suffice, if you ask me.
Another entry I'd expect (which is what I was looking for, and stumbled upon this issue instead) is to generally describe some good practices on what to do in case of fail, so how to "wrap" things with try catch and what are our options to safely recover from this (because even retrying network requests will return with error eventually, unless you want to repeat it indefinitely)
stale commentedon Oct 1, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
roidayan1 commentedon Jul 9, 2026
Opened #1037 which addresses this from a different angle. Rather than a built-in retry policy (
{ retries }), it adds a generalonError(error, props)hook (plus a symmetriconLoad), available per-instance and globally vialoadable.setConfig. That gives you a first-class place to implement retry / reload / error reporting in userland, without baking a specific policy into the library. Docs include a reload-once-after-deploy example.