Router.push/replace calls in useEffect vs render ?

[josebrito]

Hi,

By following NextJS examples, I'm aware that calls to Router.push/replace should be wrapped into useEffect hooks. However, I did not find a clear explanation as to why we should do:

function MyComponent({ somePropThatChecksForRedirect }) {
  const router = useRouter();

  useEffect(() => {
    if (somePropThatChecksForRedirect) {
      router.push("/");
    }
  }, [somePropThatChecksForRedirect]);

  return <div>Hello</div>;
}

over

function MyComponent({ somePropThatChecksForRedirect }) {
  const router = useRouter();

  if (somePropThatChecksForRedirect) {
    router.push("/");
    return null;
  }
  
  return <div>Hello</div>;
}

Can someone clarify as to why one pattern should be used over another? Or are they both correct?

Thank you

[jagaapple]

This is related to React lifecycle and not Next.js.
When states or giving props are changed in ancestor components of the component, the render function of the component is recalled every time even if the same props are given.

If you write code within if statements in render functions directly, they are called many times more than expected.

[josebrito]

That's what I thought, since we've experienced a couple of bugs that behaviour.

However let me clarify why I asked this question. We've migrated a client-side app that used react-router. So, before it was normal to do something like this:

function MyComponent({ somePropThatChecksForRedirect }) {
  if (somePropThatChecksForRedirect) {
    return <Redirect to="/" />;
  }
  return <div>Hello</div>;
}

So when we migrated to Next, the routing was kept in the render function, just like my example in the first post.

Turns out that the Next documentation isn't clear regarding this, and we ended up making this mistake a couple of times. I suggest adding something to the Next documentation, even if a small side note, to clarify that routing should be done in React lifecycle side-effects.

Thank you!