How to set initial state for dynamically added reducer? about redux-tools HOT 6 CLOSED

yep agree, I am not saying the implemention you are using is wrong, for me is NOT just ideal. :)

I dont see any problem why the state should not be passing through store initialState (this is the reason they added this prop in there) - bottom line is, the store is just a "distributor" of state in this case, there is nothing wrong on fact you will pass initial state which may or may not be used by reducer...

Anyway, the best would be to have ability to pass initial state with withReducers() (or any other similar way as initial state factory).

Thanks in advance.

from redux-tools.

Hey there, the intended usage is the first method you described, which should be working fine (we are using this throughout our internal projects). To make the second method work as well, it is necessary to swap out the combineReducers implementation for a custom one, see #76.

Could you clarify why you'd need to use the second method instead of the first one?

from redux-tools.

Hey there, the intended usage is the first method you described, which should be working fine (we are using this throughout our internal projects). To make the second method work as well, it is necessary to swap out the combineReducers implementation for a custom one, see #76.

Could you clarify why you'd need to use the second method instead of the first one?

Can you clarify how to use swap out implementation of combineReducers for this case?

And to clarify why the second usage is wrong... mainly it is because it creates side effects and external dependency which is not testable (without mocks). Dont forget the reducers should be pure functions without any dependencies which is not the case if you use localStorage for initial state in reducer

from redux-tools.

Modification of redux-tools is necessary, see packages/reducers/src/combineReducerEntries.js.

I think that in the second method you're just replacing a problem with another one (testability and impure reducers compared to features being responsible for their own data). To have it "correct", you'd need to pass the token to the createStore function, but why should the entire store know about the data source for a dependent reducer?

Another option is to instead have an authentication reducer factory and pass the localStorage data externally, to avoid mocking (i.e. the reducer factory would accept initial data when injecting). This is IMO the best way to approach this in terms of quality of code.

That being said, redux-tools should not limit you in the way you solve this issue, so #76 should be fixed regardless (still a bug).

from redux-tools.

We use the first method because the side-effect is performed only during initialization, which is IMO fine for reducers (It doesn't cause any issues, it just isn't "clean" according to the documentation and FP principles.).

from redux-tools.

fixed by #86

from redux-tools.