Closed matdehaast closed 5 years ago
Hi Matthew, thanks for coming up with this suggestion!
There are indeed a couple of places wher window
& document
is being used. Mainly window.getComputedStyle
, window.addEventListener
, window.removeEventListener
, window.innerHeight
and window.innerWidth
.
To be honest I haven't tried to render it completely SSR (ie. Next.js). The docs are written in Gatsby.js, and a while back I had some window
-issues with another Gatsby-project when I tried to build it. But this project (docs with react-laag) succeeded right away, without giving an error about an undefined `window. That's why I thought it would be SSR-compatble, but maybe that's a bit premature.
Anyway, it is certainly my intention to support SSR. I will do some research on SSR and check in a more solid way if it's indeed fully compatible. If you have any recommendations, please let me know.
I've added a little test (ssr-test.js
) to check whether ReactDOMServer.renderToString
renders succesfully. After some small adjustments it seems to be working fine. I did get some warnings about using useLayoutEffect
server-side, but decided to work around it by conditionally falling back to useEffect
when typeof window === "undefined"
.
I still need to check if the components gets hydrated properly. Will check asap ;)
Ok, I did some manual testing, and the component seems to hydrate properly on the frontend-side :). Hard to test this in a automated way though, since React is showing warnings in the console, instead of throwing an error. Any advice on this?
Seems what you did is the correct way to handle it. Tippy-react basically do the same with the fallback
Currently the library requires
window.
.Maybe look for a way to check if the component is being rendered in the browser before doing that to support SSR