blog/avoiding-hydration-mismatches-with-use-sync-external-store

[TkDodo]

blog/avoiding-hydration-mismatches-with-use-sync-external-store

Avoiding hydration mismatches can usually be done in two ways - suppressing the warning or spawning an effect. But is there a third option ... ?

https://tkdodo.eu/blog/avoiding-hydration-mismatches-with-use-sync-external-store

[micahjon]

Excellent article, thanks for sharing

[prateek3255]

Hey @TkDodo, great article as usual. I just had one doubt, in the minimizing layout shift section, why do we need to ensure that the output is same on server and client for getServerSnapshot, I understand that it's because we need to produce the same output as server during hydration to avoid mismatch, but the docs also say that the value is serialized and passed from the server to the client, so why can't it use the serialized value during hydration instead of calling the getServerSnapshot again?

[TkDodo]

so why can't it use the serialized value during hydration instead of calling the getServerSnapshot again?

that I do not know. I guess the serialization happens as part of the produced html output only?

[ImSingee]

I don't look at the source code, but from the document I think getServerSnapshot is called only on server. So we must return the same result in getSnapshot (for the first time) and getServerSnapshot to avoid hydration mismatch.

[TkDodo]

No, it's definitely called on the client as well: https://react.dev/reference/react/useSyncExternalStore#parameters

Emphasis mine:

optional getServerSnapshot: A function that returns the initial snapshot of the data in the store. It will be used only during server rendering and during hydration of server-rendered content on the client.

[jonaskuske]

In the future, HTTP Client hints will hopefully make this whole situation better, because it will give servers a way to know information that is only available on the client before rendering anything. With that, we could SSR correct information without needing to resort to workarounds. Until then, I think this is as good as it gets, and I'd prefer useSyncExternalStore to the effect solution any day.

I think it'd be helpful to mention that for the given example, date rendering, the Accept-Language header is available without Client Hints. So to get stable date rendering, you can read it from Accept-Language (server) / navigator.language (client) or from a cookie if locale is user-selected instead of inferred.

[TkDodo]

yep good point, we actually do this at work. Not sure why I didn't think of it 😅 . The classic examples that the server can't know is timezones and screen dimensions (for server-rendering responsive screens)

[mechaniccoder]

Thanks for sharing great article. By the way, i have a question. Flash of content might occur both from double render pass and useSyncExternalStore. The difference is useSyncExternalStore renders client snapshot more earlier than double render?

[TkDodo]

for a real first client render, it works the same. But if you transition to a page on the client, it will be one render with uSES but two with useEffect.