Converted from http://plnkr.co/edit/kHrrvjSVTjIaiZpPdbbG?p=preview
See main.js for two ways to do it. To run:
- clone the gist into a web servable dir
npm install- open index.html (use
http://notfile://)
Note: Although scheduling is configurable in most.js, we haven't yet exposed an API for it. In this case, it's simple enough just to use requestAnimationFrame directly, since it's only being used at the render boundary.
@Blesh No problem at all, happy to help.
Yes. In general, event propagation in most.js is end-to-end synchronous whenever possible. Some combinators, like
delay,debounce,await, etc. will introduce asynchrony because they have to. That is, the "stuff to the left" of adelay()happens in a different call stack than the "stuff to the right" of it.So, in something like
stream.map(...).filter(...).scan(...).observe(func), for each event, themap,filter,scan, andobservewill all happen synchronously.It seems like the right point at which to introduce rAF would be just before, or inside of
observe, since it's best to do the bulk of computation before the animation frame, then do the minimum work within the frame.I've been thinking about a "scheduler hopping" API, similar to what RxJS offers, but I haven't hit a super-compelling use case for it yet. Being able to easy hop to requestAnimationFrame in
observemight be the one that pushes me over the edge, though :)I was thinking something like:
var rescheduledStream = stream.reschedule(scheduler). Any further transformations onrescheduledStreamwould then occur synchronously within whatever mechanism (rAF, etc.)schedulerused. For example:stream.map(...).filter(...).reschedule(rAFScheduler).observe(func).