A Data Oriented alternate to Redux

Posted by moodyharsh on 2017-06-09

Show me your flowcharts and conceal your tables, and I shall
continue to be mystified. Show me your tables, and I won’t usually
need your flowcharts; they’ll be obvious - Fred Brooks

Code is the moving part of software. We talk as if code doesn’t
move. The word object implies something that does not move unless
acted upon. The word function implies something fixed in time.
Granted code doesn’t seem to move visibly like electricity or fuel
but it does. Code pushes data into the user screens and into the
database. Data remains fairly passive like a glass bottle in a
manufacturing process or like a chemical being moved across the
refinery systems.

There are infinite ways of acting upon data. How can we anticipate
all the ways with classes ? This is the fundamental mistake of OOP
IMO. Data and Code ought to be sepearte. Take 10 revisions of any
software. The data structures and tables that don’t change. It is data structures
that are meant to be resued, not code. The role of code is to process data.

If you’ve chosen the right data structures and organized things
well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming - Rob Pike

Software = Data + Processes.

A software is something that manufuctures, transforms, moves and stores
data for consumption and distribution. In data oriented design the
goal is to create code directly around data. Data is seen as permanant
and code is seen as transient.

Data Oriented Design and Entity Component System was discovered
by the MMORPG game developer community. It provides an alternative
to class based design for Game Objects. In it, state and application
data are centralized as an in-memory database and code running in
independent threads transforms the data every frame. The centralising
of state and application data is similiar to the notion of store
in react + flux. The key difference being data oriented design
doesn’t enforce immutable data structures. Structurally this is
closer to the Blackboard pattern.

Video Games are soft realtime systems. Business code is not like
that. Business code reacts to more discrete events. How do we apply
Data Oriented design to this ? I think a message bus is one way to
model the discrete events. We can easily model the the central
in-memrory database using javascript objects.

Here’s a library I put up todo just that.
It provides a centralized store for application data and a message bus
to handle state changes and events. Usage example,

Entity holds a plain javascript object and some metadata along with it.

Manager stores all the entities (application data) and registers the systems
which act upon the entities. It provides a boradcast message bus which wires all
the registered systems.

System encapsulates all the machinery for transforming and moving data.
It its simplest form its a closure. Every time a system is notified, it comes
alive and processes the application data.

The workflow is approximately this,

  1. Every time application data needs to be changed, create a new Message and notify the manager
  2. Manager dispatches message to the registered Systems
  3. Systems work together and transform the store.
  4. UI changes its state by listening to the change message which the systems report back

It is also easy to implement Undo / Redo with this approach. Every change message can trigger
a snapshot of the entities. You can checkout the react todo mvc example here.