Action validator throws on an action without a 'name' property (like the ones dispatched by the 'redux-devtools') about redux-immutable HOT 10 CLOSED

I don't think it's a Redux issue. "Type" is an established convention, at least in Flux world, that's where most of our conventions come from. There need to be very good reasons to break these conventions, and more so after we shipped 1.0 and lots of code is already written using "type". I think that's something for redux-immutable to reconsider.

from redux-immutable.

I have rewritten the test to check if action has type property and wether its value begins with "@@". These actions will be ignored, 85852fe.

@gaearon Is right in a sense that:

"Type" is an established convention, at least in Flux world, that's where most of our conventions come from.

This is also a convention defined in "flux-standard-action" spec. However, I have argued that "type" name as a convention does not make semantic sense.

"redux-immutable" implements the https://github.com/gajus/canonical-reducer-composition/ spec. Read the action object spec for more details. I will update the main "canonical-reducer-composition" description to include explanation why to use this "unconventional" spec over what has been established in flux land, but the short answer is: "canonical-reducer-composition" tries to be

• semantically correct
• follow conventions defined in the broader programming ecosystem
• more strict (e.g. FSA defines 3 allowable name variations of the "name" property: "type", "actionType" or "actionId" all of which are derived from the legacy standard and only the latter making the most sense.)

In the mean time, I am working on dev-tools that will work with both "redux" and "redux-immutable".

from redux-immutable.

@gajus This also breaks the logger middleware (it shows 'undefined' instead of the action type)
The community grow, middleware is the most pluggable way to extends Redux and is all about intercepting actions, if you don't get aligned with Redux convention things will just break,

At least make it configurable where default could be 'name',

(I guess we can just give the combineReducers a 2nd hash options where you can configure the property name that indicates the action identifier.)

Thanks.

from redux-immutable.

@asaf Just an idea, but why not have a function at the top of the middleware chain that maps "type" to "name" in every action it receives? This way anyone can use whatever name they choose if they don't like "name" convention. I can write a quick middleware package for that.

The same middleware function could map other properties that do not meet the standard, such as "payload".

Does that sound like a good solution?

from redux-immutable.

A simplified version would look like this:

store = applyMiddleware(
    mapper.fromCCAtoFSA,
    /* all middleware that needs to be FSA compatible */
    logger,
    mapper.fromFSAtoCCA
)(createStore)(reducer, state);

Where the mapper is something along the lines of:

let fromCCAtoFSA,
    fromFSAtoCCA;

fromCCAtoFSA = (store) => (next) => (action) => {
    next({
        type: action.name,
        payload: action.data
    });
};

fromFSAtoCCA = (store) => (next) => (action) => {
    next({
        name: action.type,
        data: action.payload
    });
};

export default {
    fromCCAtoFSA,
    fromFSAtoCCA
};

from redux-immutable.

@gajus 👍 I like this convention-conversion stuff.

from redux-immutable.

Ok. Will research certain aspects of the conversion (such as Error mapping) and release a package. Should be before the end of the day.

from redux-immutable.

The solution is to use middleware for converting between the two standards.

• https://github.com/gajus/redux-convention#middleware
• https://github.com/gajus/canonical-reducer-composition/blob/master/README.md#flux-standard-action

from redux-immutable.

@gajus This is still problematic, as @gaearon mentioned, "lots of code is already written using "type"", this also means reducers are being written in the community and expecting type, conversion to 'name' won't satisfy,

IMO, If you aim CCA out of the redux community you can diverge, but if you aim for Redux, you should be compatible with its standards otherwise community code will break.

from redux-immutable.

I use CRC as well as CCA in all the projects that I develop. I am sharing the CRC spec. I am sharing some libraries with the open source world and provide a method of bridging the different conventions. Sounds fair to me.

from redux-immutable.