POP, Signals and Dispatchers (part 1)

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.

  1. This is a simplified version of the full class.

  2. Maybe a code smell?

  3. Going to use Brent Simmons's example: it's an RSS feed app

  4. 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"