Interesting use of a bus for each action. I'm curious why you used @setProps() instead of just storing the person object in the component state? Modifying props seems a like non "Reactish".
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`.
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...