Good use of SWR

[ErnestBrandi]

Hi, I have a few questions about how SWR should be used the best.
Let's consider the following 2 use cases

Use SWR in parent and pass down props

export default function Page() {
  const { data: user } = useSWR('/api/user')
  const { data: projects } = useSWR(() => '/api/projects?uid=' + user.id)

  return (
    { !user && !projects ? (
        <Pogress />
      ) : (
        <SomeComp 
          user={user}
        />
        projects.map((value, index) => 
          <Child
            key={index}
            user={user}
            project={project}
          />
        )
      )
    }
  )
}

export default function SomeComp(props) {
  const user = props.user;
  // ...
}

export default function Child(props) {
  const user = props.user;
  const project = props.project;

  return (
    <div>Do stuffs...</div>
  )
}

Use SWR in each individual component

export default function Page() {
  return (
    <SomeComp />
    <Child />
  )
}

export default function SomeComp(props) {
  const { data: user } = useSWR('/api/user')
  
  return (
    { !user ? (
        <Pogress />
      ) : (
        // user stuffs
      )
    }
  )
}

export default function Child(props) {
  const { data: user } = useSWR('/api/user')
  const { data: projects } = useSWR(() => '/api/projects?uid=' + user.id)

  return (
    { !user && !projects ? (
        <Pogress />
      ) : (
        // projects.map()
      )
    }
  )
}

I feel like this is a common question but, which method should be preferred ?
I know it is not so much related to SWR itself but more about having dumb/smart react component (still what's SWR opinion about that) ?
I also know SWR use cached data so there is nothing wrong (performance wise) by doing the second method.
Also, what about a combination of those two way of doing ? Would that make sense sometimes or would it just be messy ?
Thanks for your replies !

[huozhi]

hi @ErnestBrandi I prefer the second one, and you can also optimize the user call in Child component to passing down the prop user.

export default function Page() {
  return (
    // you might have sth else here, or you can merge `Page` and `SomeComp`
    <SomeComp />
-  <Child />
  )
}

export default function SomeComp(props) {
  const { data: user } = useSWR('/api/user')
  
  return (
    {!user ? (
        <Pogress />
      ) : (
+        <Child user={user} />
      )
    }
  )
}


export default function Child(props) {
-   const { data: user } = useSWR('/api/user')
+  const { user } = props // then here for sure we had a user
  const { data: projects } = useSWR(() => '/api/projects?uid=' + user.id)

  return (
    { !user && !projects ? (
        <Pogress />
      ) : (
        // projects.map()
      )
    }
  )
}

it can make the call more consistent that you won't have multiple renders overlapped between user hooks and projects hooks. the projects hook will be called always after user is resolved.

[ErnestBrandi]

Ok so you would kind of combine the two then !

[taylorhlabs]

In this case, my understanding is that any changes to user (like someone making a change to the user on another device) would not be rendered in the Child component after initial render since user is being passed as a prop. A major advantage of using SWR seems to be its ability to fetch the latest data in the background but if you want to take advantage of this in your app, you cannot pass SWR data to child components as props because prop changes won't trigger a re-render in the child component. Assuming this is true, we have to use the pattern provided by @shuding to take advantage of the background refresh of the data. Is my understanding correct here?

[ErnestBrandi]

Hi, no this is not true. SWR uses useState internally in order to know when to re-render UI; so when data is updated in a certain component, it is also updated in all its children where this data is passed down as a prop. The question was more about a conceptual way of coding than a practical way.

[taylorhlabs]

Thanks for clarifying, @ErnestBrandi. I had an error in my logic and wasn't passing props down correctly.

[shuding]

We're using the second pattern at Vercel. Also we created tons of "data hooks" such as:

function useUser () {
  return useSWR('/api/user')
}

And then just use useUser() inside every component which needs user.

Because of that, we don't need to pass props around the tree. It's also easier to maintain (so we can easily compose a UI without caring about data props).

SWR handles deduping automatically. So it's basically just an extra useState and the performance overhead can be safely ignored.

[ErnestBrandi]

Nice ! I agree with the fact that it is easier to maintain; with props and nested components at some point you can't really tell where does the data come from and it can lead to dependency problems (https://github.com/vercel/swr#dependent-fetching).

[pffigueiredo]

@shuding what about testing, won't this be creating a lot of coupling? Isn't "constructor injection" a preferred solution?

[sergiodxa]

I use more the second way, where each component fetch what it needs instead of passing via props. I additionally tend to prefetch in the parent when the child is going to be rendered conditionally, this way I already have the data in cache when the child is rendered.

[ErnestBrandi]

Hmm interesting ! That might also be a good way to handle a single "Progress" (spinner or whatever) in the top component and then displaying the data directly in the children.

[ErnestBrandi]

Thanks for those answers :) I have another question.
When should I use SSR (getServerSideProps) and when should I go for SWR ?

Since I started using SWR, I can't figure out any good use case for SSR anymore... Indeed, you can always display the page template (navbar, footer, etc) and populate it client side (showing a progress while fetching data). Plus, this is less work for the server which was a big trend in websites development a few years ago.

I know you can combine both of these worlds with initialData.

Is there obvious situations where I should use SSR and not SWR (or just client side fetching) ?

[sergiodxa]

You can use them combined, use SSR to get the data and render immediately, then pass that data to SWR as initialData and let SWR handle the logic to revalidate it and keep it up-to-date. This is the same if you use SSG instead of SSR, you can use them combined with SWR.