In late 2014 I was working on an iPhone app for LASU, a shoppable instagram for yuppies and Facebook was releasing their React Native project. I remeber being excited by it thinking how it would make the development experience I had with Titantium much nicer. Unfortunately it wasn't available yet and I had to get the app done.
So I poored over the documentation in hope of finding some nuggets of wisdom that might help me do what I was doing, better. It turns out that the declarative UI stuff was a little out of my reach at the time (no time to develop a React for Titanium) but the flux approach to manging state in the app was.
Soon after I started to understand what it was the value of separating the actions that manipulated state from the stores of state themselves I rushed to implment my own flux system with actions, stores etc. It worked amazingly and made debugging the app 100x easier. I could store All of the actions that were sent through the dispatcher, log them fromone point and then, play them back through the dispatcher to find the application state that was causing my issues!
Unfortunately LASU fell apart, mainly becuase we failed to assess the needs of our target audience. Which is a long way of saying we never talked to anyone.
The flux implementation left a mark on me though. It just made it much easier for me to understand the flow of state through my app. As I moved more into web services development for our next projects I longed for that clarity.
I recently started reading about distributed logging, event sourcing and CQRS. The premise of these things is:
Anyway, the point is I realized that Flux, CQRS and ES are all attempting to achieve the same goal: sanely managing application state, via the same means: Separating reads from writes.
This is a work in progress / brain dump