Skip to content

SSR: trust guessedBreakpoint during hydratation #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

ValentinH
Copy link
Contributor

@ValentinH ValentinH commented Feb 23, 2020

As explained in #29, when the breakpoint is wrongly guessed on the server, there is an HTML mismatch during ReactDom.hydrate(). When using a CSS-in-JSS technique, this can lead to a completely broken page due to wrong CSS classnames being used.

This PR simply solves this issue by letting the developer set the guessedBreakpoint on the client as well. Thanks to this, there will be no mismatch during hydratation. Once the app is hydrated, it will be rerendered using the real breakpoint (during componentDidMount() ).

There will be a "blinking" effect on load when switching between the guessed breakpoint and the real one (as with current version), but now, there is no mismatch so no risk of unfortunate side-effects anymore.

As explained in ehellman#29, when the breapoint is wrongly guessed on the server, there will be an HTML mismatch during `ReactDom.hydrate()`. When using a CSS-in-JSS technique, this can lead to a completely broken page due to wrong CSS classnames being used.

This PR simply solves this issue by letting the developer set the `guessedBreakpoint` on the client as well. Thanks to this, there will no mismatch during hydratation. Once the app is hydrated, it will be rerenderd using the real breakpoint (during `componentDidMount()` ).

There will be a "blinking" effect on load when switching between the guesss breakpoint and the real one (as with current version) but now, there is no mismatch so no risk of unfortunate side-effects anymore.
@ValentinH ValentinH requested a review from ehellman February 23, 2020 18:32
@ValentinH
Copy link
Contributor Author

Let's face it, this will never be merged 😅

@ValentinH ValentinH closed this Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant