Open orbiteleven opened 8 years ago
Maybe, what is the benefit? Interoperability?
One thing I don't agree is using the same action for the the event, the success and the error. Most likely if we use this we would keep using separate actions e.g. 'ON_FETCH_ERROR'.
The benefit would be standardization. As it is now, when dealing with redux-crud
actions I look for action.action
and action.record(s)
, but with redux-actions
it's action.type
and action.payload
(or action.error
). The standardization would be nice.
I imagine START|SUCCESS|ERROR
actions would be independent. action.error
is a boolean indicating this action is an error state. It can be used by middleware upstream.
@orbiteleven do you mean to just make START|SUCCESS|ERROR
actions FSA compliant or replace them with sequence
{type: FETCH, meta: {sequence: 'start'}
{type: FETCH, payload: ...}
{type: FETCH, error: true, payload: error}
I like the second idea, because this three actions is the one, but it's a pain to monitor them.
@sporto this would defeat the point imo, I wouldn't mind seeing a configuration option to allow for FSA
Any interest in implementing Flux Standard Actions? https://github.com/acdlite/flux-standard-action
Selfishly this makes sense as I blend both redux-actions (https://github.com/acdlite/redux-actions) and redux-crud in my applications and would like a consistent action interface.
Understandably this would be a breaking change, but IMO worth it... if there's interest.