I have adapted this from a project I started working on a few days ago.

The animation loop has the following features:

• Decoupled stepping from rendering so that stepping can be done using a constant time step which is very important in any numerical integration.
• API that allows passing in pure functions.
• Pauses when browser tab is not visible (more accurately when the ticker is called too infrequently).
• Stops automatically when there are no more animations to run.
• Supports rendering with interpolation.

I would really appreciate some feedback to make sure we take this in the right direction.

API

import createAnimationLoop from './src/animationLoop';

const animationLoop = createAnimationLoop({
  // Fixed time step in seconds.
  timeStep: 1/60,

  // Slow-mo anyone? Give 0.1 a try.
  timeScale: 1,

  // Pause if we have more than this many steps worth of accumulated time.
  maxSteps: 10,

  // Function that gives the current (relative or absolute) time.
  getTime: performance.now.bind(performance),

  // Function that calls our loop when a frame can be rendered.
  ticker: window.requestAnimationFrame.bind(window)
});

const stepFn = (timeStep, state) => {
  // compute next state
};

const renderFn = (alpha, nextState, prevState) => {
  // render interpolated state
};

// Register a simulation/animation.
const unsubscribe = animationLoop.subscribe(stepFn, renderFn, initialState);

// Start the loop. Noop if the loop is running.
animationLoop.start();

// Whenever we decide that our animation has finished,
// for example when the speed is 0.
// The loop stops automatically if there are no other running animations.
unsubscribe();

Explanation

This library is basically a very simplified physics simulation engine for React. Because of this we can learn from what others have done in the gaming industry.

I have done quite a bit of reading on the subject and looked under the hood of a number of game engines before writing this animation loop. Here are some good articles on the subject.

So what is the animation loop? The animation loop is the heartbeat of our engine and is responsible for calling the function that updates our physic simulation whenever a frame can be rendered. One update cycle is called a step and in the case of browsers requestAnimationFrame dictates when a frame can be rendered.

At any given step, a physics simulation, just like this library, uses numerical integrations to compute the state of the “world” from the previous step’s state. As such, this state is only an approximation of how a similar system would behave in the real world.

In order to ensure the stability of the system and to have accurate integrations it is important to do the stepping in fixed time increments or fixed time step. The problem with requestAnimationFrame is that it gets called at irregular (many times dramatic) intervals.

Step

In order to solve this problem stepping needs to be decoupled from rendering. The way this works is whenever rAF is called we accumulate time. When enough time is accumulated we advance our simulation. If for example at any point in time we have accumulated 35ms and our chosen time step is 16.6ms then the system will advance by 2 steps in one frame.

Render

When it’s time to render, we inevitably run into an awkward situation where our world stays the same for 2 frames in a row when not enough time accumulates to make a step. Many times this is followed by a frame in which two steps are made. This leads to an irritating jitter when rendered. The solution is straightforward though. Knowing the current and previous state as well as the unused accumulated time, we can interpolate all values resulting in buttery smooth animations.

Time Step

The time step has a direct impact on the progression of the simulation. The lower the time step, the more accurate and stable the simulation gets. The higher the time step, the more brittle it becomes. In my experience the system becomes very unstable at any time step above 1/20 seconds or 0.05 ms with objects flying everywhere and does not noticeably improve accuracy for time steps below 1/120 seconds or 0.008 ms. Remember changing the time step does not mean a change in the rendered FPS. It just means the simulation does more or less steps per frame. What it does mean however, is that it impacts performance. A higher time step means more performance at the expense of stability and accuracy. I think a safe bet is a time step of 1/60.

React-animation is taken on npm. Let's find a better name for it.

Current suggestions:

• React-Spring (not sure, we might add Decay component later)
• React-Motion
• React-Move
• Reanimation
• React-Tween

Sort of related to #100

It is OK now to check current value if you are using default spring preset. But if I am using something like wobbly and animate height, I can easily get zero height while animation is far from being finished (then it goes to negative height, but that is a different story).

So if I think that my animation is done when height equals 0 and want to unmount element, that is not actually true and on next RAF component is shown again but with a very little height. And again and again.

