redux @@redux/INIT actions

[SebastienDaniel]

It's kind of counter-intuitive to have to manually add @@redux/INIT tests that pass when filtering actions, since this is an extension of redux default behaviour.

filterActions(
        require("./session"),
        function(action) {
            return /@@redux|_SESSION$/g.test(action.type);
        }
    )

Shouldn't those actions be handled by default by this module?

[omnidan]

@SebastienDaniel Handling the @@redux/INIT action is an anti-pattern and should not be used. Feel free to reopen if I misunderstood or if you have any other questions. 😉

[SebastienDaniel]

I guess I didn't express myself properly :o

I'm not saying we should handle or react to those actions in anyway whatsoever, I'm saying those actions should pass any controls set by redux-ignore. In other words, they shouldn't ever be ignored.

Or is that still an anti-pattern?

[omnidan]

@SebastienDaniel It's an anti-pattern to treat @@redux/INIT special in any way. The idea is that you shouldn't rely on that action to initialize your state properly. When the first real action comes in, the default value for the state will be used anyway. You can read more about this here.

What's the issue you're having?

[SebastienDaniel]

The code is working fine. Its mostly a boilerplate issue, so nothing critical.

I felt that having to account for @@redux/INIT when using redux-ignore was an implementation detail of redux that should be handled by redux-ignore.

Here is what my root reducer looks like when using redux-ignore.

combineReducers({
    apis: ignore.ignoreActions(
        require("./apis"),
        function(action) {
            return /^ACTIVATE_|^FILTER_|^SORT_|^WAITING_FOR$|^TRIGGER_$|^ADD_$/g.test(action.type);
        }
    ),
    session: ignore.filterActions(
        require("./session"),
        function(action) {
            return /@@redux|_SESSION$/g.test(action.type);
        }
    ),
    components: require("./components"),
    shell: ignore.filterActions(
        require("./shell"),
        function(action) {
            return /@@redux|^ACTIVATE_|^TRIGGER_|^ADD_/g.test(action.type);
        }
    )
});

Notice that I NEED to account for @@redux/INIT, otherwise redux throws the error:
Reducer "reducerName" returned undefined during initialization. If the state passed to the reducer is undefined, you must explicitly return the initial state. The initial state may not be undefined.
This is caused by @@redux/INIT actions being ignored by redux-ignore, preventing the store from returning it's initial state on redux initialization.

Maybe there's something I'm not understanding or a piece of information I'm missing. You seem to be saying that I'm not understanding the issue (all the better if I can learn from this!)

thx for your patience :)

[omnidan]

@SebastienDaniel ah, I understand your issue now, but unfortunately this isn't an easy fix.

I can think of two solutions to this:

1. Always let @@redux/INIT pass through - this could break in later versions of redux if it is changed to a random string. (you are not meant to handle that action)
2. Let all @@ actions pass through - this would solve the issue with 1. but might cause bugs when @@ is used to namespace an action, e.g. @@app/ACTION - those actions would never be ignored

In both solutions, we are introducing lots of magic and causing more bugs than we are fixing. @@redux/INIT is generally problematic with higher-order reducers.

I'll reopen this and add a help wanted tag in case someone comes up with a decent solution for this.

EDIT: Actually, there is another solution: Just use ignoreActions instead of filterActions, which acts as a blacklist (and thus still allows @@redux/INIT to pass through).

[liesislukas]

I've just added redux-ignore to my project and instantly got mentioned error:

VM35779:263 Uncaught Error: Reducer "user" returned undefined during initialization. If the state passed to the reducer is undefined, you must explicitly return the initial state. The initial state may not be undefined

[Mike-Dax]

I'm having the same error as liesislukas, would that be related to this issue?

[omnidan]

this should be fixed in 1.2.4 (thanks @maxmechanic!) - please let me know if there are any more issues 😁