12

Outline

In my app I'm using React and Reflux and have a hierarchical setup with regards to my data. I'm trying to break elements of my app into separate stores to be able to hook events correctly and separate concerns.

I have the following data flow:

Workspaces -> Placeholders -> Elements

In this scenario, when a workspace is created a default placeholder must in turn be created with a reference (ID) to the newly created workspace. The same applies for the placeholder to element relationship.

Sticking point

The Reflux way seems to suggest the PlaceholderStore listens to the triggers from WorkspaceStore, adding the newly created ID to this.trigger().

Reflux only allows a single event to be triggered from stores; thus preventing external components being able to discern create or update actions. This means that if one trigger in the store sends an ID as argument[0], subsequent triggers should do the same (to remain consistent). This is a problem for components looking for updates to multiple workspaces (e.g. re-ordering / mass updates).

Undesirable solution

I had thought to add in a concept of StoreActions; Actions that only stores can create, that other stores would then listen to (effectively discarding the original trigger from stores). With this components / stores could listen to specific events, and the arguments passed to said events could be tailored without worry. This seems like a wrong way to go and an abuse of the Reflux event system.

Help

Should I be trying to break up related data? Is there a better way to structure the data instead?

I've read about aggregate stores, but not seen any implementations to dissect. Do these offer a solution by way of bringing data from multiple stores together, and if so, what is responsible for creating events React components can listen to?

Many thanks for any help / insight anyone can offer!

Gabriele Petronella
  • 106,943
  • 21
  • 217
  • 235
Ashley 'CptLemming' Wilson
  • 8,686
  • 2
  • 32
  • 36
  • *I'm new to Reflux*. I find creating multiple ```store```s to be bad. I'd prefer a single action for multiple ```store```s (let's say *CRUD*), then I would pass down the store ```fn```s (```onTodoItemCreate```)for one module (let's say the ```create``` part for user), then have one main file for that module (for all the components or its ```route handler``` or template) passing the ```store handlers``` (or ```triggers```) down to components to whatever littler sub-components would need it. – srph Dec 16 '14 at 19:26
  • 2
    New to Reflux too. It will be easier to maintain a single store that manages appropriately complex models within. This is how I do it presently in my React/Reflux app. However, the data size grows, I may need to split the data and stores up as you are attempting to do. My point being that you may wish to start with a simpler structure, and improve it only as needed (by actual usage that demands it). – Drew Goodwin Dec 17 '14 at 23:11

1 Answers1

12

Yes, it is perfectly reasonable to call actions from a store. I see actions as initiators of data flows and I consider exceptional flows as seperate ones.

A good example is a CRUD store that also handles AJAX calls (to CRUD the data with server-side). The store will trigger the change event as soon as it's data gets updated. However in the event that an AJAX call fails, it should instead start a data flow for that instead so that other stores and components can listen in on those. From the top of my head such errors are in the interest of a toast/notification component and Analytics error logging such as GA Exceptions.

The AJAX example may also be implemented through the preEmit hook in the actions and there are several examples among the github issues discussion on that. There is even this "async actions" helper.

It's by design that the stores only emit a change event. If you want to emit other kinds of events, it basically means you're starting new data flows for which you should be using actions instead.

Spoike
  • 119,724
  • 44
  • 140
  • 158