I am pretty sure we had this discussion somewhere else, but could not find a separate issue for this.

I would like to see API in this way:

<Motion>
  {(style, {isFinished}) => console.log(isFinished)}
</Motion>

Passing another object to render function will not break current API, and will potentially allow us to pass more fields, not only isFinished but exposing some RM internal state (maybe related to #219)

I don't intend for this to land until after I've used it and made sure we're solving the right problem, but I'm opening this now so @chenglou can play with it (and maybe add Flow if there are places I've missed).

See also #235.

This only concerns animating a single spring for now. I need to prototype a bit more on the springs with dependencies (e.g. chat heads, where the destination of the second head is the current position of the first head) and TransitionSpring, but I think this new Spring is cool enough to stay even if the other solutions don't work out. (props names are temporary. Not important right now)

<Spring to={{top: 10, left: 20}}>Hi</Spring> That's your new basic spring. It renders to a div and transfers all the props. to is constrained to recognized CSS attributes (will provide injectable defaults for different platforms). Will intelligently not interpolate non-interpolable/unrecognized attributes. A few major advantages:

• Does manual DOM manipulation under the hood and skips React's render (a-la Animated). Better perf and since this spring's a very common use-case, lots of potential perf boost here. Heck, screw all of this, let's just use Velocity.js or something under the hood =).
• Can interpolate from height: auto; by reaching into the DOM to set an initial value. #62
• Color interpolation (color, backgroundColor) comes for free without needing to expose a helper. Same for interpolating "10%" strings. #85
• Spring precision/error margin are implicitly configured; e.g. left will be rounded to integer and when the spring wobbling distance is around 1 px we'll stop right away because there's no point to keep going. #100.
• Interpolating many springs: none of our business anymore. map through some random arrays and return your Spring with the desired configuration each time. This is not true for dependent springs. I'm still thinking of a clean API for that.
• No more vendor prefix, e.g. if you provide transition, we'll add WebkitTransition for you under the hood.

To configure the spring stiffness and damping: <Spring to={{top: config(10, 120, 17), left: 20}}>Hi</Spring> 120 being stiffness and 17 being damping. Function params format subject to change depending on what's concise and clear. If every attribute has the same config, we could accept a config prop on the spring itself for convenience. What the return value of config(10, 120, 17) is doesn't matter. You don't really read into the anyway. This also kills the special config: [] to signal that you want to jump to the final value straight away. We could provide a clearer stop(destValue) instead. Again, name and signature subject to change.

An initial prop is exposed (equivalent of defaultValue right now).

As you can see, it's not that much of a departure from the current basic Spring API: you were probably already using something similar. I'm having a bit of trouble figuring out how the perf that comes from skipping render will cooperate with dependent springs or TransitionSpring (seems like with a child-function you kind of have to re-render the wrapper every time), brainstorming welcome.

I have the following (simplified) structure:

    <DumbWrapperComponent>
      <Messages/>  (listens to MesagesStore)
      <OtherUI/>     (listens to UIStore)
    </DumbWrapperComponent>

Messages and OtherUI have two distinct stores they're listening to, so they (should) render independently of each other. OtherUI has some draggable elements using ReactMotion for smooth animation and an 'Add Message' button which adds a message to Messages using Flux pattern. It all works fine except for a case when you click the 'Add Message' button quickly after dragging something so the animation is still running. I get "Error: Invariant Violation: Expected flush transaction's stored dirty-components length (1) to match dirty-components array length (2)"

I'm going to check it more thoroughly in a second and update/close if I find the solution but I thought I'd ask just as a sanity check - is this an expected and known behavior/limitation of React Motion?

I'm still using v0.2.7 if that matters.

Context: implementing/implemented callback for when a component finishes transitioning. We're not sure yet whether the callback will be applied on the whole component, on the a single style object, or per style value (current implantation for Motion is on the whole component/style object (same thing for Motion since a Motion component has a single style obj), so keep that in mind if you want a future-proof name for this (or not. Maybe it's better to have a specific name for our current implementation, and a different one for a different, e.g. per-value callback).

Potential names:

• onEnd
• onRest
• onDone
• onStop
• onFinish
• ???

Go ahead!

As part of #13. Independent from the code itself. Only had to fix same syntax issue in Spring, since parser crashed on that one.

When lib files are moved, these configs should be updated accordingly, but for the moment everything works fine.

I was having a great deal of trouble understanding the API, so I've attempted to make the type signatures much clearer in the docs. I may have got some things wrong though. I originally stuck to the Haskell-esque syntax for the type signatures, but opted to switch to TypeScript syntax because it allows you to annotate the function parameters. I hope this helps!

Rendered

Hi Chenglou,

Here are my thoughts after integrating the Spring API yesterday:

• Users of my components will have trouble understanding stiffness/damping compared to the slightly more intuitive and common curve/duration.
• In some instances the Spring animation doesn't return to a stable state.
• Would be great to see some predefined constants like you get with most curve animation libraries (e.g. stiff_spring, wobbly_spring).

I love the API design but would really like to have the choice to use a Tween object. I know it's got issues like you mentioned in the React-Europe talk but I don't think it would hurt to provide a traditional approach to animation as well.

let Demo = React.createClass({
  getInitialState() {
    return {open: false};
  },

  handleMouseDown() {
    this.setState({open: !this.state.open});
  },

  render() {
    return (
      <div>
        <button onMouseDown={this.handleMouseDown}>Toggle</button>
        <Tween endValue={{val: this.state.open ? 400 : 0, config: [EasingTypes.easeInOutQuad, 2]}}>
          {interpolated =>
            <div className="demo0-block" style={{
              transform: `translate3d(${interpolated.val}px, 0, 0)`,
            }} />
          }
        </Tween>
      </div>
    );
  }
});

I think the best way to move animation forward in react is to make it dead simple to experiment with the animation on a set of potentially multipage actions.

For example, let's say I have an admin panel, I have a certain flow to getting from listing to a form and then performing an action and I want to set some nice animations for doing all that, ideally by setting a crude version then experimenting by recording and replaying back.

This can potentially benefit more then just the developer.

For simplicity sake, lets assuming we have the following, as their not that hard (probably) and some technologies related to them are still surfacing as we speak or in their growing stages (eg. baobab v2).

• a single application state tree like structure (eg. baobab) that holds all the data in the application
• we save animation configuration exclusively in the tree structure and its inteded to be constant for the lifecycle of the application (except when we're intentionally editing in development)
• we have a timeline system that can save all changes made to said structure from one predefined start point to a predefined end point
• we have a simple interface for viewing and editing nodes in the tree (ie. for our purposes mainly animation configuration nodes)
• we can reset the entire state with out any page reload and we can also save to localStorage and reload

Problems & Questions

How could we go about saving animation state to said structure? (with out key paths everywhere) How can we go about triggering animation state from said structure? How can we go about storing animation configuration in the state structure? How can we go about reading in a human understandable format the configuration from the tree? How can we go about resetting everything? (ie. stop/replay) How do we handle animation that's applied to many items? (ie. shared components that appear in multiple areas)

Please add support for prefers-reduced-motion. If a site visitor's browser indicates that they are bothered by animation, as evidenced by them having set prefers-reduced-motion to reduce, then don't serve them animation; jump immediately to the end state without animation.

Hi! While upgrading some dependencies in our project, I noticed an issue with the metadata for this package that caused our build process to crash after the upgrade.

Specifically, according to the npm documentation the author field in package.json should designate a single person and be either a JSON object or a string. This package currently has "author": ["nkbt", "chenglou"], which violates the spec and crashes some tools that try to parse it according to the spec (such as https://github.com/pivotal/LicenseFinder). While such tools should probably be made more robust, the current package.json for this project is (AFAICT) still invalid.

Probably the simplest fix would be to change the key from "author" to "contributors", which has the same semantics but allows multiple values. It could also be a good idea to validate the package.json against https://www.npmjs.com/package/package.json-schema.

Bumps express from 4.16.3 to 4.18.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps qs from 6.2.3 to 6.2.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps loader-utils from 1.1.0 to 1.4.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.