navigate not working in gatsby build

[kevinmichaelchen]

Description

I have a page, /trial, that I want to ensure is always visited with a route param. In my constructor, I check this.props.location.search, and if it's falsy (empty) I want to navigate to /trial/?product=foobar.

Here's my code

import React from 'react'
import { navigate } from 'gatsby'

class Foobar extends React.Component {
  constructor(props) {
    super(props)
    this.redirectIfNecessary()
  }

  redirectIfNecessary() {
    // Make prospect the default product
    const { location } = this.props
    const { search } = location
    if (!search) {
      navigate('/trial/?product=foobar', {
        state: {
          product: 'foobar',
        },
      })
    }
  }

  render() {
    return <div>Hello, world</div>
  }
}

Expectations vs Reality

This works fine during dev time, but when I run gatsby build I get

error Building static HTML for pages failed

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND

  186 | 
  187 | var navigate = function navigate(to, options) {
> 188 |   window.___navigate(withPrefix(to), options);
      | ^
  189 | };
  190 | 
  191 | exports.navigate = navigate;


  WebpackError: ReferenceError: window is not defined

Environment

gatsby info --clipboard

  System:
    OS: macOS 10.14.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.3.0 - /usr/local/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 70.0.3538.110
    Firefox: 63.0.3
    Safari: 12.0.1
  npmPackages:
    gatsby: ^2.0.64 => 2.0.64 
    gatsby-image: ^2.0.20 => 2.0.22 
    gatsby-plugin-manifest: ^2.0.10 => 2.0.11 
    gatsby-plugin-offline: ^2.0.19 => 2.0.19 
    gatsby-plugin-react-helmet: ^3.0.4 => 3.0.4 
    gatsby-plugin-react-svg: ^2.0.0 => 2.0.0 
    gatsby-plugin-sass: ^2.0.7 => 2.0.7 
    gatsby-plugin-sharp: ^2.0.15 => 2.0.15 
    gatsby-source-filesystem: ^2.0.11 => 2.0.11 
    gatsby-transformer-sharp: ^2.1.8 => 2.1.9 
  npmGlobalPackages:
    gatsby-cli: 2.4.6

[sidharthachatterjee]

Hey @kevinmichaelchen

Webpack is failing to build this because window is only available in the browser and not during build time.

You can fix this by moving the redirectIfNecessary call from the constructor to componentDidMount instead. That way it will only run on the client side and not during build time.

You can also do this declaratively in your render function by including the Redirect component from reach router

I'm closing this for now since this issue isn't specific to Gatsby but feel free to reopen if there's anything else.

[mpaccione]

User browser monads repo as a quick fix for this!

https://www.npmjs.com/package/browser-monads

[0x1ad2]

Try wrapping the modules that want to access window in the following code.

    if (typeof window !== `undefined`) {
          navigate(`/route/to/your/page`);
    }

IMO it's a bit of a nasty hack and it would be better if it's included in the navigate module of Gatsby.

https://www.gatsbyjs.com/docs/debugging-html-builds/

[ryancrunchi]

I think this issue should be reopened for several reasons :

• as @0x1ad2 stated : if (typeof window !== 'undefined') is hacky
• <Redirect> component from reach router module does not have state and replace parameters that navigate offers : navigate(path, {state: something, replace: true})
• navigate is part of gatsby and SSR is intrinsic to gatsby. I think it is not consistent to provide a navigate function in a framework that uses SSR and will crash the build if you use it. IMHO navigate should check itself for window.
  Maybe adding a warning, instead of just crashing is a good compromise
• developers should not think about if their piece of code will be SSR or not when they use gatsby. The SSR/not SSR thinking should be hidden inside gatsby

[iamacoderguy]

I think this issue should be reopened for several reasons :

• as @0x1ad2 stated : if (typeof window !== 'undefined') is hacky
• <Redirect> component from reach router module does not have state and replace parameters that navigate offers : navigate(path, {state: something, replace: true})
• navigate is part of gatsby and SSR is intrinsic to gatsby. I think it is not consistent to provide a navigate function in a framework that uses SSR and will crash the build if you use it. IMHO navigate should check itself for window.
  Maybe adding a warning, instead of just crashing is a good compromise
• developers should not think about if their piece of code will be SSR or not when they use gatsby. The SSR/not SSR thinking should be hidden inside gatsby

Any updates for this issue?

[andrewminton]

After spending a day looking at this, I'm confused as to whether this error is generated by my actual code of the build tools themselves. As a framework for static sites, this is fundamental to the production side and to this date is unresolved imho. Agree with the above. I've inherited someone else' code to make text changes.... and have rebuilt this from scratch with a fresh build only to come to the same conclusion when running gatsby build. Please can we provide clearer guidelines as to where the culprit is if it's not in the page code. Is navigation.js generated by the build tools? if so, it'll be overwritten when tackling this again on next dev sprint surely?

[alpha93]

These are the reasons I find working with Gatsby so frustrating. The whole framework is riddled with such hard to catch bugs. Took me quite a while to figure out that there was nothing wrong with my code and it was Gatsby itself that was using the window object internally. Everything will be honky dory in the development mode but as soon as you try to build it, a bunch of cryptic errors are dumped on you. This bug was posted back in 2018 and they still havent fixed it. How hard would it have been for the Gatsby team to put the if-check fix in the code for navigate()?