Window is not defined

[IstoraMandiri]

I'm trying to use a semantic-ui import along with my components.

Works fine in development but if I try to gatsby build, I get Error: ReferenceError: window is not defined.

I'm doing this:

import $ from 'jquery';
$.fn.transition = require('semantic-ui-transition');
$.fn.dropdown = require('semantic-ui-dropdown');

Is there any workaround?

Edit: Managed to get it working with:

try {
  $.fn.sidebar = require('semantic-ui-sidebar');
} catch (e) {
  console.log(e)
}

[KyleAMathews]

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.

[AndersDJohnson]

@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?

[Maxhodges]

@hitchcott can you share a bit more about your build? I just installed semantic-ui into a gatsby project but my CSS isn't working. Not sure how to get the CSS loaded in my page. React is suppose the in-line styles right, but how does it know about them? Also I suppose I should configure webpack to do the LESS build instead of gulp. Did you just install the webpack-lessloader?

[kylegach]

@Maxhodges — It’s Webpack, not React, that “knows” about your styles. Webpack knows because you import or require the compiled file(s) somewhere in the JS files that get bundled.

For example, I import my main styles.css in the _template.js file, so when Webpack builds the bundle, it includes those styles – inline when in development mode; external referenced file when in production (look at cssLink here for an example).

There’s no need for an additional LESS loader, as Gatsby already includes one in its default Webpack config.

[cybermill]

for those of you that followed the directions on the Gatsby GitHub page for installing the docs-site...
import { colors } from 'utils/colors'
is the trouble maker and after commenting out this and ${colors.bg} the site developed nicely.

[Tseberechts]

Would it be possible to show a better error message when this happens? I have no idea where to find the error.

Failed at generating HTML

/home/projects/snipsonian/node_modules/gatsby/dist/bin/cli.js:42
      throw err;
      ^
Error: ReferenceError: window is not defined
    at Object.defineProperty.value (render-page.js:44529:79)
    at __webpack_require__ (render-page.js:30:30)
    at Object.exports.__esModule (render-page.js:42560:24)
    at __webpack_require__ (render-page.js:30:30)
    at Object.defineProperty.value (render-page.js:42533:51)
    at __webpack_require__ (render-page.js:30:30)
    at Object.<anonymous> (render-page.js:80:19)
    at __webpack_require__ (render-page.js:30:30)
    at Object.assign.i (render-page.js:50:18)
    at render-page.js:53:10
error Command failed with exit code 1.

[KyleAMathews]

That's a really good idea! Currently pressing hard on 1.0 so won't get this soon but for now, just open up public/render-page.js to the the line number indicated there (44529) and see what code is causing trouble.

…

On Wed, May 17, 2017 at 11:45 AM Thomas Seberechts ***@***.***> wrote: Would it be possible to show a better error message when this happens? I have no idea where to find the error. Failed at generating HTML /home/projects/snipsonian/node_modules/gatsby/dist/bin/cli.js:42 throw err; ^ Error: ReferenceError: window is not defined at Object.defineProperty.value (render-page.js:44529:79) at __webpack_require__ (render-page.js:30:30) at Object.exports.__esModule (render-page.js:42560:24) at __webpack_require__ (render-page.js:30:30) at Object.defineProperty.value (render-page.js:42533:51) at __webpack_require__ (render-page.js:30:30) at Object.<anonymous> (render-page.js:80:19) at __webpack_require__ (render-page.js:30:30) at Object.assign.i (render-page.js:50:18) at render-page.js:53:10 error Command failed with exit code 1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#309 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEVh6E9bZyyi0iX-Q7Q92VTvEb1DZbmks5r6sHGgaJpZM4Isiea> .

[Tseberechts]

That worked! Thx.

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

[mohhasbias]

the error is disappeared when using componetDidMount

[gregorskii]

I have a similar issue, but I am using localStorage to persist some of my redux state on the browser. How do I bypass this issue if I cannot use window.localStorage in the store.js file?

😢

Thanks!

[heldrida]

@gregorskii

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

then, windowGlobal.localStorage

[gregorskii]

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.

[CallMeLaNN]

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() {
    // ...
  }
}

// ...

[altcoder]

@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);
    }
  }

[joshwcomeau]

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?

[justintemps]

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?

[hackhat]

@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.

[lili21]

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

[PHILATSHAKA]

Hi,
I am experiencing the same issue here, Coverflow works fine for gatsby develop but for build it throws an error:
WebpackError: window is not defined

     - react-coverflow.js:1 Object.<anonymous>
       ~/react-coverflow/dist/react-coverflow.js:1:330
     
     - main.js:1 Object.<anonymous>
       ~/react-coverflow/main.js:1:1

import Coverflow from 'react-coverflow';
import { StyleRoot } from 'radium'

class Team extends React.Component {

render(){
return(

<Coverflow
displayQuantityOfSide={2}
navigation
infiniteScroll
enableHeading
active={0}
media={{
'@media (max-width: 720px)': {
width: '100%',
height: '200px'
},
'@media (min-width: 720px)': {
width: '100%',
height: '400px',
}
}}
>

  </Coverflow>
</StyleRoot>
)

}
}

export default Team;

[gregorskii]

While I don’t disagree this is a pain point. One could argue those libraries written with logic around the window variable are not suited for SSR use. Those libraries themselves should check if window is defined and work in SSR mode.

No other comments to the deeper point you are making, that’s a philosophical discussion better suited to the maintainers.

[agjs]

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.

[gregorskii]

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.

[rein96]