Extract Common Patterns in Stores and Actions

[paulstatezny]

Extract Common Patterns in Stores and Actions

Acceptance Criteria

1. AbstractActionCreator class exists with a performApiAction method. The method abstracts away the most common use case in action creators: Performing an API call and dispatching flux actions on success/error with the response body as payload.
   • The method signature will look like this:

performApiAction : function(promise, actionType)

• It will be used like this in an action creator:

getFoo : function(fooId, fooFilters)
{
    this.performApiAction(fooClient.getFoo(fooId, fooFilters), 'GET_FOO');
}

// Replaces this -- AND the need to write any tests; could save 20-30 min per issue for issues with multiple actions
getFoo : function(fooId, fooFilters)
{
    var flux = this;

    flux.dispatch('GET_FOO');

    fooClient.getFoo(fooId, fooFilters).then(function (response) {
        flux.dispatch('GET_FOO_SUCCESS', response);
    }, function (errors) {
        flux.dispatch('GET_FOO_RESPONSE', errors);
    });
}

• The method will receive the promise and dispatch action + '_SUCCESS' on success, and + '_FAILURE' on failure, both with the responses received as the payloads.
  1. AbstractStore class exists with a handleApiAction method, which is designed to simply receive a payload and store it to a given property and then emit a change event.
• The method signature will look like this:

handleApiAction : function(actionType, propertyName)

• It will be used like this in a store

initialize : function()
{
    this.bindActions(/* ... Other non-standardly handled actions here */);
    this.handleApiAction('GET_FOO', 'foo'); // Store will put payload of GET_FOO in this.foo and emit('change');
}

Tasks

• Create abstract action, abstract store

  Additional Notes

• This will save us from rewriting the same old code and tests over and over. It will probably save 10's of man hours in the short term.

[paulstatezny]

There is still discussion to be had about AbstractStore.handleApiAction and how it should relate to loaded flags.

[chrisshiplet]

Is this going to handle the definition of constants at all? One concern I have is that it hides the existence of the "GET_FOO_SUCCESS" and "GET_FOO_FAILURE" constants and that could confuse someone when they just add "GET_FOO" to the constants file and nothing works.

[paulstatezny]

Good question. We could make it more verbose:

this.performApiAction(fooClient.getFoo(fooId, fooFilters), 'GET_FOO', 'GET_FOO_SUCCESS', 'GET_FOO_FAILURE');

But I think part of the complaint is wanting to minimize the boilerplate.

[paulstatezny]

Also, convention over configuration

[chrisshiplet]

Adding this here from our lunch discussion - I would rather go the direction of making the "SUCCESS" and "FAILURE" constants totally internal and only having the programmer specify a constant representing the name of the action. That way we're not requiring a programmer to explicitly define constants in order for our shorthand convention to work properly. I'm not sure what the implementation of this looks like yet without digging into fluxxor a little more.