Accessing the same SWR hook in nested components

[stefan-spittank]

I am wondering whether we use the SWR hooks in the intended way.
Sometimes we use the same data in a parent and in nested child components. In such cases we fetch the data in the parent component and pass it via props to the nested child components.
It looks as if the official SWR documentation recommends using the hook locally in every component and fetching the (already cached) information there.
I am aware of the caching part, but wonder how this affects the rendering. 
Given I have one parent component P and two child components C1 and C2. If I fetch the data in P and pass it down, each component would render once.Wouldn't the child components be rendered twice if each component fetches the data itself? First due to the parent component being re rendered and again after they receive the data itself.
Am I missing something?

[icyJoseph]

Yeah... but it depends... consider this example:

import useSWR from "swr";

const useData = () => {
  return useSWR<string>("data", () => {
    return new Promise((resolve) => setTimeout(resolve, 1000, "data"));
  });
};

const Parent: React.FC = ({ children }) => {
  const { data } = useData();
  console.count("Parent");

  return (
    <section>
      <h1>Parent {data}</h1>

      {children}

      <Child label="inner" />
    </section>
  );
};

const Child = ({ label }: { label: string }) => {
  const { data } = useData();
  console.count(`Child: ${label}`);

  return <p>{data}</p>;
};

const Home: NextPage = () => {
  return (
    <div>
      <Parent>
        <Child label="1" />
        <Child label="2" />
        <Child label="3" />
      </Parent>
    </div>
  );
};

This would log (without strict mode):

Parent: 1
Child: 1: 1
Child: 2: 1
Child: 3: 1
Child: inner: 1
Child: 1: 2
Child: 2: 2
Child: 3: 2
Child: inner: 2
Parent: 2
Child: inner: 3

But we shouldn't let the logs dictate our understanding. We can profile this using the React Dev Tools, which is what you should do in your use cases.

The Profiler would show about 7 frames (using NextJS).

1. First, everything renders
2. Some Next JS Dev Tool component renders (safe to ignore)
3. Child 1 re-renders
4. Child 2 re-renders
5. Child 3 re-renders
6. Child inner re-renders
7. Parent + Child inner re-render

This means that using composition, in this case, prevents re-rendering for children 1,2 and 3, which is not only true for swr, but in general for any piece of state management. This is because not all children at redefined during the render pass, only the one I call inner, that will be a new child every time.

Edit: Using memo on the inner Child, would change the 7th frame to only Parent re-renders.

As usual, there's no silver bullet answer.

Also, re-rendering is not necessarily that bad, it only means that React collects updates. SWR is highly optimized to prevent re-rendering of callers. And last, but not least, when using this global data solutions, we must remember that, most of the time, components sharing a data slice, are actually using the same data reference.

• How does vercel use SWR?
• A great resource on composition

[icyJoseph]

Awesome, one thing I forgot there, is that you could use memo on Child, then use this memoized Child inside Parent, and that'd cut down the third inner Child render.

[pke]

@icyJoseph I was under the impression with swr we would have more black box components and don't need composition anymore? Exactly like in the "how does vercel use SWR" described.

[icyJoseph]

Yes, definitely. However, this goes more into how does one architect the application, because when a parent renders, the entire children tree is re-rendered, unless memoized on a per-child basis.

The question is then, how much black boxing we allow within components, and whether or not, we should reach out to other patterns for prevent performance problems.

It's not an swr problem really, it's more into the React Rendering Behavior. Small applications can use black boxing easily, large applications could also do it, as long as we can safely and clearly avoid expensive rendering. Otherwise, we ought to reconsider our architecture. As you have read, vercel, uses swr so it is possible.

In your particular case, I am not sure how could one tackle the react-navigation render model, because if all views are mounted, then any change to state will be expensive to execute.

[pke]

Thanks for your extensive answer @icyJoseph!
I figure I might improve the swr caused re-renders by adjusting the way swr refetches.
react-navigation offers a way to know if a current screen (component) is in focus.
If I include this in the cache key condition, it should only fetch if its in focus?

useSWR(isFocused && sessionId ? "user" : null, ...)

once the screen had been mounted one time the cache would be updated. But does this prevent the fetcher from being called again when the screen is not on focus and the cache key evaluates to null?

[icyJoseph]

Let's try to keep things tidy. I've answered here #1839 (comment).