Rule proposal: ssr-friendly

[alexreardon]

In order to be SSR compliant, you can only access browser globals such as window, document and so on, inside of componentDidMount, componentDidUpdate and componentWillUnmount

• Diagram source
• React lifecycles documentation

A rule could be created to avoid the use of unguarded browser globals in other lifecycle methods.

Example of a guard:

if (typeof window !== 'undefined') {
 // I can use browser globals in here
}

Use of browser globals are allowed when:

• used in a guard
• used in componentDidMount, componentDidUpdate and componentWillUnmount
• used in useEffect or useLayoutEffect
• used in an event handler

[ljharb]

This sounds like an excellent rule, and I'm very much in favor of it. A PR is appreciated!

(Note, however, that it's also acceptable to access these things in event handlers - any component method or function that is only referenced by passing it in as a prop to an element, and never directly invoked)

[alexreardon]

@ljharb I updated the description

[alexreardon]

I have not had experience writing eslint plugins before. I see the first step as fairly straight forward: checking if browser globals are called inside of componentDidMount, componentDidUpdate or componentWillUnmount.

I am not sure how to check if this is done inside of a guard such as

if (typeof window !== 'undefined') {
 // I can use browser globals in here
}

@ljharb you have any thoughts on how I could check to see if the usage of the code is guarded?

[ljharb]

Even if guarded, if initial render behavior differs between client and server, that’s a bug - so there shouldn’t be any use outside of those methods, even guarded.

[alexreardon]

Sometimes there might be - such as when a component mounts into a portal.

[alexreardon]

So on the server it might just return null, whereas in the browser it might return ReactDOM.createPortal(children, el). I have seen this pattern around

[alexreardon]

But I could buy that these are edge cases and a consumer could add a //eslint-ignore-next-line react/ssr-friendly

[ljharb]

That would cause a render mismatch, i believe - if you want to conditionally render into a portal, you’d need to do that using state set in componentDidMount.

[alexreardon]

Sounds good to me

[sidharthachatterjee]

Watching this closely as this would be super useful for Gatsby

[alexreardon]

I hope to take more of a look at this soon!