I have been looking at Flux for a while now and I have reach a dilemma.
If you are familiar with this architecture, one of its central pieces is the Dispatcher:
The dispatcher is the central hub that manages all data flow in a Flux application. It is essentially a registry of callbacks into the stores and has no real intelligence of its own — it is a simple mechanism for distributing the actions to the stores.
I don't need to register callbacks; I expose a signal that will be observed by the Stores1:
In case you are wondering, the Action itself is an empty protocol. 2 So who implements the Action protocol? Well, different enums for specific domains of the application3: authentication, fetch feeds, etc.
Now, this is where the problem begins. The store is observing a Signal of type
Signal<Action, NoError>. But, although each store should be able to observe any kind of Action 4, it leads me to this kind of pattern inside a store:
Which I kind of hate. As it stands, I have a couple of options, which I will explore in a later post.
This is a simplified version of the full class. ↩
Maybe a code smell? ↩
Going to use Brent Simmons's example: it's an RSS feed app ↩
Flux states: "Within the store's registered callback, a switch statement based on the action's type is used to interpret the action and to provide the proper hooks into the store's internal methods" ↩