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

useFetcher: fetcher.load doesn't revalidate when search params change #5090

Closed
dT-Nick opened this issue Jan 13, 2023 · 5 comments · Fixed by remix-run/react-router#9948
Closed
Labels
bug Something isn't working feat:routing

Comments

@dT-Nick
Copy link

dT-Nick commented Jan 13, 2023

What version of Remix are you using?

1.10.0

Steps to Reproduce

CodeSandbox URL

Click the button Change query string. That submits a form that revalidates the index.tsx loader but doesn't revalidate fetcher.load. If you click the button Run 'index.tsx' action, it works as expected, and revalidates both.

The fetcher runs a resource route's loader - with the intent of using shouldRevalidate to manage whether it actually revalidates or not.

Expected Behavior

I would expect a change in search params to revalidate all 'active' instances of fetcher.load by default (as per 1.10.0 updates, where fetcher.load revalidates).

Actual Behavior

Changing the search params doesn't seem to revalidate fetcher.load in this instance. I understand I could change the URL in fetcher.load to include the search params, but then the shouldRevalidate function in the resource route isn't run, and I'd have to stick any shouldRevalidate logic into the useEffect.

@brophdawg11 brophdawg11 added bug Something isn't working and removed bug:unverified labels Jan 17, 2023
@brophdawg11
Copy link
Contributor

Thanks @dT-Nick - I'm taking a look at this now. I think this is a bug but confirming internally. Fetchers have slightly different shouldRevalidate logic at the moment and only fall into the shouldRevalidate flow on explicit revalidations (after an action submission, a useRevalidate call, or a redirect that forced a revalidation by setting a cookie). But it seems like they oughta respect the few additional scenarios that would cause a route loader to implicitly revalidate (route params changes, search params change, or clicking a link to the exact same current location)

@brophdawg11 brophdawg11 self-assigned this Jan 17, 2023
@dT-Nick
Copy link
Author

dT-Nick commented Jan 19, 2023

Great thanks! Perhaps this could go hand in hand with #5091.

I know within a resource routes loader function you can access the referrer (the current URL a user is actually on) from the headers. So I'm hoping you might be able to access that (and the next referrer URL, similar to shouldRevalidate's currentUrl and nextUrl) from the shouldRevalidate function. I can see the shouldRevalidate function only runs on the client though, and I have no idea how it's working under the hood, so I'm assuming it's not that easy.

@brophdawg11
Copy link
Contributor

Commented over there but yeah I think that's just a bug

@brophdawg11
Copy link
Contributor

This should be fixed in Remix 1.12.0 which should be deployed in the next hour or two

@brophdawg11
Copy link
Contributor

Released in 1.12.0

@brophdawg11 brophdawg11 removed the awaiting release This issue has been fixed and will be released soon label Jan 31, 2023
@brophdawg11 brophdawg11 removed their assignment Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feat:routing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants