Wouldn't it be nice if everything went smoothly?
Sure it would, but networks are unreliable and sources aren't always present.
As a result, a lot of the code we write is dealing with things when they go wrong.
This module is designed to help you with that.
Let's say you're trying to do the following: You want to access an online resource and, if that's not available or corrupted, you'll try a different one and, if that's not available or corrupted, you'll try a local file and, if that's not available or corrupted, you'll just resort to something default.
Something like this might ensue:
getRemoteResource('foo')
.catch(() => getRemoteResource('foo2'))
.catch(() => getLocalResource('foo3'))
.catch(() => getDefault())
.then(handleResource);
That's not the worse code in the world, but it's not very dynamic.
It could be built with:
[
() => getRemoteResource('foo'),
() => getRemoteResource('foo2'),
() => getLocalResource('foo3'),
() => getDefault()
].reduce((chain, resourceGetter) => {
if(chain) {
return chain.catch(resourceGetter);
}
return resourceGetter();
}).then(handleResource);
This solves the non-dynamic problem, but we've now got a hulking great reducer in your code whose purpose is not exactly obvious.
In addition, this all assumes that your sources return promises. Some of them may be accessed synchronously. It may not really be warranted to convert them into promises.
Enter fallback-plan
npm i @dancrumb/fallback-plan
or
yarn add @dancrumb/fallback-plan
For more examples, please visit our Github Page
Here are some answers to questions you may have.
Since all of the fallback plan options ultimately return a Promise, you can nest them:
fallback([
cycle([
'foo',
'foo2'
], getRemoteResource),
() => getLocalResource('foo3'),
getDefault
]).then(useResource);
These types of methods are pretty cool, but they execute all of the Promises in order to determine which finishes first.
If you have a fallback plan with numerous possible options and some of these are costly, the last thing
you want to do is to fire them off unnecessarily. fallback-plan
only calls a function
that returns a Promise if it needs to.
Same reason as given in the examples above. If you did:
fallback([
getRemoteResource('foo'),
getRemoteResource('foo2'),
getLocalResource('foo3'),
getDefault
]).then(useResource);
then you would have requested 'foo'
, 'foo2'
and 'foo3'
... even if 'foo'
comes back
without a problem!
This module is provided under the MIT License.
Generated using TypeDoc