v6 documentation very hard to follow

Thanks for putting all this together, it helps a lot. However, upgrading from v5 to v6, I feel like the experience of using the library has gotten worse. And the documentation doesn’t help in this regard. Here are some comments for the current documentation:

• even tough v6 doesn’t pass isServer anymore, I find it in most of the examples
• async actions are not awaited (https://github.com/kirill-konshin/next-redux-wrapper#async-actions)
• could use better examples for serialization and deserialization. json-immutable hasn’t been updated for 3 years and doesn’t have TS support. For immutable when using state.toJS() this means state has to have the toJS() method, how can this be used for a very complex redux state?
• Redux Persist example still uses initialState (https://github.com/kirill-konshin/next-redux-wrapper#usage-with-redux-persist)
• there is nothing mentioned about getStaticPaths
• what’s the proper way of handling the HYDRATE action?
  1. in this example it only handles page and checks if it ends with an ‘X’.
  2. in this example every reducer is checked if they have initialData and deleted from action payload, does this mean I have to go through each reducer and check against their initialData?
  3. what are CLIENT_SERVER and CLIENT_ACTION from here?
  4. when using combineReducers, how should this action be handled? in a separate reducer or in each of the other reducers?

[kirill-konshin]

• even tough v6 doesn’t pass isServer anymore, I find it in most of the examples
  • done
• async actions are not awaited (https://github.com/kirill-konshin/next-redux-wrapper#async-actions)
  • done
• could use better examples for serialization and deserialization. json-immutable hasn’t been updated for 3 years and doesn’t have TS support. For immutable when using state.toJS() this means state has to have the toJS() method, how can this be used for a very complex redux state?
  • it’s up to application. entire state can be immutable, then top level object will have this method
• Redux Persist example still uses initialState (https://github.com/kirill-konshin/next-redux-wrapper#usage-with-redux-persist)
  • done
• there is nothing mentioned about getStaticPaths
  • it does not affect what this lib is doing
• what’s the proper way of handling the HYDRATE action?
  • in this example it only handles page and checks if it ends with an ‘X’.
    • it’s up to application how it wants to handle it
  • in this example every reducer is checked if they have initialData and deleted from action payload, does this mean I have to go through each reducer and check against their initialData?
    • you can either check at every reducer or at one top level handeler
  • what are CLIENT_SERVER and CLIENT_ACTION from here?
    • fixed, it was a typo
  • when using combineReducers, how should this action be handled? in a separate reducer or in each of the other reducers?
    • up to you, whatever feels more comfortable for the app
• Is there a way I can update documentation to remind people that sagas will opt users out of automatic static exports?
  • fixed
• Lastly, is there a way to update documentation to provide a means for people to leverage this library + redux-sagas without opting out of automatic static exports (without stopping any sagas in getInitialProps inside _app.
  • If you find a way — let us know. In general, sagas must be awaited, and the best place for that is _app.

[kirill-konshin]

They still do await for the saga to end https://github.com/vercel/next.js/blob/canary/examples/with-redux-saga/pages/index.js#L23 but not on all pages. This is also an option, you just need to make sure that all pages (that need it) will actually do it. If you miss it on one of pages you’ll end up with inconsistent sate being sent to client. So waiting in _app is safer 😉 but it has own drawbacks.