Best practice for guaranteeing query refresh on new page loads

[sivasquared]

Hi folks 👋 ,

Wondering what the best practice would be in this case.

Use case
Let's say I have two pages
/foo
/bar

and /foo renders 10 components all of which use a recoil value where the underlying value is fetched from an api.

When I switch between /bar and /foo, I want to guarantee that the page(/foo) makes a fresh api call to get the latest data.

Approaches
My current approaches to solving this are

1. use useRecoilRefresher_UNSTABLE to reset the recoil value to force a fresh fetch. I do the reset in the top most component that renders the page. This guarantees that I will fetch the data every time the page loads and will only load the data once on page load.

2. Have the recoil value be dependent on a request id. Change the request id every time the route changes.

3. TBD

What is the best practice for this use case? Really appreciate any advice 🙏

[sivasquared]

I ended up going with something like this;

const RecoilUpdater: React.FC = () => {
  const pathname = useLocation().pathname;
  // We only want to monitor if the root page changes
  const newCurrentPage = pathname.split("/")[1];
  const previousCurrentPage = useRecoilValue(currentPageState);
  const setCurrentPage = useSetRecoilState(currentPageState);

  useEffect(() => {
    if (newCurrentPage && previousCurrentPage !== newCurrentPage) {
      setCurrentPage(newCurrentPage);
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [pathname]);
  return null;
};

and have my recoil states that I want to be refreshed be dependent on this

Using a component to leverage the useEffect hook but curious if there is a better way to do this.

[csantos42]

I think both approaches are completely valid and they both come with tradeoffs. The nice thing about the approach you chose is that the selector has the power of opting in/out of listening to route changes in the same location where the selector is defined, as opposed to the alternative of centralizing route-change effects to a separate hook higher in the tree (which is not a very Recoily thing to do since Recoil promotes decentralization).

The only downside I see is that it feels awkward to subscribe to data for the sole purpose of busting the cache, since the data isn't actually used in the selector logic. At some point I think we should continue exploring the idea of Selector Effects so we could do things like:

selector({
  get: () => { /* ... */ },
  effects: [
    resetCacheOnRouteChange,
    resetCacheAfterMs(10000),
    logSelectorChange,
  ],
});

But as far as I know Selector Effects aren't officially on the roadmap yet

[sivasquared]

Thanks for the 👀 Christian. Selector effects would be awesome. It would definitely help our use case. We'll stick with this implementation for now.