Show Buttons
Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkdin
Share On Reddit
Share On Stumbleupon
Contact us
Hide Buttons

Automating Store and Action registration for multiple components using Fluxxor

I recently stum­bled across Fluxxor that pro­vides you with some really neat util­ity func­tions to build appli­ca­tions using the flux architecture.

While fluxxor pro­vides a tonne of use­ful fea­tures, one of the things that I found lack­ing was the abil­ity for com­po­nents reg­is­ter the stores that they depend upon dynamically.

The Prob­lem

It is very likely that when archi­tect­ing your flux appli­ca­tion, you will orga­nize your com­po­nents into dif­fer­ent fold­ers. Some of these com­po­nents will depend on stores and actions. And for some of them, the stores and actions are shared.

The quick start guide shows you how you reg­is­ter actions and stores before­hand. Although its an effec­tive strat­egy, its not scal­able because it is dif­fi­cult to iden­tify all the stores and actions that the sub-components on a page are going to require at the time of defin­ing the top level com­po­nent, the place where your instan­ti­ate your flux object. This also implies that you would have to edit your top level com­po­nent to reg­is­ter a new store when­ever a com­po­nent is added that depends on a store.

The sit­u­a­tion gets even more com­pli­cated if you allow com­po­nents to reg­is­ter stores by them­selves at run­time because it is pos­si­ble that dif­fer­ent com­po­nents might depend same store and there­fore it is wise to only have one place to reg­is­ter a store.

If only we could have a way to allow each com­po­nent to men­tion the stores it depends on, and then the run­time would take care of reg­is­ter­ing them if not already registered.

The Approach

It seems like this is a very good use case for cre­at­ing a mixin that can act as a check­point for com­po­nents that need to reg­is­ter stores and actions.

Lets say that we have a sim­ple data store as shown below.


And a sim­ple action as shown below


Notice that in the last line, we assigned a dis­play­Name to the store. This is the name with which we will auto-register the store using our mixin.

We will call our mixin FluxContextMixin since it helps in con­struct­ing the flux con­text by adding stores and actions as necessary.

Our objec­tive is to use this mixin on any com­po­nent that depends on other Fluxxor stores and actions. And by sim­ply list­ing out the stores and actions in the sta­t­ics, the mixin would auto­mat­i­cally reg­is­ter them in the flux con­text if they were not already registered.

Below is an exam­ple of a com­po­nent that would use our FluxContentMixin.


The Flux­Con­textMixin

Now comes the meat of the mat­ter, our Flux­Con­textMixin itself. I have added a tonne of inline com­ments to explain what I am try­ing to do at each step of the way.

Essen­tially, the mixin does a few things

  • Defines a life­cy­cle method the getInitialState,
  • Within this method, it inspects the sta­t­ics array of stores and actions.
  • For each store that it finds, it attempts to reg­is­ter it. It does so by check­ing the store con­struc­tor has already been reg­is­tered. If no, it reg­is­ters the store with the flux con­text, saves a ref­er­ence to the con­struc­tor in its clo­sure scope and then adds the name to the reg­is­tered store list.
  • Actions are sim­pler since they essen­tially need to be unique within the flux con­text and are noth­ing more that than key value pairs of action names and func­tion han­dlers. In our case, we sim­ply add the action and its han­dler to the clo­sure scope if the action name is not already registered.


After using this mixin for a while now, build­ing com­po­nents is a snap since all you gotta do is list the depen­den­cies. As far as instan­ti­at­ing stores with a con­fig is con­cered, you can do it at any time on the require. How­ever, since stores are meant to be used by mul­ti­ple com­po­nents, they would ide­ally be instan­ti­ated with the same con­fig every­where but its only one com­po­nent in the com­po­nent tree actu­ally reg­is­ters the instance with the flux context.

Ryan Sukale

Ryan is just a regular guy next door trying to manage his life and finances.