Closed marcins closed 7 years ago
Ah, after having a look at the existing tests, and especially the 'with redux' test, I think that's what the preloadState
function is intended for? That seems a bit clunky to have to explicitly wrap the relevant bits of initial state in preloadState
calls - it seems the approach above (checking for action.type
to be @@redux/INIT
) obviates the need for using preloadState
in your initial state.
Any progress on this one ?
For this minimal example:
I get an error:
This is because there are appear to actually be multiple
@@redux/INIT
actions - the first with state beingundefined
and the second with the initialState. It appears that when the optimistic reducer runs for this second init, this is when Redux passes in theinitialState
even though the optimistic reducer thinks it's alreadyready
it has lost the state it setup the first time.A potential fix appears to be changing the code around line 105 to:
.. but I still need to verify this doesn't have any adverse side-effects (and write some proper failing tests too).