WIP/Draft: Support Retry Error Callback + Retry Count

[TatisLois]

Expose a way for the useFetchye hook to specify a max retry count and callback to be invoked on retries.

Description

I wanted to open a DRAFT/WIP with a proof of concept to start a conversation on the best way to and if useFetchye should support on error scenarios. The current implementation does not support this functionality. If a user wants to support retries they either have to create a custom fetch wrapper or leverage the returned run function.

I am proposing that taking an action based on an error is a common enough scenario that we should support functionality to trigger an action or reaction when it occurs.

The approach in this proposal is to add a property to the options object named errors that itself has support for two properties called maxOnErrorRetry (number) and onError (method). If a request succeeds it prevents further retries to take place. Using the run function bails out of the on error functionality.

implementation from the perspective of a consumer of useFetchye

• Can pass in the amount of retries to cycle through on failed request
• Can define and pass in a method to the errors object named onError that is called on a retry
  • onError method passes in an object as an argument with the properties { key, error, options, run, retryOnErrorCount, maxOnErrorRetry }
  • key === original key used in useFetchye
  • error === the error message (same as the useFetchye error return value)
  • options === options object
  • retryOnErrorCount === current retry count
  • maxOnErrorRetry === max allowed retry count
  • run === function to call to increment the current retryOnErrorCount and make the request again

implementation

• Add a useEffect to packages/fetchye/src/useFetchye.js to manage error logic
• Creates a ref to keep track of the current error retry count
• If maxOnErrorRetry is not defined it will default to 1
• Checks if conditions to run on error are valid (is not loading, fetchye is returning an error, is within the retry range and an onError callback is defined)
• If conditions are met
  • it'll define a function that increments the current value for the retry on error count and wrapping the runAsync function
  • call the onError callback with it's expected arguments

outstanding questions

• Is the functionality being exposed in an ergonomic way? Is there an alternative way that would be better for the dx
• Impact on SSR. I can see the use case being just as valid on the server.
• Currently implemented in the hook. Should this be managed elsewhere?
• Should an eventual solution first be done with a feature flag?

example object a consumer would define

Motivation and Context

While refactoring to use fetchye I encountered the scenario of wanting to retry the request after an initial error. In my specific use case we wanted a workflow like:

• Failed once - have a set state to say 'hmmm let me see‘
• Failed twice - have set state now say ‘still having an issue, let me try again’
• Failed three - have set state now say ‘some issues here’ & show error display Another scenarios could be firing off a beacon call to an analytics for the failed scenario

How Has This Been Tested?

• Tested in a simple demo application that I scaffold here: https://github.com/TatisLois/fetchye-demo
• Needs unit test

Types of Changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation (adding or updating documentation)
• [ ] Dependency update

Checklist:

• [x ] My change requires a change to the documentation and I have updated the documentation accordingly.
• [ x] My changes are in sync with the code style of this project.
• [ x] There aren't any other open Pull Requests for the same issue/update.
• [ ] These changes should be applied to a maintenance branch.
• [ ] I have added the Apache 2.0 license header to any new files created.

What is the Impact to Developers Using Fetchye?

Developers using Fetchye would have greater control over what to do in the event of a failed request without having to bail completely out of the regular fetchye control flow.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

:white_check_mark: nellyk
:white_check_mark: 10xLaCroixDrinker
:x: TatisLois
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codesandbox-ci[bot]]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 5cb7c7dc8f51ea1fce9287a5830a4d8e005c7735:

Sandbox	Source
quick-install	Configuration
fetchye-provider-install	Configuration
fetchye-redux-provider-install	Configuration
nextjs-fetchye-ssr	Configuration

[oneamexbot]

This pull request is stale because it has been open 30 days with no activity.

[code-forger]

Hi @TatisLois, Thanks for your suggestion. I wonder if this would not be better as an entirly new hook useRetry:

const { isLoading, data, errors, run } = useFetchye(...);
const { isSettled } = useRetry({isLoading, isError: !!errors, retry: run, maxRetries: 3});

if (isLoading) return <p>Loading...</p>;
if (!isSettled) return <p>Retrying...</p>;
if (errors) return <p>Error...</p>;

return <p>Success!</p>;

This approach has two benefits:

• It keeps fetchye a little lighter. Every Effect we add to fetchye will be a small drain on any application that uses it, and on large application with lots of data, this could stack up.
• It makes your idea work with any other fetch library, or any async action at all. Any hook or async action that exposes a loading bool, an errors object, and a retry function, can make use of your idea, including iguazu and fetch itself.

Finally, the code would remain mostly the same. Just wrapped up in its own library instead of being embedded in fetchye.

Let me know your thoughts, and we can work with you to bring this idea to life.

[TatisLois]

At first the idea of decoupling the retry logic feature from the fetchye felt like it could become a point of confusion but after some thought I think this is a solid idea and a good direction to go with. The benefit of being able to use the hook outside of fetchye for any async operation that follows the retry hooks signature is dope!

Do you think it should live within this code base but as a separate importable hook, I get the impression it should be it's own utility library that can be installed and used alongside fetchye or any other lib. I can whip up a proof of concept on the hook.

What do you think the next steps should be?

[code-forger]

Closed due to inactivity