The nanoflux high level API bases on factories, which provide all necessary components of the Flux architecture, i.e. Stores, Dispatcher, and Actions.
Store Provider
getStore( name )
Returns the store, or undefined, if not exists.
createStore( name, descriptor )
Creates a store with given name and descriptor.
The descriptor is a JSON object containing the store’s available methods and members.
Keep in mind, that nanoflux maps actions to store functions using the following convention: actionName > onActionName
Dispatcher Provider
getDispatcher( name? )
Returns the dispatcher, or undefined if not exists. If name is null or undefined, the built-in default dispatcher will be returned.
createDispatcher( name?, actionList? )
Creates a dispatcher with given name and an optional action name list. Passing null or undefined, refers to the built-in default dispatcher.
The actionList is an array of action names, that are going to be available as actions in the dispatcher (‘fluxy’):
Examples
Adds some actions directly (‘fluxy way’) to the default dispatcher
Creates a custom dispatcher.
Action Provider
getActions( name )
Returns the action provider, or undefined if not exists.
Creates actions with given name and descriptor using the given dispatcher. This is the typical way, as it offers full control
of your actions. It is considered as best practice to access Web API (async calls) within the actions.
Keep in mind, that nanoflux maps actions to store functions using the following convention: actionName > onActionName
Middleware
use( func, dispatcher? )
Adds a middleware function to the given dispatcher (or the default dispatcher if not given).
The function’s signature is fn(storeHandlerName, args), where storeHandlerName is the name of handler in
the targeted store, and args the payload.
Flux Component API
Each component of the Flux architecture provide additional methods, which are described here
Store
Inside a store’s descriptor the following methods are available for every instance.
onInitialization()
Within this method you can do some custom initialization on the store instance’s creation.
A typical scenario would be the chaining of stores.
notify( payload? )
Use notify to inform all subscribed views about state changes. Although, it is not common, it is possible to pass payload data as argument. Usually,
a store maintains several states for certain context, that’s why payload won’t be passed on callback. But nanoflux is flexible enough to support even that.
subscribe( calleeContext, callbackFunc )
Creates a subscription and returns a subscription object. Once subscribed the subscriber callbackFunc is called on notify(). The calleeContext refers to the subscribers context
and is bound to callbackFunc.
Use the returned subscription object to unsubscribe, e.g. while a component unmounts.
Note, that nanoflux offers the possibility to chain stores using subscribe (see onInitialization())
Dispatcher
The Dispatcher is the central hub in a Flux architecture. nanoflux offers the possibility to use more than one dispatcher, if needed.
Furthermore, with the nanoflux dispatcher you can attach simple, i.e. pure dispatch actions directly to the dispatcher, using
a action name list on the dispatchers creation. This so called ‘fluxy’ approach, reduces boilerplate code significantly
Example
connectTo(store|arrayOfStores)
Establish connection between a dispatcher instance and one or more stores. Once connected, the dispatcher is able to pass an action
call towards its mapped store callback function.
Usually, multiple stores are connected to a single dispatcher, but it is also possible to connect one store to multiple dispatcher.
Tipp: Try to keep the setup as simple as possible, i.e. one dispatcher and several stores. Think twice, if you plan to introduce
another dispatcher, or even chain a store.
Example
dispatch(actionName, payload?)
Executes a dispatch, and is usually called inside an action.
The actionName is used for the action-store-mapping. It is common, to use the same name as the function’s name.
nanoflux maps actions to store functions using the following convention: actionName > onActionName.
The payload will be passed as argument directly to the store’s method.
Usually, you won’t call this method directly, but use the Action Provider instead.