Usage with redux-persist

[chapati23]

How would I use this with redux-persist?

  // routesMap.js
  …
  WALLET_SELECTOR: {
    path: '/wallet-selector/:currency',
    thunk: (dispatch, getState) => {

       // I don't seem to have the rehydrated state here.
       // Is it somehow possible to 'await' rehydration here?
      const { steps } = getState()

      canContinueIf(steps.currencySelected, dispatch)
    }
  },
  …

[faceyspacey]

I don't currently know, but I need to find out. Can you try applying it directly to the demo in isolation and see if there are any problems:

https://github.com/faceyspacey/redux-first-router-demo

Probably the best way to figure out how redux-persist plays with SSR + rehydration.

[ganlub]

I implemented it along with RFR and everything works as expected. There will be actions being fired before the re-hydration happens so you will need to rather use this or this.

@faceyspacey it would be nice to have it on the demo!

[chapati23]

Here's how I solved it. Maybe it's helpful to somebody. Had to use the cookies adapter for redux-persist so I had the state I'm interested in on the server already. Not sure if it's really the best solution but it works for me :)

// src/routesMap.js
// …
    thunk: (dispatch, getState) => {
      const { steps } = getState() // up to you to handle via standard redux techniques
      canContinueIf(steps.someStepCompleted, dispatch)
    }
// …
const canContinueIf = (stepCompleted, dispatch) => {
  if (!stepCompleted) {
    const action = redirect({ type: 'SOME_DEFAULT_ROUTE' })
    dispatch(action)
  }
}

// server/configureStore.js
export default async (req, res) => {
  // …
  const cookies = req.cookies
  const parsedCookies = {}
  Object.entries(cookies).forEach(([key, value]) => {
    const decodedKey = decodeURIComponent(key)
    const keyWithoutReduxPersistPrefix = decodedKey.replace(/reduxPersist:/, '')
    if (key !== 'reduxPersistIndex') {
      parsedCookies[keyWithoutReduxPersistPrefix] = JSON.parse(value)
    }
  })
  const preLoadedState = { ...parsedCookies } // onBeforeChange will authenticate using this
  // …
}

// src/configureStore.js
export default (history, preLoadedState) => {
  // …
  const store = createStore(rootReducer, preLoadedState, enhancers)

  if (!isServer) {
    persistStore(store, {
      blacklist: ['location', 'page'],
      storage: new CookieStorage()
    })
  }
// …
}

// server/index.js
import cookieParser from 'cookie-parser'
// …
app.use(cookieParser())
// …

[faceyspacey]

excellent! ...i think it's likely the only way--how else are we going to guarantee the client state becomes redux state on the server? Headers doesn't work, since direct visits can't contain headers like ajax requests in SPAs. Cookies is the only option.

Very well done. I'll probably even document this approach at some point. If you're up to, feel free to make a pr with a new .md in the docs folder. Feel free to give yourself credit with a link, etc.

[faceyspacey]

...perhaps a more formal solution/package would let you blacklist keys so huge amounts of domain state isn't stored in cookies (which would slow down requests). We only want UI state after all.

Or perhaps there is a reason to have domain state--black/whitelist options would let the user determine what should be stored in cookies.

[faceyspacey]

@ganlub so the idea is that to buffer and delay actions that enhancers like the one from RFR might trigger, so that when route thunks are called, they have everything they need from redux-persist as well? Very pro!

[chapati23]

@faceyspacey created a little doc locally. tried creating a feature branch, commiting with npm run cm and then pushing but don't have permissions. what's the workflow?

[chapati23]

figured it out, here goes: #78

[faceyspacey]

excellent. was just writin.

[faceyspacey]

im just gonna close this, since we have the PR (doing a little cleanup)

[brownbl1]

I know you closed this, @faceyspacey, but I wanted to add a few more details that I've been teasing out over the past hour.

First, I liked the idea of using redux-action-buffer as @ganlub suggested so I went down that route. My idea was that I could add the action buffer middleware to queue up and fire all actions (including the initial location action) only after the persist/REHYDRATE action is fired. The catch though is I was trying this with the redux-persist@next package. The problem is that in the v5 rewrite of redux-persist, they also dispatch a persist/PERSIST action before the persist/REHYDRATE. It seems that persist/REHYDRATE isn't fired until persist/PERSIST is fired. See this issue for reference: rt2zz/redux-action-buffer#14

I've created a tentative pull request in redux-action-buffer to effectively whitelist certain actions (namely persist/PERSIST) which fixes this use case of redux-action-buffer.

Using this approach, if we set up our configureStore to look like this:

const middlewares = applyMiddleware(
	createActionBuffer(REHYDRATE, null, [PERSIST]),
	middleware,
	thunk,
	logger
)

I get the desired be behavior and my action sequence looks like:
persist/PERSIST
persist/REHYDRATE
HOME // redux-first-router action
INCIDENTS_FETCHED

Does that make sense and do you see any issues with this? I'm really only messing around with it in the browser (not native or server at this point). It's possible I've missed a bigger problem here but this seems to solve all of my issues with not having access to the persisted store in onBeforeChange or route thunks.

It should probably be stated clearly that I haven't yet had a chance to see how this should work with the universal suite you've been working on. My very limited use case is that I am making an ajax request to a lambda function which returns a jwt that I'd like to store in localStorage. I don't have a server at all at this point, and I'm not trying to store all of my app state in localStorage; just the user token/info.

Also, thanks for the great work on this router!

[faceyspacey]

Thanks for taking the time to do this analysis!

...so i havent had time to focus on redux-persist personally unfortunately. So that means I'm lacking in answers.

But I can say this: i dont really like the fact that now u gotta add createActionBuffer. It's just one more thing. It's the reverse steve-jobs "one more thing" where u dont get something u want in that "one more thing." A never ending set of negative "one more things" lol.

So to me that's usually a signal to dig my heals in at some point and take a holistic approach and see if we can do "better."

I still can barely wrap my head around what the buffer thing is doing since i havent tried it--I get it, it's delaying actions. But maybe there's a better way. Why can't we just get a damn callback or await on redux persist somehow. Maybe we can get a PR into the v5 that lets u do this. If this is a genuine problem, they should build in a solution to it, not provide 3rd party hacks via additional buffer middleware.

Feel free to let me know if I'm far off in my limited birds eye perspective.