fix(using-redux): create a fresh store for each SSR page

[cpboyd]

Description

As I'd mentioned in #10912, the current using-redux example creates a static store that persists across multiple SSR pages.

It seems that the expected behavior should likely be that each page's initial load is from a fresh store, in order to match the behavior of the browser rendering.

Related Issues

Related to #10912

[wardpeet]

Could you explain:

It seems that the expected behavior should likely be that each page's initial load is from a fresh store, in order to match the behavior of the browser rendering.

Creating a new store for each page is something you don't really want when gatsby re-hydrates your page as the redux store should be shared across pages.

[cpboyd]

@wardpeet Yes, the redux store should be shared across pages once the page has been loaded, but not for every initial rendering of every single page during gatsby build.

Currently, as mentioned in #10912, each page gets rendered retaining the prior state since the store is created static and thus retained between each initial rendering in the gatsby build process.

[cpboyd]

From #10912, based on the "using-redux" example from this repo:
https://github.com/cpboyd/gatsby-redux-bug

With gatsby develop, all pages initially display a 1 if they're the first page loaded.

However, gatsby build results in the following being rendered (before Javascript browser rendering takes over):

0. A
1. B
2. C
3. Home

Note: I'd initially tried using componentWillMount(), which apparently doesn't get called during SSR in React.

[cpboyd]

A few new remarks:
Redux's help indicates SSR should create a new store for each page, but the client is static:
https://redux.js.org/recipes/server-rendering#serverjs-1

As a result, maybe we should just go back to having separate functions for gatsby-browser.js (which would match the prior wrapWithProvider and gatsby-ssr.js which would create a new store for each rendered page.

Further, even placing redux state changes in the constructor() doesn't necessarily result in the state change being dispatched BEFORE rendering occurs.

Thus, it might be worth updating the example to show pages with differing initial states.

e.g., I'm currently using:

const getStateFor = (pathname)  => {
  if (!pathname) {
    return {};
  }
...<computation here>
  return {
    ...<computed values>
  }
}

const createStore = (pathname) => {
  const pathState = getStateFor(pathname);
  return reduxCreateStore(reducer,
    {
      ...initialState,
      ...pathState
    }, composeWithDevTools(applyMiddleware()));
}

[pieh]

the wrapRootElement is called just once in gatsby-browser (just before initial render), so this change is safe to do, but we could adjust comment there a bit, to make it clear that it will cause fresh store instance for each SSR page, but it will only be called once in browser

[cpboyd]

@pieh updated with your suggestion

[pieh]

Thanks @cpboyd!

[gatsbot]

Holy buckets, @cpboyd — we just merged your PR to Gatsby! 💪💜

Gatsby is built by awesome people like you. Let us say “thanks” in two ways:

1. We’d like to send you some Gatsby swag. As a token of our appreciation, you can go to the Gatsby Swag Store and log in with your GitHub account to get a coupon code good for one free piece of swag. (Currently we’ve got a couple t-shirts available, plus some socks that are really razzing our berries right now.)
2. We just invited you to join the Gatsby organization on GitHub. This will add you to our team of maintainers. Accept the invite by visiting https://github.com/orgs/gatsbyjs/invitation. By joining the team, you’ll be able to label issues, review pull requests, and merge approved pull requests.

If there’s anything we can do to help, please don’t hesitate to reach out to us: tweet at @gatsbyjs and we’ll come a-runnin’.

Thanks again!