[v5] Rehydrated action ?

[jbrodriguez]

You're planning to have the bootstrapped property, which you can listen to for changes in Components (such as in PersistGate)

How about a persist/REHYDRATED action that can be listened to by middleware (thinking about redux-sagas here) ?

[rt2zz]

I think thats a good idea, although the actual action would probably have to be persist/BOOTSTRAPPED. Because now that we support code split reducers, the idea is being "rehydrated" is a little more fluid, however bootstrapped means: all of the initial reducers are now rehydrated.

I would like to think about how this action is dispatched. It is not clear to me if it should be automatically dispatched always, or if it should be handled by a config option or integration point.

[jbrodriguez]

Sounds great !

[brownbl1]

I also think this would be a very useful feature.

[rt2zz]

ok I want to think on it longer before adding a BOOTSTRAPPED action (need to consider performance and long term api).

but what might make a lot of sense is to add a third argument to persistStore which is a callback that will be invoked once bootstrapped. It would then be trivial to dispatch your own action which a saga can act upon. This is nice because there would be 0 performance implication for users who do not supply the argument, and would actually improve backwards compatibility with v4 persistStore.

Let me know what you think, if agreed it will be a quick addition.

[jbrodriguez]

That's how I'm doing it right now on v4.

I suggested the action, because you were removing the callback.

If you leave it there, it would almost be api compatible.

Fine by me 👍

[brownbl1]

Yeah, I don't see any reason to have both. This is probably the simplest implementation. If you wanted to fire your own BOOTSTRAPPED action from this hook, that would be your choice as the consumer.

[rt2zz]

added to alpha.4

There is a test, although I have not run this code in an actual app. Please lmk if any issue.

[rt2zz]

also please note the error does not take any arguments as we do not have restored state or any error in scope at that point. If you need state the best option is to simply call store.getState()

[brownbl1]

I tried npm upgrade redux-persist@next but I'm not seeing the new code locally. I'll try linking my local repo for now..

[brownbl1]

Just tested it locally, yep it's working for me! Only fires after all REHYDRATE actions are sent.

[rt2zz]

I know for yarn yarn upgrade redux-persist@next will not work, I have been doing yarn remove redux-persist && yarn upgrade redux-persist@next although probably a cleaner solution exists

[brownbl1]

I ended up doing he equivalent with npm.

[sibelius]

so, is there any guide for v5 to handle this?

should we dispatch an action on bootstrap callback?

[Noitidart]

@sibelius by defaulted the reducer of _persist contains a key called rehydrated. So you don't need an action, just wait for that. But you can wait for the action of REHYDRATE:

import { REHYDRATE } from '../redux-persist/constants'

[rt2zz]

non relative path:
import { REHYDRATE } from 'redux-persist/lib/constants'

So to recap: the recommended methods to know when the persistor is fully bootstrapped are:

1. in react: use PersistGate
2. in general / for integration with redux-sage: use the bootstrapped callback argument to persistStore. From their you can dispatch a custom action as needed, something like:

persistStore(store, {}, () => {
  store.dispatch({ type: BOOTSTRAPPED })
})

Still need to figure out the bes we avoid the rarely used {} second argument to persist store? For now the empty object I think is required.