The reason is that I'm coming from a React/Backbone background (see [0]), where the Backbone Model was passed in as a prop, and then also listened-to within the component. So in that context it would make more sense for it to be `props` instead of `state`. In this case, you can't really pass the person object in as props and then listen to it for changes from within the component, since the object is different from the stream "emitting" it. When the emitter and the object are different things, it makes sense that the emitter comes from `props` (or is directly `require()`'d, which may be an anti-pattern?) and the object is set in `state`.
[0] http://www.toptal.com/front-end/simple-data-flow-in-react-ap...
Ultimately, pure-Bacon seems more functional, and I wanted to use something where all the "primitives" (Immutable, Bacon, etc) can be used directly, and are extremely well-supported. I may add a few abstractions (eg; a basic Mixin for event-binding, along the lines of [0]), but would prefer not to have a framework that "does too much" or has much magic, at least until it's very widely-used.
[0] http://blog.hertzen.com/post/102991359167/flux-inspired-reac...
I'm a little worried about finding a good answer to the Flux Dispatcher's elegant `waitFor`, but I have a few ideas that I think could handle that well. I'm also worried about "stream spaghetti", especially having streams defined outside of a central `Actions.js`. I'm not yet sure how to elegantly handle server-syncing, though again, I have a few ideas (and Marty seems to provide some too). Lastly, I don't know the performance characteristics of Bacon or RxJS.
Personally, I've been playing around with Bacon.js (or RxJS) instead of the Flux dispatcher. Using `Bacon.update` in conjunction with Facebook's Immutable.js seems really promising. The outcome is a far more functional approach.
A quick and dirty example: https://gist.github.com/rattrayalex/dee40d86813bcaa9de80