I am not a big fan of generator functions, they hold state in an inaccessible/encapsulated way. They simply make no sense. There will be a time when we'll take them off from the language once enough people get burned by them and declare them useless.
It's like everything, designers feel compelled to add bells and whistles with the assumption that people can still decide to not use any of them. So again, my recommendation is to always make conscious decisions with respect to programming model, wiring and architecture. Throwing a shiny wrench in a well running engine, will still result in the same outcome, no matter how shiny it is.
hm, I find it is very readable, the sam node is just a loop :) The generator does not add any state here, it just waits for the next action at one point.
an async version allows you to wait for api calls to, and it is just normal code without callbacks
It looks like we are going to use sam like this for a "medium" sized project, which uses polymer and, redux-polymer. I can integrate them pretty well, it seems. redux is a given, it could be easier without, probably.
:D I went with babel, yes. The async generator is in stage3 already I think. That bind operator is not that far.
Also the queue is not doing much btw, I just need have a single item there in my current experiment. I recently saw an interesting video about programming styles, that was an inspiration too: https://www.youtube.com/watch?v=449j7oKQVkc
These issues need to be considered. For instance Angular2 offers much more control over the change detection mechanism since you get a chance to wire a pub/sub mechanism between your state representation and your view components. Only the components subscribing to the topics being updated would participate in the change detection. React/Redux don't seem to provide any mechanism like that, it's just too reactive.
The article addresses that the React principal problem is full tree rendering/comparison, and deeply nested components callback passing. But It doesn't give any solution other than using Binding.Scala which requires the use of, of course, Scala.
You may be better off implementing your rendering in straight ES6, templates literals are quite nice compared to anything I am seen. At a minimum you should be conscious of these issues when starting a react project.