Feature Request : Provide storage key in the rehydrate action

[ThibautMarechal]

Let's image we have this simple state that contains the columns definition of a table.

{
   columnSizes: { // It's should be stored in localstorage (same screen size) key = local
     A: 50,
     B: 150
   },
  columns: [A, B], // we want that information to be availaible cross broser (with a corresponding backend) key = server
  datas: [] // we do not saved this :)
}

We have have here 2 rehydration that will occured in the store.

I use saga that listen to some redux actions (including '@@rehydrate') to trigger a search based on the "columns" from the store.

The problem is that I cannot know when the action '@@rehydrate' is dispatched if the payload come from the key 'local' or 'server'.

It could be nice to have the stored key in the redux actions

Proposition

// before
{
  type: '@@REHYDRATE',
  payload: any
}
// after
{
  type: '@@REHYDRATE',
  payload: {
    key: string,
    savedState: any
  }
}

[adam-golab]

Hi @ThibautMarechal,

Thanks for suggesting that I see that this feature may be very helpful for similar use cases that you have. But I'm not sure if chaining the shape of an action object would be a good idea.

I have two ideas on how it can be implemented but firstly I'd like to discuss those with you.

First proposition: defining action creator and state getter in the config. So it should look like this (naming may be improved if it's not so descriptive):

// config
{
  actionCreator: persistedStateToMerge => ({
    type: '@@REHYDRATE',
      payload: {
        key: 'local',
        savedState: persistedStateToMerge,
      },
    }),
  stateGetter: action => action.payload.savedState,
}

Another proposition is to add additional fields to the current action object:

// config
{
  appendToAction: { key: 'local' },
}

// action that will be dispatched
{
  type: '@@REHYDRATE',
  payload: state,
  key: 'local'
}

What do you think about those options?

[ThibautMarechal]

The problem with the first solution is that you don't have the config inside the autoRehydrate function, so you won't be able to call "stateGetter".

The second solution seems nice. It do not break anything if someone is listening to the payload of the action.

[adam-golab]

You’re right. Only the second solution makes sense in this case. Would you like to create a PR with those changes?
If not, don’t worry, I'll maybe find some free time next weekend and try to implement this.

[ThibautMarechal]

I'll be able to do it tomorrow :)