Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support refetching if options.body changes, even if url doesn't #28

Closed
ncknuna opened this issue Dec 13, 2018 · 5 comments
Closed

Support refetching if options.body changes, even if url doesn't #28

ncknuna opened this issue Dec 13, 2018 · 5 comments

Comments

@ncknuna
Copy link

ncknuna commented Dec 13, 2018

In the version that I'm using,

if (url && url !== prevProps.url && !manual) {
specifies that we shouldn't refetch if the url hasn't changed.

In my code I'm using this component with a POST call with a body, where the user can modify the page state to change the body, which I'd like to trigger a refetch, but since the URL is the same, it doesn't. I worked around this by adding a fragment to the end of the URL that takes a hash of the body, but it'd be nice if this just worked by default. At minimum, it would be good if this behavior was documented, since I had to spend a decent amount of time poking around before I figured it out.

@techniq
Copy link
Owner

techniq commented Dec 13, 2018

Interesting point. I've always used manual and issued the request myself using fetch for POST calls. Since POST calls are more risky (changing data, etc) I've always assumed others would be doing the same.

We could look into supporting a way to trigger an automatic refetch based on other parameters (body, but not necessarily limited to it, for example changing headers, etc).

In your case is it possible to issue the request manually, or does it need to be automatic (and the url fragment is a decent workaround like you found)?

@ncknuna
Copy link
Author

ncknuna commented Dec 13, 2018

Yea, I admit that this is a bit of an odd usecase; the API we're calling is doing an analytic query, so it's not actually modifying state, but it may require a lot of input params that are better suited to a body and the query isn't computationally cheap, so it's a POST (I also didn't design the API we're calling, so I don't have much control over the decision :P)

Yea, while options.body is my particular usecase, a more generic solution makes sense to me.

Yea, there are plenty of workarounds. We could use manual, or just keep doing the url fragment thing, so this isn't super urgent. It was mostly just not intuitive to change the body and have it not refetch and not know why without digging into source code.

@techniq
Copy link
Owner

techniq commented Feb 3, 2019

@ncknuna I added support for this use case with a new deps (aka depenencies) prop.

I use this on new GraphQL component I'm working on where you always POST to the /graphql endpoint with a different body (query/variables). So far it's working well (and plan to open source it once I've settled on the API. Plan is to keep it lightweight (much more so than apollo-client, etc). It's based on react-fetch-component similar to how my react-odata one was.

I need to update the docs to show deps, but take a look at the commit and tests.

@techniq techniq closed this as completed Feb 3, 2019
@techniq
Copy link
Owner

techniq commented Feb 3, 2019

@ncknuna Forgot to mention this is in v8.0.0-9 prerelease. Just waiting for Hooks to be released (maybe Feb 4th) to make it 8.0 stable.

@ncknuna
Copy link
Author

ncknuna commented Feb 5, 2019

Ah, cool, thanks :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants