Familiarize yourself with Facebook's flux design, The main concept behind fluxapp is the unidirectional flow of data, but there is some great information in that documentation.
Fluxapp follows this design primarily with a few exceptions;
Flexibility
Fluxapp does not impose a directory structure, or even a philosophy on how to run your application. The information below is an example of how to fluxapp, but it could be manipulated to act in the same manor that facebook describes above, in regards to data flow.
It can be used as an isomorphic framework or as a traditional client side framework.
Multi Context
In order to operate in a multi context environment like node, we pass around a context object that ensures data is appropriately assigned to the proper requests.
Each context is assigned its own dispatcher, store and action instances.
Using the plugin infrastructure or by passing custom context methods to the createContext method, we can extend this context provided to components, actions and stores.
For more information see the Context Overview
Actions Handlers
Fluxapp uses namespaced actions, and handles both async and sync responses using bluebirds Promise API. On each action whether async or sync a before and after event is dispatched. In the event that the Promise is rejected a failed event is dispatched with the error that occured.
For more information see Actions
Action Types
When using namespace action handlers, we needed a way to easily reference the action. getActionType does this by converting a string made up of namespace.method:event to the proper constant for use inside of fluxapp.
For more information see Action Types
Stores
Stores bind to action events and use the data provided to manipulate their state. The base store instance provides methods for setting the initial state of the store, construction, replacing and merging new state data. Using either of these methods will invoke a change event to the stores listeners.
The state store is immutable and can be retrieved as immutable or mutable.
Router
The internal fluxapp router is primarily used for creating request routes and retrieving route objects.
For more information see Request Object and Route Objects
Dispatcher
There is still one dispatcher per context, as in flux design. Where our dispatcher alters is that it handles both async and sync requests while still providing an intelligent waitFor method that detects circular dependencies.
Another feature we have added is the queueing of events that allows additional events to occur but not be processed until the current action has completed its dispatch cycle. This feature allows us to automate before, after and failed child events saving the developer from implementing them.
For more information see Dispatcher
Plugins
Fluxapps plugin design allows for modules to register stores, actions and provide custom context methods to each context created.
For more information see Plugins and Existing Plugins
React Components
While not directly tied to react components we do provide a context wrapper using reacts context types, as well as a component mixin that takes care of binding before, after and failed action events as well as store listeners.
For more information see Component Mixin and createWrapper
On to the Contexts