What is the best way to update state after getInitialProps?

[semyou]

Can you please tell me what is the best way to update state after getInitialProps?

I have a page like this:

import { useState } from "react";
import fetch from "isometric-unfetch";
const Page = props => {
  const [patient, setPatient] = useState(props.data);
  return (<h1>{patient.name}</h1>);
};

Page.getInitialProps = async () => {
  const resp = await fetch(SOME_URL);
 const data = await resp.json();
  return { data };
};

export default Page;

My Problem: When I fetch the data from the getInitialProps, it is not reflected on patient. Because by the time I get the fetch to respond, my page has already displayed empty data.

My solution: I added a useEffect inside my Page like this and now it works. Is this a hack? Is there a better way to do this?

import { useState,useEffect } from "react";
import fetch from "isometric-unfetch";
const Page = props => {
  const [patient, setPatient] = useState(props.data);
  useEffect(()=>{
   setPatient(props.data);
})
  return <h1>{patient.name}</h1>;
};

Page.getInitialProps = async () => {
  const resp = await fetch(SOME_URL);
 const data = await resp.json();
  return { data };
};

export default Page;

[rafaelalmeidatk]

Because by the time I get the fetch to respond, my page has already displayed empty data

Next won't render the page until getInitalProps is resolved, so the props are always defined when it is time to render. If you are seeing a behavior different than this one, please share a full reproduction and we can give a look

[semyou]

@rafaelalmeidatk It took me one day to isolate the problem. Here is a code sandbox:

https://codesandbox.io/s/small-leftpad-dsofl?file=/pages/index.js

You will see that if you SSR /?user=1 or /?user=2, both work well. However, if you CSR either by clicking on the links above the home page, the result of the last SSR sticks and the link clicks do not change the value (you can see that the client has actually fetched the correct data from the getInitialProps via the console.log on your browser).

Now, if you uncomment the useEffect clause, things work even in CSR mode.

My question: Is this expected? What's the best way to achieve what I want to achieve? Is useEffect the best solution? This should be a common pattern.

Thanks

[rafaelalmeidatk]

It isn't changing because you are setting props.user into a state and isn't changing it anymore. If instead of <li>{user.name}</li> you use <li>{props.user.name}</li> it will work correctly

[semyou]

@rafaelalmeidatk : I need to display the result of the state and not props.user.name, because the state can/will be changed by other children of the component. And when the children change the state of user through inherited setUser, user.name should be displayed and not props.user.name. That's the situation I am in. Any suggestions?

[rafaelalmeidatk]

Ahh I see, sorry I didn't notice you are using derived state. In this case it is perfectly fine to use useEffect to update the state. Just be aware that using an object in the deps array will always rerun the effect if the reference isn't stable

[semyou]

Thanks. That's what I am using now but it feels hackish..

[rafaelalmeidatk]

@semyou I posted a more detailed reply below, I hope it helps you

[rafaelalmeidatk]

I discussed about this problem with some folks at Reactiflux and these are the solutions I recommend:

1) Fully controlled component

This solutions isn't always viable. Basically you don't control the state inside your page, you use the URL as your "state", so instead of having a copy of the user state in your page, you will always read from the props:

const User = (props) => {
  return (
    <>
      <Link href="/">
        <a>User 1</a>
      </Link>
      <Link href="/?user=2">
        <a>User 2</a>
      </Link>

      <h1>Current User</h1>
      <div>{props.user.name}</div>
    </>
  );
};

This solution is more useful for things like wizard forms pages.

2) Using derived state from the props

This a more common pattern, you receive the user data and want to let the user change it in your page, but if the user navigates to the page of another user, then the page has to reset to show the data of the new user.

This solution is based on the example from the React docs of implementing getDerivedStateFromProps with hooks: https://reactjs.org/docs/hooks-faq.html#how-do-i-implement-getderivedstatefromprops

const User = (props) => {
  const [user, setUser] = useState(props.user);
  const [prevUser, setPrevUser] = useState(props.user);

  // Here I utilized the ID to keep the comparison cheap,
  // if you don't have an unique identifier you would have
  // to use something like lodash#isEqual
  if (props.user.id !== prevUser.id) {
    setUser(props.user);
    setPrevUser(props.user);
  }

  return (
    <>
      <Link href="/">
        <a>User 1</a>
      </Link>
      <Link href="/?user=2">
        <a>User 2</a>
      </Link>

      <h1>Current User</h1>
      <div>{user.name}</div>
    </>
  );
};

3) Uncontrolled with a key

An alternative to solution 2 is to move your logic to a component bellow, and render this component with a key that equals to the user ID:

const User = (props) => {
  return <UserContent key={props.user.id} initialUser={props.user} />;
};

const UserContent = (props) => {
  const [user, setUser] = useState(props.initialUser);

  return (
    <>
      <Link href="/">
        <a>User 1</a>
      </Link>
      <Link href="/?user=2">
        <a>User 2</a>
      </Link>

      <h1>Current User</h1>
      <div>{user.name}</div>
    </>
  );
};

With this solution, everytime you change a page, the value of props.user.id will change and React will create a new instance of UserContent, reseting all the state the old component had. This may sound like a very bad solution performance-wise but it is not, according to the docs:

While this may sound slow, the performance difference is usually insignificant. Using a key can even be faster if the components have heavy logic that runs on updates since diffing gets bypassed for that subtree.