No Action files! another step in being super lazy.

[yonatanmn]

Normally in reflux we have several Actions files, containing list of strings, and in the stores we add methods like: onSomeAction. we have to manually connect everything, and when we change the name of the Action we do it twice or more.
Usually, I don't share Actions between stores, and this duplication is really annoying.
So I came up with this:

function createStoreAndActions(storeObj) {

    function startWithOn(str) {
        return str[0] === 'o' && str[1] === 'n' && str[2].toUpperCase() === str[2]
    }

    var ActionStrs = Object.keys(storeObj).filter(startWithOn);
    let Actions = reflux.createActions(ActionStrs);

    if (storeObj.listenables) {
        if (Array.isArray(storeObj.listenables)) {
            storeObj.listenables.push(Actions);
        } else {
            storeObj.listenables = [storeObj.listenables, Actions];
        }
    } else {
        storeObj.listenables = Actions;
    }

    return {
        Store: reflux.createStore(storeObj),
        Actions
    }

}

the convention I've used is taking all methods starting with 'on' and having capital letter after that. Of course it's easy to implement any other convention (e.g passing to create an array of strings etc)
then I can just specify those methods, and an auto actions will be created.

let {Store, Actions} = createStoreAndActions({
    mixins:[...],
     onTestAction(){
       console.log('it is working with no explicit Action!')
    }
});

export {Actions};
export default Store;

and in Component:

import TestStore, {Actions as testActions} from '../Stores/TestStore';
var Component = React.createClass({
    render: function() {
        return (
          <div onClick={testActions.onTestAction}>click here to log from store</div>
        );
    }
});

[devinivy]

I saw that you've implemented something like this in cartiv. While it reduces boilerplate, I don't know that it reduces boilerplate in a way that I prefer. I would prefer to see each action, and even know what arguments it takes– likely using an action creator.

[yonatanmn]

@devinivy , when you create actions with Action creator you separate the call from the actual logic, so actually you don't(!) see the arguments it takes, or what it actually do, and you can only guess it from the name.
Cartiv's approach is not only less-boilerplaty, but much more logical - you combine the logic with the action, and it become normal again, similar to regular JS methods that you give a name and logic at the same place.

Cartiv presents cleaner code than the example above, and allows you to manually choose which actions will get selected.

[devinivy]

You have the stores describing the arguments of an action. So if the idea is that multiple stores can listen to the same action, then which store is responsible for describing the arguments of that action? Otherwise it implicitly involves the view (any caller of an action) with the inner-workings of your store.

When an action creator exists, it dictates the format of the action (like a type/struct), then any store that wants to participate in using that action needs to accept the correct arguments (accept that specific type/struct). The way I see it, an action is not just a roundabout way of calling some specific piece of store logic– it actually expresses some sort of intention or occurrence that your app's state might be interested in.

If this works for you, I don't mean to say it's inherently wrong/incorrect, or anything like that– it just wouldn't work very well for me.

[yonatanmn]

First, where do you define argument when you create action? In Reflux's createAction or createActions I don't see it.

Secondly, after experiencing in many reflux applications, almost 99% of my actions are listened by only one store. Of course you can architecture you app otherwise, but I've found out that it is much easier later to understand the flow of the app if only one store listens to an action.
In Cartiv, without out-of-readme methods, you set the actions through the store, so you have the format+name+logic together, with only one store per action.

[devinivy]

Reflux doesn't offer a way to do this– you would wrap the action call in a function if you wanted to specify its args. In the future I would be interested in actions looking more like union-types a la https://github.com/paldepind/union-type.

What you're describing still sounds to me like a roundabout way of calling a store method directly from a view– I think we just lay our apps out differently, and that's all cool with me :)