eser / fetchp Goto Github PK

Is your feature request related to a problem? Please describe.
The fetchp does not allow users to retry failed requests, which can cause problems with data transfers. Adding a request retry feature would make transfers more reliable and successful.

Describe the solution you'd like
The retry property in the FetchpRequestInit interface allows users to specify whether or not to retry failed requests, and how many times to retry them. It can be set to a boolean value, a number, or a custom function that determines whether or not to retry a request based on the error that occurred.

• If retry is set to true, the fetchp will automatically retry failed requests once.
• If retry is set to a number, the fetchp will automatically retry failed requests that number of times.
• If retry is set to a custom function, the fetchp will pass the error that occurred to the function, and will only retry the request if the function returns true.

Additional context
The retryDelay function calculates the time to wait before retrying based on the attemptIndex, which starts at 0 for the first attempt. It can be used to increase the delay with each retry attempt to prevent overwhelming the server.

Is your feature request related to a problem? Please describe.
My feature request is related to a problem because the current behaviors doess not allow users to invalidate the cache, which can lead to incorrect or outdated information being returned. By adding a cache invalidation feature, users can ensure that they are always working with up-to-date information.

Describe the solution you'd like
I propose adding a new function to the fetchp called invalidateQuery() that allows users to invalidate the cache for a specific query. This function would take a query parameter as input, and would remove any cached results for that query from the cache. This would allow users to ensure that they are always working with the most up-to-date data, even if the cache has become stale or outdated.

Example at bellow:

response.invalidateQuery()

open to debate

Is your feature request related to a problem? Please describe.
no it's not a problem it's just syntax sugar.

Describe the solution you'd like
I feel like I'm actually using fetch when making a POST request.

For example right now my POST request looks like this:

const { data, error, doFetch, isFetching } = useFetchp('GET', 'localhost:3050/api/auth/v1/register')

doFetch({
	body: JSON.stringify({
		email: '[email protected]',
	}),
})

I think we can do it this way:

const { data, error, doFetch, isFetching } = useFetchp('GET', 'localhost:3050/api/auth/v1/register')

doFetch({
	email: '[email protected]',
})

Is your feature request related to a problem? Please describe.
Yes, it's about an issue. I was going to use fetchp for the first time today and I wanted to use it as reactive in a react project.

Describe the solution you'd like
In the example there was a usage like:

import { useFetchp } from "fetchp";

const MyComponent = (props) => {
  const { data, isLoading, error } = useFetchp("GET", "/posts");

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Error: {error.message}</div>;
  }

  return <div>{JSON.stringify(data)}</div>;
};

But isLoading doesn't actually work as expected. isFetching meets the expectations of isLoading. So when I updated as below, the problem did not occur.

import { useFetchp } from "fetchp";

const MyComponent = (props) => {
  const { data, isFetching, error, doFetch } = useFetchp("GET", "/posts");

  useEffect(() => {
		  doFetch()
	  }, [])

  if (isFetching) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Error: {error.message}</div>;
  }

  return <div>{JSON.stringify(data)}</div>;
};

Also, no example is given for POST request. I was able to learn how to send parameters by examining the codes.

Describe alternatives you've considered

• POST request usage example can be added.
• Current usage should be added for React usage, it doesn't work when copying in Readme.

If we don't want the README to be long, we can at least prepare a documentation.