redux-resource-action-creators

[whichsteveyp]

Implements the discussion and API in #186 that can be leveraged in both plugins & applications using redux-resource to help create valid action shapes for our ecosystem.

Published: [email protected] so we can try it out in apps and take a look at how this API works in practice after the bikeshedding that produced it ;)

[jamesplease]

I'll do a more thorough review soon; just did a quick pass at some of the build-related stuff. Thanks for putting this together @sprjr – looks like a great start!

[jamesplease]

some of these should be removed since they refer to prop types

[jamesplease]

this should prob be you @sprjr ✌️

[jamesplease]

ReduxResourceActionCreators

[jamesplease]

'prop-types' isn't needed here

[jamesplease]

this line can be removed

[jamesplease]

Let's drop the " – " prefix for these nested describes

[whichsteveyp]

Was chatting today about the current API here with @jmeas. Here is what we do right now:

.pending(options)
.null(options)
.succeeded(resources, options)
.failed(error, options)

The last two methods have a different API right now, although they are for different reasons.

1. .succeeded accepting a resources array instead of { resources } on the options helps us enforce that you provide an array of resources for a success and that we can properly include that on the base of the action. This is something that our reducers will require so it's 'critical' for this action shape.
2. .failed accepting an error was doing this to help enforce that there is an error present, but this was really only because redux-resource-xhr uses this key, and as it turns out there's nothing in there that is directly used by our reducers.

We talked about changing the APIs to one of these, although we're open to more suggestions:

.pending(resources, options)
.null(resources, options)
.succeeded(resources, options)
.failed(resources, options)

Which would retain the 'make sure you pass some resources for any of your actions' , although they are not necessarily required for these in all cases (e.g. you could just have a list or a label perhaps in the create scenarios.

Another suggestion was:

.pending({ resources, ...options, })
.null({ resources, ...options, })
.succeeded({ resources, ...options, })
.failed({ resources, ...options, })

Both of these would allow a consistent API across all 4 methods, although they have different tradeoffs or gains I would imagine. Any thoughts? /cc @vinodkl @marlonpp @tbranyen

[jamesplease]

@sprjr , I thought a bit about this while doing #275 / #277 . I'm currently thinking that the API should be:

// Create a set of action creators. `actionDefaults` will be set on every action.
var actionCreators = new createActionCreators('read', actionDefaults);

// Send off the `pending` action. Add/override `actionDefaults` with `action`.
actionCreators.pending(action);
actionCreators.failed(action);
actionCreators.succeeded(action);
actionCreators.null(action);

I think there are two benefits to using this API:

• there's usually a lot of shared data with the start/end actions, and since there are four total actions, it is awesome to be able to specify that in one place, actionDefaults
• using the actionTypes export directly sucks, and specifying read and then using .pending() is much nicer

My concern with the different signatures in the current implementation is that it may be too much for folks to remember.