Unidirectional Data Flow Architectures

Intro

After watching the excellent talk, I felt the need to summarize it so it can stick to my mind. As the title suggest, the talk focuses on frontned unidirectional data flow architectures as opposed to those relying on model binding (i.e. two-way data flow).

Two-way databinding Two-way databinding Unidirectional UI Architecture Unidirectional UI Architecture

Flux

Flux Architecture View is listening for events from the store, sends events/actions to the dispatcher, and the store is listening for events from the dispatcher. In essence, the dispatcher is an event bus.

Pros

  • The dispatcher simplifies the events' lifecycle.

Cons

  • Concurrency and data sharing between stores.
  • Difficult to reuse (not fractal)

Redux

Redux Architecture A variation of flux where now we also have a single store that contains the dispatcher. Reducers are pure functions responsible for managing the state (old state + action => new state). View provider allows redux to be reused with different front end frameworks/libraries (e.g. Angular, React, ...)

Pros

  • Now the store is also a singleton.
  • Reducers are easy to test and predictable.

Cons

  • Still not fractal
  • Not very beginner friendly (middlewares, providers, containers, ... what?)

BEST (Behaviour, Event, State, Tree)

BEST Architecture Direct correlation with MVC => M = State, View = Tree, Controller = Behaviour + Event. State and Tree are declarative (have no logic).

Pros

  • Simple State and Tree
  • Easy to reuse.

Cons

  • Can be a bit difficult to keep track of state changes
  • Not used much.

Model View Update (ELM)

Model View Update Architecture Very much like redux because redux was inspired by ELM (so, redux is the copycat here). All components are hirarical and can accomodate several inner layers.

Pros

  • Fractal and simple

Cons

  • Lots of wrapping and unwrapping

Model View Intent (CycleJs)

Model View Intent Architecture View has no event handlers. Those are injected by the intent layer. All communications are performed by means of exposing an observable steam which is consumed by the next component.

Pros

  • Fractal, generic, and flexible.
  • Reactive everywhere (how components communicate)

Cons

  • People don't like reactive streams (yet!)

Further reading

  • How each handles server communications?
← Back to home