react-player: Next.JS / React 18 - Hydration Error

I agree that ReactPlayer should be SSR-friendly out of the box, @cookpete what do you think?

For now, until that happens, another workaround is to lazy-load the player using Next.js dynamic imports, as mentioned by @inderrr in this comment:

import dynamic from 'next/dynamic';

const ReactPlayer = dynamic(() => import('react-player/lazy'), { ssr: false });

Have you tried this?

It’s basically checking the window.

const Component: React.FC<SomeProps> = ({url}) =>{
  const [hasWindow, setHasWindow] = useState(false);
  useEffect(() => {
    if (typeof window !== "undefined") {
      setHasWindow(true);
    }
  }, []);
  return (
    <>
      {hasWindow && <ReactPlayer url={url} />}
    </>
  )

For temporary solution you can downgrade react to 17.0.2 for example

Have you tried this?

It’s basically checking the window.

const Component: React.FC<SomeProps> = ({url}) =>{
  const [hasWindow, setHasWindow] = useState(false);
  useEffect(() => {
    if (typeof window !== "undefined") {
      setHasWindow(true);
    }
  }, []);
  return (
    <>
      {hasWindow && <ReactPlayer url={url} />}
    </>
  )

I’ve tried this and of course it works! but this means rendering the react-player component on the client side so I need to render another thing ( like an image) on the server side. I wish the react-player would handle the SSR by itself

@panzacoder I appreciate the thought you’ve put into this. Unfortunately I think we’re at the point where a proper solution is simply not worth the time and effort it would take – you might as well rewrite the library from scratch. I have been gradually rewriting this with typescript, hooks, storybook, etc, but getting time to work on it is tricky.

There is no way to avoid using window as the whole point of the component is to load third party scripts to play a given url. There is nothing we can really render during SSR because we just don’t know what markup will be rendered by these scripts. I guess we could use noembed to fetch a thumbnail and render that, but I don’t know how intrusive that would be to the codebase. At this point I would much rather keep things simple considering how complex this library has become to satisfy such a wide range of developers/platforms.

Some ideas:

• If the problem circles around lazy and Suspense should we just release v3 with it removed completely, and just let the developer decide which players to include and how to lazy load them? The majority of users are only ever using one player, and more and more users are using a platform that has lazy loading built in, like next/dynamic.
• Could we somehow wrap react-player in a way that supports Next.js? So the changes in this library are minimal and we just push Next.js users towards react-player-next (or whatever we call it).

we have released a canary version that should resolve this issue in many cases. Suspense is enabled and more importantly the current player’s root element is rendered on the server. please let me know if any issues arise. https://www.npmjs.com/package/react-player/v/3.0.0-canary.0

Solution in the Next.js doc

'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>}
}

from https://github.com/cookpete/react-player/issues/1428, if above doesn’t work, try return {isClient ? <ReactPlayer /> : null}

Solution in the Next.js doc

'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>}
}

I agree that ReactPlayer should be SSR-friendly out of the box, @cookpete what do you think?

For now, until that happens, another workaround is to lazy-load the player using Next.js dynamic imports, as mentioned by @inderrr in this comment:

import dynamic from 'next/dynamic';

const ReactPlayer = dynamic(() => import('react-player/lazy'), { ssr: false });

works for me. thanks ! 😉

I agree that ReactPlayer should be SSR-friendly out of the box, @cookpete what do you think?

For now, until that happens, another workaround is to lazy-load the player using Next.js dynamic imports, as mentioned by @inderrr in this comment:

import dynamic from 'next/dynamic';

const ReactPlayer = dynamic(() => import('react-player/lazy'), { ssr: false });

For anything not Next… im presuming using loadable components would work a treat.

The versions of the react and react-dom packages are unrelated here, SSR support is more about things like browser globals being undefined or rendering something different on client and server, which @minamobahi mentioned in the comment above:

the window is used in the component’s rendering

If you want to submit a PR, then probably best would be to:

1. Read a bit into the errors that can come from window being used in React components, such as the common ReferenceError: window is not defined error:

https://dev.to/vvo/how-to-solve-window-is-not-defined-errors-in-react-and-next-js-5f97

1. Come up with a strategy for how react-player should behave when browser globals such as window are not available. It seems like there is some work being done around window detection already:

https://github.com/cookpete/react-player/blob/9775bb755af195e6f7e8bacfed436fcefb135354/src/ReactPlayer.js?rgh-link-date=2022-07-09T13%3A01%3A03Z#L12-L18

But react-player is not rendering the same thing on client and server (which is where the Next.js error comes from).

Ok you were definitely on to something with this and it took me some digging but I think I figured out why this is so incompatible with SSR.

There was one bit of magic that I noticed in the Readme that struck me as odd but I couldn’t figure out why. For Youtube embeds, there is an example of the actual url of the YT video, not the embed url or the id of the video. In other implementations I’ve seen or done for YT embeds, typically there is some more configuration needed around stripping the embed id or specifying the poster image (for a “light” version) but this handled it.

In the line you references, we are returning null on the server side, since Suspense doesn’t work server side pre- React 18. I think now we could probably set a flag or do a check for the React version to enable Suspense/lazy. But that just allows the code to attempt to run in SSR.

The next piece I’ve seen is the call to window in the file Preview.js, and this is where the magic with the youtube URL happens:

https://github.com/cookpete/react-player/blob/662082a2f2edc863e8ca9cefdd7a3c88ad49ea0d/src/Preview.js#L42

Basically, if the url is for youtube and a poster image isn’t provided, we are fetching a YT endpoint that provides some meta about the video, including a poster image uri and html for an iframe.

I’m going to make an attempt to fix this in a universal way in a fork I made, but one big thought is on my mind: Should we be doing it this way?

I think there might be a solution that is right enough for all React environments, but ultimately if this component is handling a certain level of data fetching, it needs to have integrations with specific frameworks that can handle this in the way that it intends to do so. Since SSR and SSG is becoming the norm for react, my thoughts on a refactor would be some or all of the following:

• Decouple optimizations like this throughout the repo that work to gather data not provided by the user
• Provide those data fetching functions as helpers available to get the data in the way that the given framework suggests
• Potentially provide examples including framework-specific implementations of the component
• Provide a React 18 implementation that doesn’t opt-out of Suspense in SSR

If I can find time, I will try to experiment with some of these concepts, but would be interested in feedback from @cookpete on these thoughts also.

Its work for me

To dynamically load a component on the client side, you can use the ssr option to disable server-rendering. This is useful if an external dependency or component relies on browser APIs like window.

import dynamic from ‘next/dynamic’

const DynamicHeader = dynamic(() => import(‘…/components/header’), { ssr: false, })

Thank you, just what I was looking for 👍

I agree that ReactPlayer should be SSR-friendly out of the box, @cookpete what do you think?

Sounds great. I just don’t have the time or knowledge to implement, test and document it.