This is more about the perils of React switching from component classes where lifecycle methods were explicit and obvious to the multipurpose leaky abstraction known as useEffect and the hooks API. To anyone that went through the class phase, this issue is probably obvious and well known.<p>Also, Gatsby. If Gatsby is hiding the React warnings when your SSR diverges from client side, then that's on Gatsby. It's hard enough to debug when you know what's going on. This is like going in blindfolded with both arms tied behind your back.<p>Luckily this issue only comes up a handful of times.
I think the common, simpler way is to make the component itself (<AuthenticatedNav>) state-aware. So it always returns that component, but the component itself renders differently (`isLoggedIn && <NavBarSubComponent>`) depending on some upstream state passed as a prop or a shared context via a context provider.<p>If you return two different tags like the author did, React won't know how to properly inject that into the DOM. They are different elements, after all.
Honestly, it's a very frustrating aspect of modern web development that developers still have to care about this client/server split for initial render.<p>JavaScript, via Node, threatens to consume server-side implementations of user-facing output for no other reason than this is an annoying problem that gets even more annoying if your client and server are talking two different scripting languages.
I know this is way besides the point, but<p>> Smart people realized that if we could do that rendering on the server, we could send the user a fully-formed HTML document.<p>Is so funny to read. It’s like history never happened.
Trying to couple client server might seem like a good idea, but you are always left guessing as to how the component got in the state it is in, which defeats a lot of the stateless ideas and puts us in a bad place debugging. Express is a good idea, React is a good idea, NextJs and the like make the developers guess until they get burned enough and then by that time a new concept like hooks vs class components comes to popularity and you start the process of learning where the new pit traps are located, until the next big shakeup.
Just to clarify myself. If I have already logged in and now closed the window. Again open a tab and send request to the server, won't the token/cookies/sessioninfo etc. be sent in the initial request to the page? And if the auth info is sent via the headers, can we not check the user login status (expired sessions) at the server and send the right component back?