examples - how to implement action type namespacing ?

[pbc]

I have spent about a week now trying to find any good implementations of action type namespacing and have rolled my own which is based on Transition classes which hold definition of an action creator, reducer and a list of it's child transitions, but this approach requires way too much boiler plate code and it's problematic when you have a lot of very simple actions.

In all of the examples which you can find in this repo and plenty of others this problem is always ignored for some reason but this was the first problem I have spotted when started looking into Redux.

Am I missing something here ? You guys have no action type naming collisions ?

Can someone update the examples and show me how you deal with this problem or point me in the right direction ?

My specific case is related to having 2 separate admin panels on the frontend. One for testers and one for customers which will have their state stored in separate sections of the store ("testerAccount", "customerAccount"), but both of them will be able to do similar things for e.g. ADD_VIDEO_UPLOAD, ADD_COMMENT, etc, etc.

I would really appreciate your help here :)

[gaearon]

Put accountType into actions? See also examples/real-world/reducers for how you can write a reducer factory and use the same code many times producing reducers that respond to different actions.

Similarly don't forget action creators are just functions, and you can create functions that return a bunch of other functions.

[gaearon]

I think it would really help if you provided a specific small example of the problem you say is ignored in existing examples.

We can then help you find ways to simplify that specific example. It's very hard to suggest something specific in response to a question without code.

[pbc]

@gaearon I know where you're heading with this, but I am not trying to create reusable reducers, action creators or DRY things up, quite the opposite.

I am trying to isolate groups of actions from each other so I can have 2 people working on two different sections of the system and be sure that they won't start triggering each other's reducers accidentally due to lack of namespacing in the action type names.

Hope this makes it more clear.

[koulmomo]

I've solved this issue in my project(s) by using https://www.npmjs.com/package/flux-constant in combination with a super simple helper function called createActionTypes.

Essentially, my code ends up being:

// create-action-types.js
var fluxConstant = require('flux-constant');
module.exports = function (types) {
    return fluxConstant.set(types);
};

// in foo-action-types.js
module.exports = createAtionTypes([
    'ADD_FOO',
    'REMOVE_FOO'
]);

// in some-store.js
var fooActionTypes = require('foo-action-types');
function (state, action) {
    switch(action.type) {
        case fooActionTypes.ADD_FOO: 

        case fooActionTypes.REMOVE_FOO:
   }
}

[gaearon]

Why not keep all action types as constants in one place?
Then they sure can't clash because you can't export the same name twice.

[pbc]

To better visualise this, let's say this is the initial state of the store:

let initialState = {
  "testerAccount": {
    "videoUploads": [],
    "messages": []
  },
  "customerAccount": {
    "videoUploads": [],
    "messages": []
  },
  "systemUserAccount": {
    "videoUploads": [],
    "messages": []
  }
};

How will you avoid action type name collisions when implementing separate reducers for adding videos or messages for each of these sections ?

[pbc]

@gaearon what you're suggesting doesn't solve the core of the problem, it's more of duct tape approach because over time you will end up with a huge type file which will cause a lot of problems .

It will straight away cause problems during code merges which later on will need to be solved with naming hacks, for e.g.:

ADD_VIDEO_UPLOAD, ADD_TESTER_VIDEO_UPLOAD, ADD_VIDEO_UPLOAD_IN_SOME_SECTION, etc.

which is a one big headache again.

@koulmomo This is exactly what I was looking for, thank you :) 👍 Simple and powerful.

@gaearon I think we should have at least one example which uses either this package or a new package which could be named redux-constant ?

In my opinion promoting approach in the docs / examples, which solves the problem of namespacing should be the new default.

Thank you for your help with this :)

[gaearon]

In your example, I don't really get why not have one set of types, one reducer generator and one set of action creators. The actions would contain accountType property to tell them apart. Action creators would accept it as a parameter. The reducer factory would accept accountType and return a reducer that only handles actions with this account type.

[gaearon]

I don't think flux-constant is a great solution here. It seems to rely on instanceof checks. Which means you can't serialize your actions and later replay them because—bam!—their deserialized types won't match the generated ones.

People often try to make Flux “simpler” without realizing they are breaking its essential features.

[gaearon]

In your example, I don't really get why not have one set of types, one reducer generator and one set of action creators. The actions would contain accountType property to tell them apart. Action creators would accept it as a parameter. The reducer factory would accept accountType and return a reducer that only handles actions with this account type.

I was mislead by the apparent symmetry in your example. I understand now that you meant there is no DRY here, and the symmetry in features is only apparent as you said in #786 (comment).

[gaearon]

I don't think there's a need for a library here. Establish a convention! For example, if your subprojects or features are so separate, make it a rule to call action types feature/ACTION_TYPE, e.g. testers/UPLOAD_VIDEO or customers/UPLOAD_VIDEO. This is especially nice if these “groups” actually correspond to real folders (or better—packages) on the disk.

Violations will be easy to catch in code reviews. If you really want to, you can automate this but I can't see what it brings over manual namespacing. Inside each module, you'd still want to declare all constants in one file for easier control over features, preventing accidental duplication of effort, and as a documentation.

I'm all for adding a huge-apps example with code splitting, namespaced action types, etc. That would be a separate issue though.

[gaearon]

Strings aren't inherently bad for namespacing. URLs are strings, and they seem to work fine.

[pbc]

@gaearon You are right , I forgot about the problem of serialization with the solution based on flux-constant.

I don't have a problem with string based namespacing as long as we can easily distinguish the modules / namespaces in the name it self.

The naming convention based solution is something I have seen before:

https://github.com/erikras/ducks-modular-redux

but I hoped that there might be a better or a "correct" way of doing this which would be based on your experience.

I think I will try to convert the flux-constant approach into something that you could actually serialize in some way.

Please add a "huge-apps" example if you find time for this because this will save other people a lot of time and maybe it will lead to establishing some sort of convention which we could easily follow later on.

Thank you again :)