First thank you for this great driver!

It would be great to have diagrams exported as images (seehttps://github.com/ReactiveX/rxjs/blob/master/doc/writing-marble-tests.md#generating-png-marble-diagrams-from-tests) for several reasons:

• living documentation
• introducing Cycle.js concepts and ideas to developers
• awesomeness!

Do you think this could be part of the responsibility of this project?

From what I saw, it seems that it could be achieved easily by reusing https://github.com/ReactiveX/rxjs/tree/31dfc7324bf51b98df6678f072b7a3bd4c0b5888/spec/helpers/tests2png however I have not much experience with other reactive libraries than rxjs and don't know it it would be difficult to port it with adapters for most and xstream.

eg. sources.Time.periodic(1000) pauses when I switch tabs and resumes when I come back due to requestAnimationFrame.

@staltz's new html-looks-like library looks like a lot of fun.

I want to be able to use it with @cycle/time.

https://github.com/staltz/html-looks-like

In order to do this, we might need to support custom assertion functions. This is probably an overall positive step for flexibility, and brings us more in line with how RxJS works.

Here's an example of what usage might look like:

import {mockDOMSource, makeHTMLDriver} from '@cycle/dom';
import htmlLooksLike from 'html-looks-like';

import {Counter} from '../src/counter';

const htmlDriver = makeHTMLDriver();

function toHTML (vtree$) {
  return htmlDriver(vtree$).elements();
}

describe('Counter', () => {
  it('increments and decrements in response to clicks', (done) => {
    const Time = mockTimeSource();

    const expectedHTML = (count) => `
      <div class="counter">
        {{ ... }}
        <div class="count">Count: ${count}</div>
        {{ ... }}
      </div>
    `;

    const addClick$      = Time.diagram(`---x--x-------x--x--|`);
    const subtractClick$ = Time.diagram(`---------x----------|`);
    const expectedHTML$  = Time.diagram(`0--1--2--1----2--3--|`).map(expectedHTML);

    const DOM = mockDOMSource({
      '.add': {
        click: addClick$
      },

      '.subtract': {
        click: subtractClick$
      },
    });

    const counter = Counter({DOM});

    const HTML$ = counter.DOM.compose(toHTML);

    Time.assertEqual(HTML$, expectedHTML$, htmlLooksLike.bool)

    Time.run(done);
  });
});

As already mentioned in #21
Would simplify tests like here (cyclejs-community/create-cycle-app-flavors#16)
Important would be that the Promise resolves to true in the passing case.

As discussed in #16 it would be useful to have a document that fully specifies the behaviour of marble diagrams, possibly in a way that would allow us to unify the behaviour of RxJS and @cycle/time's diagrams.

This could be a markdown file in this repository or a separate repository altogether.

Currently, the mock time source passes the combined assertion errors as an argument to done. This causes the test to pass when using Jasmine 2 (default for Jest), because Jasmine has a separate done.fail function. Would you be interested in checking for the existence of and passing to error to done.fail before trying to pass the error to done? I can also submit a PR myself if you're short on time :)

It would be nice if we could allow users to specify additional operators to be available with @cycle/time, so that users could create their own operators or so that we could ship some operators that are uncommonly used but can be added as needed.

One possible way we could do this is to create a makeTimeDriver function that takes an extras object:

import {makeTimeDriver} from `@cycle/time`;
import tween from `@cycle/time/extra/tween`;

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

mockTimeSource could also take this extras object.

An extra would need to be a function that takes in the schedule object (used for adding to the schedule, like a listener), the currentTime() function, and possibly a function to get the time source (to allow building on top of core operators). It would need to return a function.

One thing I am unsure of is how to make this play nicely with TypeScript. Perhaps there is a way to tell TypeScript that there will be extra operators in the TimeSource from the provided extras object but I am unsure.

This is a prerequisite for #13.

It would be really cool to be able to throttle a stream not based on a fixed time value, but instead using requestAnimationFrame(). Something like the Pythagoras Tree could be rendered at the most speed the browser can handle instead of under-/overusing the renderer

... when RxJS and Xstream/extras include similar?

That was my 1st question. The testing stuff is awesome.

Which test frameworks are currently supported? Please specify.
I'd like to use ava
Would just require support for async/await for Time.run() I think?
Thanks.

// Ava test
test('Counter', async t => {
  const Time = mockTimeSource();

  Time.assertEqual(count$, expectedCount$)

  await Time.run();
});

In the code for time-driver.js, I see the following

_runVirtually: function (done, timeToRunTo) so it looks like it currently requires a done callback argument for proper async

But then I also see time-source where the cb argument is optional

export interface MockTimeSource extends TimeSource {
  // ...
  run (cb?: (err?: Error) => void): void;
}

I wasn't sure if this issue should go here or in the main cyclejs repo - please let me know if I need to move it.

mock-time-source.ts uses package combine-errors, which uses package lodash.uniqby which then pulls in a bunch of extra lodash stuff which bloats the bundle considerably if you're not already using lodash.

lodash.uniqby brings in lodash.iteratee (56kb) among others - all in all it adds up to almost 100kb of extra code that won't be used:

This wouldn't be a problem if we were able to use ES module versions of the packages (rather than bundled cjs) and a treeshaking/dead code eliminating bundler as in theory it could remove the unused modules.

My solution is to split the mock vs non-mock timesource files so in your tests you can pull in the mock time source (including any dependencies needed, e.g. lodash) but your app can pull in the skinnier time driver alone.
Here's an example:
https://github.com/cyclejs/time/compare/master...willheslam:separate-test-deps?expand=1

What do you think?

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

As described here requestIdleCallback can be used to perform low priority work (like an infinite scroller).
It would be cool to be able to have a throttleIdleCallback function, kinda like this:

const distance$ = DOM.select('document').events('scroll')
    .map(ev => ev.view)
    .map(win => win.document.body.offsetHeight - win.innerHeight - win.scrollTop);

const append$ = xs.merge(
    //This will emit within the next 1.5 seconds when the browser has not much to do
    distance$.filter(d => d < 1500 && d > 500).compose(Time.throttleIdleCallback(1500)),

    //This will fire if we are getting to close to the bottom, so we can force it to happen
    distance$.filter(d => d <= 500)
).mapTo(/* HTTP request and insertion */)

I dont know if this is

1. possible
2. useful
3. better done in another way

What do you think @Widdershin?

This issue is for any feedback you have while reading the README.

Something confusing? Badly explained? Not discussed at all?

If you have any thoughts I would love to hear them.

This one's a bit silly, but I encountered it by accident.

I've got these two tests. The first succeeds as expected, the second fails. The second diagram is a bit silly, but I expected it to work, since it does seem to accept the diagram, but then messes up the time, maybe converting the two parentheses into ticks or something. The parentheses aren't expected values either. If this syntax is not supported, maybe it should fail.

import { mockTimeSource } from "@cycle/time";
import xs from "xstream";

describe("@cycle/time learning test", () => {
    it("two periodic values", done => {
        const Time = mockTimeSource();

        const stream$ = Time.periodic(80);
        const expected$ = Time.diagram(`----0---1---`);

        Time.assertEqual(stream$, expected$);
        Time.run(done); // OK :)
    });

    it('two periodic with the first being a single "simultaneous" value', done => {
        const Time = mockTimeSource();

        const stream$ = Time.periodic(80);
        const expected$ = Time.diagram(`----(0)---1-`);

        Time.assertEqual(stream$, expected$);
        Time.run(done); // Not OK? :(
    });
});

Error:

 FAIL  src/cycle/time.test.js
  ● @cycle/time learning test › two periodic with the first being a single "simultaneous" value

    
    Expected
    
    ----0-----1
    
    Got
    
    ----0---1
    
    Failed because:
    
     * Right value at wrong time, expected at 200 but happened at 160 (1)
     * Expected value at time 200 but got different value at 160

    Diff (actual => expected):
      
      
      
      
          
      at checkEqual (node_modules/@cycle/time/dist/assert-equal.js:59:24)
      at Object.assert.finish (node_modules/@cycle/time/dist/assert-equal.js:72:17)
      at node_modules/@cycle/time/dist/mock-time-source.js:20:62
      at Array.forEach (native)
      at finish (node_modules/@cycle/time/dist/mock-time-source.js:20:20)
      at node_modules/@cycle/time/dist/mock-time-source.js:74:74
      at Immediate.processEvent (node_modules/@cycle/time/dist/run-virtually.js:8:9)
      at runCallback (timers.js:572:20)
      at tryOnImmediate (timers.js:550:5)
      at processImmediate [as _immediateCallback] (timers.js:529:5)

I've written the following Time driver learning test (using Jest), because I couldn't figure out why my own test was failing. The below test fails unexpectedly. Is this a bug, or should this behaviour be explained in the documentation perhaps?

import { mockTimeSource } from "@cycle/time";
import xs from "xstream";

describe("@cycle/time learning test", () => {
    // [...]

    it("supports delayed value with start-with value", () => {
        const Time = mockTimeSource();

        const actual$ = xs.of("B").compose(Time.delay(40)).startWith("A");
        const expected$ = Time.diagram(`A-B|`);

        Time.assertEqual(actual$, expected$);

        return new Promise((resolve, reject) => {
            Time.run(err => err ? reject(err) : resolve());
        });
    });
});

Unexpected failure:

 FAIL  src/cycle/__tests__/time.test.js
  ● @cycle/time learning test › supports delayed value with start-with value

    
          Expected
    
          A-B|
    
          Got
    
          A-|
    
          Failed because
    
          Length of actual and expected differs
      
      
            
          
      at checkEqual (node_modules/@cycle/time/dist/assert-equal.js:53:24)
      at Object.xstream_1.default.combine.addListener.complete (node_modules/@cycle/time/dist/assert-equal.js:79:17)
      at Stream._c (node_modules/xstream/index.js:917:18)
      at CombineListener._c (node_modules/xstream/index.js:162:19)
      at MemoryStream.Stream._c (node_modules/xstream/index.js:917:18)
      at Object.complete (node_modules/@cycle/time/dist/record.js:14:25)
      at Stream._c (node_modules/xstream/index.js:917:18)
      at Stream.shamefullySendComplete (node_modules/xstream/index.js:1664:14)
      at Immediate.processEvent (node_modules/@cycle/time/dist/run-virtually.js:33:35)
      at runCallback (timers.js:570:20)
      at tryOnImmediate (timers.js:550:5)
      at processImmediate [as _immediateCallback] (timers.js:529:5)

Installed packages:

$ grep -A1 -E '^"?(@cycle|jest|xstream)' yarn.lock | grep -vE '^--$'
"@cycle/[email protected]":
  version "4.2.0"
"@cycle/base@^4.3.0":
  version "4.3.0"
"@cycle/time@^0.4.0":
  version "0.4.0"
"@cycle/[email protected]":
  version "3.1.0"
"@cycle/xstream-run@^4.2.0":
  version "4.2.0"
jest-changed-files@^17.0.2:
  version "17.0.2"
jest-cli@^18.1.0:
  version "18.1.0"
jest-config@^18.1.0:
  version "18.1.0"
jest-diff@^18.1.0:
  version "18.1.0"
jest-environment-jsdom@^18.1.0:
  version "18.1.0"
jest-environment-node@^18.1.0:
  version "18.1.0"
jest-file-exists@^17.0.0:
  version "17.0.0"
jest-haste-map@^18.1.0:
  version "18.1.0"
jest-jasmine2@^18.1.0:
  version "18.1.0"
jest-matcher-utils@^18.1.0:
  version "18.1.0"
jest-matchers@^18.1.0:
  version "18.1.0"
jest-mock@^18.0.0:
  version "18.0.0"
jest-resolve-dependencies@^18.1.0:
  version "18.1.0"
jest-resolve@^18.1.0:
  version "18.1.0"
jest-runtime@^18.1.0:
  version "18.1.0"
jest-snapshot@^18.1.0:
  version "18.1.0"
jest-util@^18.1.0:
  version "18.1.0"
[email protected]:
  version "18.2.0"
jest@^18.1.0:
  version "18.1.0"
xstream@*, xstream@^10.2.0:
  version "10.2.0"

I think I will investigate this once cycle unified is released, as I think it will be a fair bit easier then.

It would be nice if we could do:

import {timeDriver, TimeSource} from '@cycle/time';

Current workaround:

import {timeDriver} from '@cycle/time';
import {TimeSource} from '@cycle/time/dist/time-source';

I think this works correctly for rxjs and most, just not xstream 😿