-
Notifications
You must be signed in to change notification settings - Fork 866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v5] Rehydrated action ? #408
Comments
I think thats a good idea, although the actual action would probably have to be 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. |
Sounds great ! |
I also think this would be a very useful feature. |
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. |
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 👍 |
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. |
added to alpha.4 There is a test, although I have not run this code in an actual app. Please lmk if any issue. |
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 |
I tried |
Just tested it locally, yep it's working for me! Only fires after all REHYDRATE actions are sent. |
I know for yarn |
I ended up doing he equivalent with |
so, is there any guide for v5 to handle this? should we dispatch an action on bootstrap callback? |
@sibelius by defaulted the reducer of
|
non relative path: So to recap: the recommended methods to know when the persistor is fully bootstrapped are:
persistStore(store, {}, () => {
store.dispatch({ type: BOOTSTRAPPED })
}) Still need to figure out the bes we avoid the rarely used |
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) ?
The text was updated successfully, but these errors were encountered: