gatsby: Window is not defined

That worked! Thx.

Tip: put typeof window !== 'undefined' && window.whaterver-you-need to solve this.

Yeah, during development, react components are only run in the browser where window is defined. When building, Gatsby renders these components on the server where window is not defined. Generally with React the solution to this is only access window in componentDidMount or to check that window exists before accessing it. For third party libraries that don’t do this, what you’ve done looks great.

I’m not really sure why is this issue closed? This issue, in fact, is probably the most critical one when Gatsby is concerned and the entire philosophy of it should be changed and fixed.

It’s really bad that browser and SSR logic are coupled. Not to mention the fact that you run one version of the code in development and divergence of it in production. This is really bad. Why would you make such builds? The only difference between those two should be enabled debugging functionalities in development and e.g. source maps or whatever. This really makes it difficult and engaging to use Gatsby.

In my opinion, you should reopen this and prioritize this issue. This issue makes people literally give up on thousands of modules out there that depend on window and not all of them can be imported in componentDidMount e.g. HOC like modules etc.

@gregorskii

const windowGlobal = typeof window !== 'undefined' && window

then, windowGlobal.localStorage

Yeah, during development, react components are only run in the browser where window is defined. When building, Gatsby renders these components on the server where window is not defined. Generally with React the solution to this is only access window in componentDidMount or to check that window exists before accessing it. For third party libraries that don’t do this, what you’ve done looks great.

It would be super helpful to surface this early / prominently. I’m trying to build for the first time, and there are many issues I have to fix now, since I was unaware that this would become an issue. It’s particularly stressful as I urgently need to deploy this; I’m submitting a proposal for something, and I need the site to be online.

I’m only looking to deploy to Github Pages (for now, at least), and so I don’t need SSR. Is there a way to just build for clients?

@CallMeLaNN suggestion worked for me. With UIkit, I get:

WebpackError: Element is not defined

Putting the imports inside componentDidMount worked.

 componentDidMount() {
    try {
      this.UIkit = require("uikit/dist/js/uikit");
      this.Icons = require("uikit/dist/js/uikit-icons");
      this.UIkit.use(this.Icons);
    } catch (e) {
      console.error(e);
    }
  }

With all due respect, what you wrote makes no sense. Why would someone who is building a “browser-only” library check if window object exists? Can you name or point to a single library on the entire NPM registry that does this? Or you are saying that all those libraries that people wrote are written wrongly?

Or people should consider that there is a framework called “Gatsby” that needs this? One should be able to use Gatsby on one or another end and those ends should be ENTIRELY decoupled. This is the only point, really. Nothing philosophical about it.

so Can I make it run build in browser ? I don’t need SSR.

Ya this worked, but I had to mock local storage using https://www.npmjs.com/package/localstorage-memory:

const windowGlobal = typeof window !== 'undefined' && window;
const localAdapter = windowGlobal ?
  adapter(windowGlobal.localStorage) :
  adapter(memoryStorage)
;

Using https://www.npmjs.com/package/redux-localstorage.

@joshwcomeau completely agree with you, also I don’t think is a good idea to run dev in browser only and build in node.js. The difference is so big, and as in DEV and PROD environment you want to make the environments as similar as possible, I think gatsby should do the same, run both dev and build in an environment that is as similar as possible.

By design Gatsby is a static site generator. Most of the work it does to accomplish that is done outside of the browser at compile time. It’s not only a “client” or “browser” tool.

Server side rendering is by definition done on the “server” side, where “window” is not a thing.

Gatsby’s compiling is done with Webpack, webpack by default does not wire up a window variable. From my experience there is not only one way to adapt client libraries to work under webpack. This leads to the Gatsby config itself not capable of providing a simple one shot solution to fix all libraries that depend on “window”.

FWIW I think it makes sense to separate the part so of the tool to discuss which part of it is impeding what you wish to do.

the error is disappeared when using componetDidMount

only access window in componentDidMount

Gist for third party js.

// index.js
import React from "react";
import Link from "gatsby-link";

// import "uikit/dist/js/uikit";
// Third party JS access `window` without
// `typeof window !== "undefined"` check

class Template extends React.Component {
  componentDidMount() {
    import("uikit/dist/js/uikit")
      .then((uikit) => {
        this.uikit = uikit;
      })
      .catch((error) => console.error(error));
  }
  render() {
    // ...
  }
}

// ...

@KyleAMathews I can’t seem to get componentDidMount to fire in html.js or _template.jsx using gatsby develop, maybe it’s not supposed to, or I’m doing something wrong?

@wmlutz something like the below code block. react is loaded after the initial static bundle is received. So by the time the user reaches _handleSubmit window will exist.

Please note if react toasts calls window on import then you might still experience the error.

_handleSubmit = async (e) => {
    e.preventDefault();
    let {email} = this.state;

    const response = await addToMailchimp(email)
    if (response.result === "success") {
      if (window) ToastsStore.success("Successfully joined the list")
    }
    if (response.result === "error") {
      if (window) ToastsStore.error("There was an error: " + result.msg)
    }
  }

It seems like with Gatsby v2, you need to choose between es6 and commonjs imports, you won’t be able to mix them up anymore for reasons having to do with webpack 4.

That being the case, and assuming you’re already using es6 imports, it would seem like @jfaeldon’s solution is the one to use here and @hitchcott’s won’t work anymore.

Can someone confirm that?