-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
React 18 NextJS 12.1 - Hydration failed #1428
Comments
We got around this by effectively memoizing a boolean to track the loading state of it (and only rendering it once). |
I‘d recommend to check on something like window (which is only available on client side). This needs to be done in useEffect for proper handling.
|
Like @sandrooco said, this can fix the issue. |
@davidkhierl import dynamic from "next/dynamic";
const ReactPlayer = dynamic(() => import("react-player/lazy"), { ssr: false }); Make sure to implement this solution when using the above method |
These workarounds look good. It’s also possible this is fixed in |
Um sorry, why this issue closed? I'm still getting hydration error with Dynamic import fixed the issue, but the |
@degitgitagitya It seems to be a issue with |
Rendering the component on the client side only isn't a solution and has negative performance impact, @cookpete this issue should be reopened. |
@mrgnou I’m happy to reopen this for visibility (although there is quite a backlog of issues now and I have little spare time) but what is the solution? What should be rendered on the server? This library loads third party scripts on the client to embed video players. What markup could we possibly render on the server that would make sense? |
Is it an alternative is to include a empty iframe ? I suppose iframes are a good solution as they could be marked optionaly as unoptimized. Or maybe it could include a option for client-only, where it waits of an effect to set a boolean true if window is defined, it does defeat the pourpouse of optimization, but makes a transparent workaround for some providers. |
I'd say everything that can be rendered synchronously to avoid client side rerender.
I know maintaining such a lib is really time consuming, and thank you for your hard work so far, there ain't many lightweight react players out there! |
See cookpete/react-player#1428 for more information about why ReactPlayer shouldn't be rendered on the server. Ideally this is something that would be handled internally by the ReactPlayer component, but alas, we must take care of it ourselves. We should replace ReactPlayer with a more robust solution for our built-in Video component.
See cookpete/react-player#1428 for more information about why ReactPlayer shouldn't be rendered on the server. Ideally this is something that would be handled internally by the ReactPlayer component, but alas, we must take care of it ourselves. We should replace ReactPlayer with a more robust solution for our built-in Video component.
See cookpete/react-player#1428 for more information about why ReactPlayer shouldn't be rendered on the server. Ideally this is something that would be handled internally by the ReactPlayer component, but alas, we must take care of it ourselves. We should replace ReactPlayer with a more robust solution for our built-in Video component.
Seems like this should work in |
'use client'
import { useState, useEffect } from 'react'
export default function App() {
const [isClient, setIsClient] = useState(false)
useEffect(() => {
setIsClient(true)
}, [])
return {isClient ? <ReactPlayer /> : <p>The video player cannot render on the server side</p>}
} |
This worked for me in next 14. Thanks! |
Solution tweak that worked on this end: return 'use client' // if using app dir
import { useState, useEffect } from 'react'
export default function App() {
const [isClient, setIsClient] = useState(false)
useEffect(() => {
setIsClient(true)
}, [])
return {isClient ? <ReactPlayer /> : null}
} |
Yes this fixes the hydration but ref won't work and other callback props like onProgress |
we have released a canary version that should resolve this issue in many cases. |
Thanks Sir its Working Now. |
The hydration error remains when using the canary v3.0.0 and the React 19 Release Candidate 😢 Do we have to use ReactPlayer's |
Current Behavior
causing error: Hydration failed because the initial UI does not match what was rendered on the server.
Expected Behavior
should not cause error
Steps to Reproduce
The text was updated successfully, but these errors were encountered: