reactjs - How to deal with hierarchical data with Reflux stores? -

outline

in app i'm using react , reflux , have hierarchical setup regards data. i'm trying break elements of app separate stores able hook events correctly , separate concerns.

i have following data flow:

workspaces -> placeholders -> elements

in scenario, when workspace created default placeholder must in turn created reference (id) newly created workspace. same applies placeholder element relationship.

sticking point

the reflux way seems suggest placeholderstore listens triggers workspacestore, adding newly created id this.trigger().

reflux allows single event triggered stores; preventing external components being able discern create or update actions. means if 1 trigger in store sends id argument[0], subsequent triggers should same (to remain consistent). problem components looking updates multiple workspaces (e.g. re-ordering / mass updates).

undesirable solution

i had thought add in concept of storeactions; actions stores can create, other stores listen (effectively discarding original trigger stores). components / stores listen specific events, , arguments passed said events tailored without worry. seems wrong way go , abuse of reflux event system.

help

should trying break related data? there better way structure data instead?

i've read aggregate stores, not seen implementations dissect. these offer solution way of bringing data multiple stores together, , if so, responsible creating events react components can listen to?

many / insight can offer!

yes, reasonable call actions store. see actions initiators of data flows , consider exceptional flows seperate ones.

a example crud store handles ajax calls (to crud data server-side). store trigger change event it's data gets updated. in event ajax call fails, should instead start data flow instead other stores , components can listen in on those. top of head such errors in interest of toast/notification component , analytics error logging such ga exceptions.

the ajax example may implemented through preemit hook in actions , there several examples among github issues discussion on that. there "async actions" helper.

it's design stores emit change event. if want emit other kinds of events, means you're starting new data flows should using actions instead.