Different outcomes in production vs development depending on window size

[nikoladev]

Description

I have a page with a navigation menu on the side that can be opened and closed. If the site is loaded on desktop (defined as a window width of more than 768 pixels), then the menu should start in the open state. If the site is loaded with a window width of less than 768 pixels the menu should start in the closed state. I use window.matchMedia to check the window width.

This works fine in development. But when I build the site something strange occurs. If I load the page in a wide window the menu button doesn't work. However, if I reload the page while it has a narrow width and resize afterwards to a wide window the menu button now works.

Why is this happening? I'm even using the DEV_SSR flag, to pre-empt bugs like this.

Steps to reproduce

• Download the minimal reproduction
• Run npm install
• Run npm run develop and go to http://localhost:8000. Try reloading the page in a wide window. The menu should start in an open state and you can open and close the menu.
  • Check the console for some logs. This is what it looks like when everything works
• Run npm run build and npm run serve and http://localhost:9000. Try reloading the page in a wide window. The menu is closed and the menu button doesn't work.
  • Check the console. When the menu button doesn't work, its onClick handler is never called.
• Now resize the window so it's narrow and reload the page. The menu button works. If you resize the window to be wider without reloading the menu button will keep working.
  • Check the console. The onClick handler works.

Expected result

The production build should work just like in development. Reloading the page in a wide window should not cause the menu button to fail, the button should fire its onClick events. Also, the menu should start in an open state on a wide window.

Actual result

When the production build page is loaded in a wide window the menu doesn't start in an open state. And the menu button doesn't work.

Environment

  System:
    OS: macOS 10.15.7
  Binaries:
    Node: 14.15.4
    npm: 6.14.10
  Languages:
    Python: 2.7.17
  npmPackages:
    gatsby: 2.30.1 => 2.30.1 
    gatsby-plugin-sass: 3.0.0 => 3.0.0 

[matt-koevort]

@nikoladev have you looked into something along the lines of the following: https://www.joshwcomeau.com/react/the-perils-of-rehydration/

Sounds like a rehydration issue to me.

[nikoladev]

@matt-koevort I think you're right, and according to that article you linked there is already an issue on this at #17914.

Just like in the article, I managed to fix it by using useEffect to change the state after the first render:

// Old code
const [ menuIsOpen, setMenuIsOpen ] = useState(
  canMatchMedia()
    ? !isMobile()
    : false
)

// New code
const [ menuIsOpen, setMenuIsOpen ] = useState(false)
useEffect(() => {
  if (canMatchMedia()) {
    setMenuIsOpen(!isMobile())
  }
}, [])

There is a slight difference in end result, in that the menu doesn't start in an open state but instead starts with the animation leading into the open state. But that's an acceptable "bug" :)

Then the question that remains is why this behavior wasn't replicated in development with the DEV_SSR flag (which is supposed to help in preventing these bugs).

Thanks for your help!

[LekoArts]

Thanks for linking the article and also adding your solution here (for future google searches)!

For your question on DEV_SSR I'd kindly suggest posting this to #28138 so that @KyleAMathews can answer there. Thanks!