Skip to content

Home

Jump to bottom
Shane Brinkman-Davis edited this page Jan 2, 2017 · 38 revisions

Art.Flux is a simple, elegant solution to the following design constraints:

  • Components can subscribe to remote or shared data
  • Subscribing Components' states are automatically updated:
    • if the status of the initial request changes
    • as the initial request makes progress
    • whenever the data changes
  • if the data is available immediately upon component instantiation, the component’s first render will reflect that data
  • data is addressed by model-name and key-string
    • non-string keys are supported via custom toFluxKey methods
  • model and subscription definitions are simple and lean

If you are familiar with the Flux design pattern, see: Art.Flux-vs-Other-Fluxes

See

How It Works

There are three main parts to Art.Flux: FluxModels, FluxComponents and the FluxStore:

Using Art.Flux consists of registering one or more FluxModels and creating FluxComponents that subscribe to data provided by those models.

Behind the scenes, the FluxStore, a singleton class, manages all component subscriptions and provides epoch state updates. Epoch state updates queue all state changes in Flux turing a time unit, usually one animation frame, and applies them atomically to the FluxStore's internal state. Immediately after the internal state update, FluxStore notifies all subscribers of changes.

New subscriptions to data not currently in the FluxStore indirectly cause loads to be invoked on the appropriate models. FluxModels are responsible for updating the FluxStore on the progress of those loads and the final result. FluxModels can later update the FluxStore if that data is updated locally or remotely.

When all subscribers to a particular piece of data go away, the FluxStore releases the data. In this way the FluxStore only keeps in memory what is actually being used by active FluxComponents.

The diagram above shows typical method invocations that cause data to flow around the Flux loop. Only the myModel.myMutator needs to be invoked in your application code. FluxComponent state is automatically updated, and standard FluxModels take care of updating the FluxStore for you.

Example

To use Art.Flux, create your a custom model and custom FluxComponent with a subscription to the model:

# models/nav_state.coffee
{ApplicationState} = require 'art-flux'

module.exports = class NavState extends ApplicationState
  @stateFields currentTab: "home"

  nextTab: ->
    @currentTab = switch @currentTab
      when "home" then "search"
      else "home"

  @register()
# components/my_component.coffee
{TextElement} = require 'art-react'
{createFluxComponentFactory} = require 'art-flux'

module.exports = createFluxComponentFactory
  @subscriptions ”navState.currentTab”

  nextTab: -> @models.navState.nextTab()

  render: -> 
    TextElement 
      text: @state.currentTab
      on: pointerClick: @nextTab

Clone this wiki locally