alexreardon / raf-stub Goto Github PK

Currently the versioning for this library is not respecting SemVer

Current scheme:

X.Y.Z

• X: ??
• Y: breaking changes
• Z: patches and new features

SemVer

X.Y.Z (major, minor, patch)

• X: breaking changes
• Y: new features (non breaking)
• Z: patches

Currently this is the api for replaceRaf:

type ReplaceRafOptions = {
    duration?: number,
    startTime?: number
};

export function replaceRaf(roots?: Object[] = [], { duration = defaultDuration, startTime = now() }: ReplaceRafOptions = {}) 

However, ReplaceRafOptions should have always had duration named as frameDuration. Adding flow types exposed this issue.

I will change ReplaceRafOptions to use frameDuration rather than duration. I am unsure if I should support the old API or create a major version bump. A major version bump could be a nice opportunity to cleanup the legacy replaceRaf api: function replaceRaf(...rest: Array<Object>): void.

The vanilla window.requestAnimationFrame function doesn’t just call the callback with no arguments, it provides a DOMHighResTimeStamp argument representing the time for when requestAnimationFrame starts to fire callbacks on that frame (see the MDN documentation about it). Currently, callbacks that use this argument cannot be tested with raf-stub.

An easy fix for this would be to store window.performance.now() in a variable at the beginning of the step function and pass that variable to every callback in the forEach loop. However, this would probably not be very helpful in most cases that use the timestamp, as those usually rely on time difference rather than frame count to time the animation. The “easy fix” would really only be a framerate controller.

So I think the ideal solution would be to keep track of a fake animation time globally and have step accept an optional argument with a default value of 1000 / 60, representing the fake time elapsed since the last frame.

Otherwise, great job! This is a very interesting tool for debugging animations. ^^

I have noticed that this test has failed on occasion across two builds:

• https://travis-ci.org/alexreardon/raf-stub/builds/187564225
• https://travis-ci.org/alexreardon/raf-stub/builds/185904496

Test definition:

it('should allow you to flush callbacks with a provided frame duration', () => {
  const parent = sinon.spy(() => {
    api.add(child);
  });
  const child = sinon.stub();
  const customDuration = frameDuration * 10;

  api.add(parent);
  api.flush(customDuration);

  expect(parent.calledWith(startTime + customDuration)).to.be.true;
  expect(child.calledWith(startTime + 2 * customDuration)).to.be.true;
});

Error message:

1) instance flush should allow you to flush callbacks with a provided frame duration:
     AssertionError: expected false to be true
      at Context.<anonymous> (test/index.js:326:13)

Thanks for the lib @alexreardon

When importing this module in TS webpack throws a wobbly using esnext modules:

ERROR in ./node_modules/raf-stub/src/index.js
Module parse failed: Unexpected token (5:5)
You may need an appropriate loader to handle this file type.
| import { defaultFrameDuration } from './constants';
| 
| type Stub = {|
|     add: (cb: Function) => number,
|     remove: (id: number) => void,

Is it possible to transition to flow comment types or if you have any other ideas?

Happy to raise a PR for comment types

Currently greenkeeper does not support yarn: greenkeeperio/greenkeeper#314. Until it does there is no point bumping package dependencies as they are not used in the build

Is there any technical reason to lock it down to 6.7 ??

error [email protected]: The engine "node" is incompatible with this module. Expected version "^6.7.0"

current version

node -v
v7.3.0

It would be great if the build could also have a metric for flow type coverage

This was originally removed as there was some issues with codecov.io. However, it looks like those have been resolved