Port xstream#tween to @cycle/time

[Widdershin]

Tween is the only time based operator in xstream that @cycle/time does not implement.

[Widdershin]

I don't want to include tween in core right now, because I think the current API surface is quite large. I want to support extra operators, so that we can provide niche operators without requiring people to bundle them.

This could look like:

import {makeTimeDriver, mockTimeSource} from '@cycle/time';
import tween from '@cycle/time/extra/tween';

const drivers = {
  Time: makeTimeDriver({extra: {tween}})
}

const mockTime = mockTimeSource({extra: {tween}});

This will also open the way up to custom operators from users.

[staltz]

Also, I'm not sure tween() is the best way for doing animations. I used it in http://matrixmultiplication.xyz and in Firefox I still get some glitches, and I have no idea yet why how the glitch happens.

[staltz]

Actually @Widdershin the glitches in matrixmultiplication might be due to the lack of rAF usage. I think tween doesn't need to be implemented in Cycle Time as long as we have something like sources.Time.burst(1500 /*ms*/) where burst returns a Stream of numbers from 0 to 1 that lasts 1500ms. With such a stream, you can interpolate those numbers using typical cartesian Math and do whatever animations you want.

In other words, the tween logic can be pure math living under a specific library which is agnostic to Cycle.js. And Cycle Time just needs to provide a burst of numbers between 0 and 1. The duration 1500ms can be measured by calling Date.now() (or some equivalent way of getting timestamps), this way we can decouple rAF framerate from animation duration.

[staltz]

PS: Ben Lesh's recent talk on animations in RxJS using rAF might be relevant as an inspiration or reference. https://www.youtube.com/watch?v=X_RnO7KSR-4 You might know most of this so it's okay to watch it in 2x.