router location state is broken for imperative nagivation

[wKovacs64]

Description

2019-06-15: Original Problem Statement

Passing state through @reach/router's navigate function works in Gatsby v2.8.8 but not in v2.9.0 (nor v2.9.4, the latest version at this time). This broke in #14359.

Declarative links pass state correctly (e.g. <Link to="/page-2" state={{ success: true }}>).

2019-08-23: Update 1

The problem appears partially fixed as of Gatsby v2.13.2 (b8e2adc6, specifically) for development mode (gatsby develop) but is still broken in production (gatsby build output). Also, instead of null, location.state is now undefined.

Steps to reproduce

Imperatively navigate to another page. The location.state prop will be undefined in the destination page component.

Reproduction:
https://github.com/wKovacs64/gatsby-location-state-test

Expected result

props.location.state should be populated.

Actual result

props.location.state is undefined.

Environment

  System:
    OS: Windows 10
    CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  Binaries:
    Yarn: 1.17.3 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.9.0 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.15 - /c/Users/Justin/.windows-build-tools/python27/python
  Browsers:
    Edge: 44.18362.267.0
  npmPackages:
    gatsby: 2.13.80 => 2.13.80 
    gatsby-image: ^2.2.13 => 2.2.13 
    gatsby-plugin-manifest: ^2.2.9 => 2.2.9 
    gatsby-plugin-offline: ^2.2.10 => 2.2.10 
    gatsby-plugin-react-helmet: ^3.1.5 => 3.1.5 
    gatsby-plugin-sharp: ^2.2.17 => 2.2.17 
    gatsby-source-filesystem: ^2.1.16 => 2.1.16 
    gatsby-transformer-sharp: ^2.2.11 => 2.2.11 

[valse]

I saw that if you set location state from a "new" page (or you do a page refresh before) the destination value is null... If you navigate other routes and then return to the initial page (where you set the location state), the state working properly.

[wKovacs64]

This broke in #14359, for what it's worth.

[wKovacs64]

Any luck with this, @sidharthachatterjee? I tried to take a look but those changes are a bit intimidating. Maybe @Moocar would know what's up?

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[wKovacs64]

Not stale...

[bernharduw]

Having the same issue (in gatsby 2.13.56), I could work around it by using history.state if location.state is not set. You have to do a bit of a dance to not run into build errors (history is only available in the browser):

  const state =
    // eslint-disable-next-line no-restricted-globals
    location.state || (typeof history === 'object' && history.state);

[sbardian]

This appears to be fixed in the latest release. . .

[wKovacs64]

gatsby@2.13.2 (b8e2adc, specifically) seems to have fixed it for development mode (gatsby develop) but not production (serving the result of gatsby build). I'll update the reproduction repo shortly. Edit: updated the description and modified the reproduction repo to test both dev and production.

[wKovacs64]

@pieh did you do something in b8e2adc to intentionally resolve location state in development mode, or was that a happy coincidence?

[wKovacs64]

Well, this seems to have been resolved somewhere along the way. It's working again in gatsby@2.17.10. Closing, I guess.

[mimoid-prog]

Doesn't work in Gatsby version: 2.19.28. The value of location.state is null

[louishugens]

Same issue here

[yannicklaclau]

not working in 2.20.24

[pieh]

Hey folks - can you confirm that reproduction https://github.com/wKovacs64/gatsby-location-state-test is still relevant? (after updating to latest gatsby?). I will need something to work with to confirm and potentially fix

[wKovacs64]

I'm unable to reproduce it in gatsby@2.19.28 (project won't even build, due to an unrelated error) nor gatsby@2.20.24 (everything works fine). Updated my reproduction accordingly.

Maybe people are experiencing a similar but different issue (?), in which case a fresh reproduction would be needed.

[yannicklaclau]

you're right @wKovacs64. I also ran your test on 2.20.24 and it works fine. going to check what's different on my end and report back...

[yannicklaclau]

Figured it out.

My setup includes:

• client-side routes
• authentication

I'm using a pattern similar to this: https://www.gatsbyjs.org/docs/client-only-routes-and-user-authentication.

The problem was that the state was being passed to the router, and then rendered in a PrivateRoute component, which in turn failed to pass on down the location props to the component it was itself rendering after the authentication/authorization check.

Thanks for the previous tips/help on this thread!

[vyk1]

Had to pass state params via Gatsby Link.
On development, it worked fine but when on build it threw this error.
After digging a little bit, (https://www.gatsbyjs.org/docs/location-data-from-props/#example-of-providing-state-to-a-link-component) the solution was to set a default values: e.g.:
`
const Details= ({ location }) => {
const { state = {} } = location
const { project } = state
if (!project) {
return

Details Page

}
return (//... )

`

[ziyafenn]

Is there any fix for that? On gatsby build it's throwing error WebpackError: TypeError: Cannot read property 'platform' of undefined where platform is location.state.platform,
Tried solution from @vyk1 , didn't help.

Gatsby 2.23.3

[louishugens]

I think you will find the variable in window.history.state, hope it helps. Best Regards Hugens LOUIS (+509)-47007622

…

On Tue, Sep 15, 2020 at 5:02 PM Ziya Fenn ***@***.***> wrote: Is there any fix for that? On *gatsby build* it's throwing error *WebpackError: TypeError: Cannot read property 'platform' of undefined* where platform is location.state.platform, Tried solution from @vyk1 <https://github.com/vyk1> , didn't help. Gatsby 2.23.3 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEVNJKEXG5G6KZP6P6FQODSF7I6VANCNFSM4HYQJUHA> .