Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Server client html mismatch occurs on first render

See original GitHub issue

Issue Description

Warnings like Warning: Expected server HTML to contain a matching <button> in <div>. occurs because html was rendered with no url params on server side, but rendered with url params in client side.

I think Next.js handles this problem by setting router.query to an empty object on the first render, and sets client url params on the next render. But because useUrlState uses window.location.search and not router, this warning occurs.

This can be avoided by using code like this:

const [queryState, setQueryState] = useQueryState(...);
const [state, setState] = useState();
useEffect(() => setState(queryState), [queryState]);

But it would be better if this boilerplate could be avoided in some way.

Issue Analytics

State:
Created a year ago
Reactions:5
Comments:5 (1 by maintainers)

Top GitHub Comments

1reaction

ViktorQvarfordtcommented, Oct 19, 2022

I think the correct solution would be to always return the default value on both server and client-side on the initial render. Reading from window.location should be done in an effect. See this article for an in-depth explanation of why this is important https://joshwcomeau.com/react/the-perils-of-rehydration/

0reactions

franky47commented, Sep 5, 2022

Unfortunately the Next.js router does not expose querystring params in the render tree in SSR, so those should be treated as client-side only (just like you would for code that depends on local storage values for example).

While theoretically it could be possible to get this kind of information on “per request” SSR (ie: page with getServerSideProps), other kinds of non-client renders (ISR, static optimisation at build time) are not attached to a request and therefore don’t have querystring parameters.