javascript - Should a Flux action creator dispatch granular actions or sweeping ones? -

the premise

i'm refactoring flux stores/actions/action creators more fluxy (publish, publish_success, publish_failure instead of weird is_loading action), , wondering how structure actions: should action creators call single actions (publish_success) or multiple ones (add_author, add_book, etc)?

the example

here's more specific example:

i have tasksstore holds todo items innovative new task-management app, , have poorly named action creator taskactions lets me fetch varieties server , add new ones api. kinda this:

const tasksstore = { ... };  const taskactions = {     fetchtasks(),     addtask() }; 

what actions should dispatch communicate tasksstore?

i see 2 options: action-creator-api-specific actions (fetch_tasks, fetch_tasks_success, fetch_tasks_failure, add_task, add_task_success, & add_task_failure) or reusable actions (add_task called on , on fetch , called once addtask()).

basically, should api (verbose, perhaps redundant, dispatch-able actions each action-creator-action):

const tasksstore = {     on('fetch_success', (tasks) => { // add tasks });     on('add_success', (task) => { // add task }); };  const taskactions = {     fetchtasks() {         dispatch('fetch');         myapi.fetchtasks(             (success_payload) => { dispatch('fetch_success', success_payload) },             (failure_payload) => { dispatch('fetch_failure', failure_payload) }         );     },     addtask() {         dispatch('add');         myapi.addtask(             (success_payload) => { dispatch('add_success', success_payload) },             (failure_payload) => { dispatch('add_failure', failure_payload) }         );     } }; 

or (concise, reusable dispatch-able actions):

const tasksstore = {     on('add', (task) => { // add task }); };  const taskactions = {     fetchtasks() {         dispatch('fetch');         myapi.fetchtasks(             (success_payload) => {                  success_payload.foreach((task) => { dispatch('add', task); })             },             (failure_payload) => { dispatch('fetch_failure', failure_payload)         );     },     addtask() {         dispatch('add');         myapi.addtask(             (success_payload) => { dispatch('add', success_payload),             (failure_payload) => { dispatch('add_failure', failure_payload)         );     } }; 

or in between?

thanks!

we decided go more verbose route:

for ajax actions (like in examples), dispatch specific "started" action, "success" or "failure" action:

dispatch('reticulate_splines'); app.reticulatespinesandreturnpromise().then(     (success) => { dispatch('reticulate_splines_success'); },     (failure) => { dispatch('reticulate_splines_failure'); } ); 

why?

1. this decouples action creators actions bit— action creators expose uniform, grokkable api in form of dispatched actions: actioncreator.fetchmessages dispatch fetch_messages action, not add or fetch_or_add or weird. it's lot easier understand decoupled system actions , stores (decoupled because actions travel through dispatcher) when there no unexpected dispatches.
2. it makes lot easier multiple stores listen action-creator-actions. messagethreadsstore need update when .fetchmessages() not .postmessage()? listen fetch_messages_success, not add might have been called in both otherwise.

anyway, hope helps.