react-native-macos/Libraries/Animated/AnimatedImplementation.js

741 строка
20 KiB
JavaScript
Исходник Обычный вид История

/**
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @flow
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
* @format
*/
'use strict';
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const {AnimatedEvent, attachNativeEvent} = require('./AnimatedEvent');
const AnimatedAddition = require('./nodes/AnimatedAddition');
const AnimatedDiffClamp = require('./nodes/AnimatedDiffClamp');
const AnimatedDivision = require('./nodes/AnimatedDivision');
const AnimatedInterpolation = require('./nodes/AnimatedInterpolation');
const AnimatedModulo = require('./nodes/AnimatedModulo');
const AnimatedMultiplication = require('./nodes/AnimatedMultiplication');
const AnimatedNode = require('./nodes/AnimatedNode');
const AnimatedSubtraction = require('./nodes/AnimatedSubtraction');
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const AnimatedTracking = require('./nodes/AnimatedTracking');
const AnimatedValue = require('./nodes/AnimatedValue');
const AnimatedValueXY = require('./nodes/AnimatedValueXY');
const DecayAnimation = require('./animations/DecayAnimation');
const SpringAnimation = require('./animations/SpringAnimation');
const TimingAnimation = require('./animations/TimingAnimation');
const createAnimatedComponent = require('./createAnimatedComponent');
import type {
AnimationConfig,
EndCallback,
EndResult,
} from './animations/Animation';
import type {TimingAnimationConfig} from './animations/TimingAnimation';
import type {DecayAnimationConfig} from './animations/DecayAnimation';
import type {SpringAnimationConfig} from './animations/SpringAnimation';
import type {Mapping, EventConfig} from './AnimatedEvent';
import AnimatedColor from './nodes/AnimatedColor';
export type CompositeAnimation = {
start: (callback?: ?EndCallback) => void,
stop: () => void,
reset: () => void,
_startNativeLoop: (iterations?: number) => void,
_isUsingNativeDriver: () => boolean,
...
};
const add = function (
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
a: AnimatedNode | number,
b: AnimatedNode | number,
): AnimatedAddition {
return new AnimatedAddition(a, b);
};
const subtract = function (
a: AnimatedNode | number,
b: AnimatedNode | number,
): AnimatedSubtraction {
return new AnimatedSubtraction(a, b);
};
const divide = function (
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
a: AnimatedNode | number,
b: AnimatedNode | number,
): AnimatedDivision {
return new AnimatedDivision(a, b);
};
const multiply = function (
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
a: AnimatedNode | number,
b: AnimatedNode | number,
): AnimatedMultiplication {
return new AnimatedMultiplication(a, b);
};
const modulo = function (a: AnimatedNode, modulus: number): AnimatedModulo {
return new AnimatedModulo(a, modulus);
};
const diffClamp = function (
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
a: AnimatedNode,
min: number,
max: number,
): AnimatedDiffClamp {
return new AnimatedDiffClamp(a, min, max);
};
const _combineCallbacks = function (
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
callback: ?EndCallback,
config: $ReadOnly<{...AnimationConfig, ...}>,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
) {
if (callback && config.onComplete) {
return (...args) => {
config.onComplete && config.onComplete(...args);
callback && callback(...args);
};
} else {
return callback || config.onComplete;
}
};
const maybeVectorAnim = function (
value: AnimatedValue | AnimatedValueXY | AnimatedColor,
config: Object,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
anim: (value: AnimatedValue, config: Object) => CompositeAnimation,
): ?CompositeAnimation {
if (value instanceof AnimatedValueXY) {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const configX = {...config};
const configY = {...config};
for (const key in config) {
const {x, y} = config[key];
if (x !== undefined && y !== undefined) {
configX[key] = x;
configY[key] = y;
}
}
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const aX = anim((value: AnimatedValueXY).x, configX);
const aY = anim((value: AnimatedValueXY).y, configY);
// We use `stopTogether: false` here because otherwise tracking will break
// because the second animation will get stopped before it can update.
return parallel([aX, aY], {stopTogether: false});
} else if (value instanceof AnimatedColor) {
const configR = {...config};
const configG = {...config};
const configB = {...config};
const configA = {...config};
for (const key in config) {
const {r, g, b, a} = config[key];
if (
r !== undefined &&
g !== undefined &&
b !== undefined &&
a !== undefined
) {
configR[key] = r;
configG[key] = g;
configB[key] = b;
configA[key] = a;
}
}
const aR = anim((value: AnimatedColor).r, configR);
const aG = anim((value: AnimatedColor).g, configG);
const aB = anim((value: AnimatedColor).b, configB);
const aA = anim((value: AnimatedColor).a, configA);
// We use `stopTogether: false` here because otherwise tracking will break
// because the second animation will get stopped before it can update.
return parallel([aR, aG, aB, aA], {stopTogether: false});
}
return null;
};
const spring = function (
value: AnimatedValue | AnimatedValueXY | AnimatedColor,
config: SpringAnimationConfig,
): CompositeAnimation {
const start = function (
animatedValue: AnimatedValue | AnimatedValueXY | AnimatedColor,
configuration: SpringAnimationConfig,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
callback?: ?EndCallback,
): void {
callback = _combineCallbacks(callback, configuration);
const singleValue: any = animatedValue;
const singleConfig: any = configuration;
singleValue.stopTracking();
if (configuration.toValue instanceof AnimatedNode) {
singleValue.track(
new AnimatedTracking(
singleValue,
configuration.toValue,
SpringAnimation,
singleConfig,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
callback,
),
);
} else {
singleValue.animate(new SpringAnimation(singleConfig), callback);
}
};
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return (
maybeVectorAnim(value, config, spring) || {
start: function (callback?: ?EndCallback): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
start(value, config, callback);
},
stop: function (): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
value.stopAnimation();
},
reset: function (): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
value.resetAnimation();
},
_startNativeLoop: function (iterations?: number): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const singleConfig = {...config, iterations};
start(value, singleConfig);
},
_isUsingNativeDriver: function (): boolean {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return config.useNativeDriver || false;
},
}
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
);
};
const timing = function (
value: AnimatedValue | AnimatedValueXY | AnimatedColor,
config: TimingAnimationConfig,
): CompositeAnimation {
const start = function (
animatedValue: AnimatedValue | AnimatedValueXY | AnimatedColor,
configuration: TimingAnimationConfig,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
callback?: ?EndCallback,
): void {
callback = _combineCallbacks(callback, configuration);
const singleValue: any = animatedValue;
const singleConfig: any = configuration;
singleValue.stopTracking();
if (configuration.toValue instanceof AnimatedNode) {
singleValue.track(
new AnimatedTracking(
singleValue,
configuration.toValue,
TimingAnimation,
singleConfig,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
callback,
),
);
} else {
singleValue.animate(new TimingAnimation(singleConfig), callback);
}
};
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return (
maybeVectorAnim(value, config, timing) || {
start: function (callback?: ?EndCallback): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
start(value, config, callback);
},
stop: function (): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
value.stopAnimation();
},
reset: function (): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
value.resetAnimation();
},
_startNativeLoop: function (iterations?: number): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const singleConfig = {...config, iterations};
start(value, singleConfig);
},
_isUsingNativeDriver: function (): boolean {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return config.useNativeDriver || false;
},
}
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
);
};
const decay = function (
value: AnimatedValue | AnimatedValueXY | AnimatedColor,
config: DecayAnimationConfig,
): CompositeAnimation {
const start = function (
animatedValue: AnimatedValue | AnimatedValueXY | AnimatedColor,
configuration: DecayAnimationConfig,
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
callback?: ?EndCallback,
): void {
callback = _combineCallbacks(callback, configuration);
const singleValue: any = animatedValue;
const singleConfig: any = configuration;
singleValue.stopTracking();
singleValue.animate(new DecayAnimation(singleConfig), callback);
};
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return (
maybeVectorAnim(value, config, decay) || {
start: function (callback?: ?EndCallback): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
start(value, config, callback);
},
stop: function (): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
value.stopAnimation();
},
reset: function (): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
value.resetAnimation();
},
_startNativeLoop: function (iterations?: number): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const singleConfig = {...config, iterations};
start(value, singleConfig);
},
_isUsingNativeDriver: function (): boolean {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return config.useNativeDriver || false;
},
}
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
);
};
const sequence = function (
animations: Array<CompositeAnimation>,
): CompositeAnimation {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
let current = 0;
return {
start: function (callback?: ?EndCallback) {
const onComplete = function (result) {
if (!result.finished) {
callback && callback(result);
return;
}
current++;
if (current === animations.length) {
callback && callback(result);
return;
}
animations[current].start(onComplete);
};
if (animations.length === 0) {
callback && callback({finished: true});
} else {
animations[current].start(onComplete);
}
},
stop: function () {
if (current < animations.length) {
animations[current].stop();
}
},
reset: function () {
animations.forEach((animation, idx) => {
if (idx <= current) {
animation.reset();
}
});
current = 0;
},
_startNativeLoop: function () {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
throw new Error(
'Loops run using the native driver cannot contain Animated.sequence animations',
);
},
_isUsingNativeDriver: function (): boolean {
return false;
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
},
};
};
type ParallelConfig = {
// If one is stopped, stop all. default: true
stopTogether?: boolean,
...
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
};
const parallel = function (
animations: Array<CompositeAnimation>,
config?: ?ParallelConfig,
): CompositeAnimation {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
let doneCount = 0;
// Make sure we only call stop() at most once for each animation
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const hasEnded = {};
const stopTogether = !(config && config.stopTogether === false);
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
const result = {
start: function (callback?: ?EndCallback) {
if (doneCount === animations.length) {
callback && callback({finished: true});
return;
}
animations.forEach((animation, idx) => {
const cb = function (endResult) {
hasEnded[idx] = true;
doneCount++;
if (doneCount === animations.length) {
doneCount = 0;
callback && callback(endResult);
return;
}
if (!endResult.finished && stopTogether) {
result.stop();
}
};
if (!animation) {
cb({finished: true});
} else {
animation.start(cb);
}
});
},
stop: function (): void {
animations.forEach((animation, idx) => {
!hasEnded[idx] && animation.stop();
hasEnded[idx] = true;
});
},
reset: function (): void {
animations.forEach((animation, idx) => {
animation.reset();
hasEnded[idx] = false;
doneCount = 0;
});
},
_startNativeLoop: function () {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
throw new Error(
'Loops run using the native driver cannot contain Animated.parallel animations',
);
},
_isUsingNativeDriver: function (): boolean {
return false;
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
},
};
return result;
};
const delay = function (time: number): CompositeAnimation {
// Would be nice to make a specialized implementation
Add explicit `useNativeDriver: false` to callsites Summary: In order to cleanup the callsites that are not using Animated's native driver, we are going to make useNativeDriver a required option so people have to think about whether they want the native driver or not. I made this change by changing [Animated.js](https://fburl.com/ritcebri) to have this animation config type: ``` export type AnimationConfig = { isInteraction?: boolean, useNativeDriver: true, onComplete?: ?EndCallback, iterations?: number, }; ``` This causes Flow to error anywhere where useNativeDriver isn't set or where it is set to false. I then used these Flow errors to codemod the callsites. I got the location of the Flow errors by running: ``` flow status --strip-root --json --message-width=0 | jq '.errors | [.[].extra | .[].message | .[].loc | objects | {source: .source, start: .start, end: .end}]' ``` And then ran this codemod: ``` const json = JSON.parse('JSON RESULT FROM FLOW'); const fileLookup = new Map(); json.forEach(item => { if (!fileLookup.has(item.source)) { fileLookup.set(item.source, []); } fileLookup.get(item.source).push(item); }); export default function transformer(file, api) { const j = api.jscodeshift; const filePath = file.path; if (!fileLookup.has(filePath)) { return; } const locationInfo = fileLookup.get(filePath); return j(file.source) .find(j.ObjectExpression) .forEach(path => { if ( path.node.properties.some( property => property != null && property.key != null && property.key.name === 'useNativeDriver', ) ) { return; } const hasErrorOnLine = locationInfo.some( singleLocationInfo => singleLocationInfo.start.line === path.node.loc.start.line && Math.abs( singleLocationInfo.start.column - path.node.loc.start.column, ) <= 2, ); if (!hasErrorOnLine) { return; } path.node.properties.push( j.property( 'init', j.identifier('useNativeDriver'), j.booleanLiteral(false), ), ); }) .toSource(); } export const parser = 'flow'; ``` ``` yarn jscodeshift --parser=flow --transform addUseNativeDriver.js RKJSModules react-native-github ``` Followed up with ``` hg status -n --change . | xargs js1 prettier ``` Reviewed By: mdvacca Differential Revision: D16611291 fbshipit-source-id: 1157587416ec7603d1a59e1fad6a821f1f57b952
2019-08-02 02:42:42 +03:00
return timing(new AnimatedValue(0), {
toValue: 0,
delay: time,
duration: 0,
useNativeDriver: false,
});
};
const stagger = function (
time: number,
animations: Array<CompositeAnimation>,
): CompositeAnimation {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
return parallel(
animations.map((animation, i) => {
return sequence([delay(time * i), animation]);
}),
);
};
type LoopAnimationConfig = {
iterations: number,
resetBeforeIteration?: boolean,
...
};
const loop = function (
animation: CompositeAnimation,
{iterations = -1, resetBeforeIteration = true}: LoopAnimationConfig = {},
): CompositeAnimation {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
let isFinished = false;
let iterationsSoFar = 0;
return {
start: function (callback?: ?EndCallback) {
const restart = function (result: EndResult = {finished: true}): void {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
if (
isFinished ||
iterationsSoFar === iterations ||
result.finished === false
) {
callback && callback(result);
} else {
iterationsSoFar++;
resetBeforeIteration && animation.reset();
animation.start(restart);
}
};
if (!animation || iterations === 0) {
callback && callback({finished: true});
} else {
if (animation._isUsingNativeDriver()) {
animation._startNativeLoop(iterations);
} else {
restart(); // Start looping recursively on the js thread
}
}
},
stop: function (): void {
isFinished = true;
animation.stop();
},
reset: function (): void {
iterationsSoFar = 0;
isFinished = false;
animation.reset();
},
_startNativeLoop: function () {
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
throw new Error(
'Loops run using the native driver cannot contain Animated.loop animations',
);
},
_isUsingNativeDriver: function (): boolean {
return animation._isUsingNativeDriver();
},
};
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
};
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
function forkEvent(
event: ?AnimatedEvent | ?Function,
listener: Function,
): AnimatedEvent | Function {
if (!event) {
return listener;
} else if (event instanceof AnimatedEvent) {
event.__addListener(listener);
return event;
} else {
return (...args) => {
typeof event === 'function' && event(...args);
listener(...args);
};
}
}
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
function unforkEvent(
event: ?AnimatedEvent | ?Function,
listener: Function,
): void {
if (event && event instanceof AnimatedEvent) {
event.__removeListener(listener);
}
}
const event = function (
argMapping: $ReadOnlyArray<?Mapping>,
config: EventConfig,
): any {
const animatedEvent = new AnimatedEvent(argMapping, config);
if (animatedEvent.__isNative) {
return animatedEvent;
} else {
return animatedEvent.__getHandler();
}
};
2015-09-04 05:29:04 +03:00
/**
* The `Animated` library is designed to make animations fluid, powerful, and
* easy to build and maintain. `Animated` focuses on declarative relationships
* between inputs and outputs, with configurable transforms in between, and
* simple `start`/`stop` methods to control time-based animation execution.
* If additional transforms are added, be sure to include them in
* AnimatedMock.js as well.
2015-09-04 05:29:04 +03:00
*
* See https://reactnative.dev/docs/animated
2015-09-04 05:29:04 +03:00
*/
module.exports = {
2015-09-04 05:29:04 +03:00
/**
* Standard value class for driving animations. Typically initialized with
* `new Animated.Value(0);`
*
* See https://reactnative.dev/docs/animated#value
2015-09-04 05:29:04 +03:00
*/
Value: AnimatedValue,
/**
* 2D value class for driving 2D animations, such as pan gestures.
*
* See https://reactnative.dev/docs/animatedvaluexy
2015-09-04 05:29:04 +03:00
*/
ValueXY: AnimatedValueXY,
/**
* Value class for driving color animations.
*/
Color: AnimatedColor,
/**
* Exported to use the Interpolation type in flow.
*
* See https://reactnative.dev/docs/animated#interpolation
*/
Interpolation: AnimatedInterpolation,
/**
* Exported for ease of type checking. All animated values derive from this
* class.
*
* See https://reactnative.dev/docs/animated#node
*/
Split up AnimatedImplementation.js Summary: AnimatedImplementation.js is getting pretty hard to navigate and reason about so I split it up into different modules. Also took the opportunity to run prettier on that code and do some minor const/let refactorings. This doesn't change any logic, mostly just moves code around and add proper imports / exports. This opens the door for further cleanup and flow type improvements but want to keep this already big PR as small as possible. Discussion points: - Should I use haste for this? Animated is pretty much a standalone module, it still uses a few haste imports but for new modules I used commonjs imports to avoid polluting the haste global namespace too much. The new modules are all internal to Animated and should not be imported externally. - We're using `requestAnimationFrame` from fbjs instead of the one available globally in RN and browsers is there a reason for that? - Should we even support web in this implementation? There is a standalone repo that exist for Animated web. Is this implementation of Animated web used internally at facebook? - Probably still related to web, we used some weird Set polyfill is that still needed? Notes: There is a small regression for docs where the type of some classes that are exported like AnimatedValue show up as CallExpression instead if Class. <img width="655" alt="screen shot 2017-08-14 at 3 19 18 am" src="https://user-images.githubusercontent.com/2677334/29261820-8f243036-809f-11e7-8bf0-0fe9f93939ca.png"> **Test plan** Tested that all Animated related examples still work in RNTester on iOS and Android. Tested that the doc is still working Ran unit tests Closes https://github.com/facebook/react-native/pull/15485 Differential Revision: D5679886 Pulled By: sahrens fbshipit-source-id: d3e9b6987ab5ff2cd20108c3b9d860c7536be8a0
2017-08-23 03:57:38 +03:00
Node: AnimatedNode,
2015-09-04 05:29:04 +03:00
/**
* Animates a value from an initial velocity to zero based on a decay
* coefficient.
*
* See https://reactnative.dev/docs/animated#decay
2015-09-04 05:29:04 +03:00
*/
decay,
2015-09-04 05:29:04 +03:00
/**
* Animates a value along a timed easing curve. The Easing module has tons of
* predefined curves, or you can use your own function.
*
* See https://reactnative.dev/docs/animated#timing
2015-09-04 05:29:04 +03:00
*/
timing,
2015-09-04 05:29:04 +03:00
/**
Add closed-form damped harmonic oscillator algorithm to Animated.spring Summary: As I was working on mimicking iOS animations for my ongoing work with `react-navigation`, one task I had was to match the "push from right" animation that is common in UINavigationController. I was able to grab the exact animation values for this animation with some LLDB magic, and found that the screen is animated using a `CASpringAnimation` with the parameters: - stiffness: 1000 - damping: 500 - mass: 3 After spending a considerable amount of time attempting to replicate the spring created with these values by CASpringAnimation by specifying values for tension and friction in the current `Animated.spring` implementation, I was unable to come up with mathematically equivalent values that could replicate the spring _exactly_. After doing some research, I ended up disassembling the QuartzCore framework, reading the assembly, and determined that Apple's implementation of `CASpringAnimation` does not use an integrated, numerical animation model as we do in Animated.spring, but instead solved for the closed form of the equations that govern damped harmonic oscillation (the differential equations themselves are [here](https://en.wikipedia.org/wiki/Harmonic_oscillator#Damped_harmonic_oscillator), and a paper describing the math to arrive at the closed-form solution to the second-order ODE that describes the DHO is [here](http://planetmath.org/sites/default/files/texpdf/39745.pdf)). Though we can get the currently implemented RK4 integration close by tweaking some values, it is, the current model is at it's core, an approximation. It seemed that if I wanted to implement the `CASpringAnimation` behavior _exactly_, I needed to implement the analytical model (as is implemented in `CASpringAnimation`) in `Animated`. We add three new optional parameters to `Animated.spring` (to both the JS and native implementations): - `stiffness`, a value describing the spring's stiffness coefficient - `damping`, a value defining how the spring's motion should be damped due to the forces of friction (technically called the _viscous damping coefficient_). - `mass`, a value describing the mass of the object attached to the end of the simulated spring Just like if a developer were to specify `bounciness`/`speed` and `tension`/`friction` in the same config, specifying any of these new parameters while also specifying the aforementioned config values will cause an error to be thrown. ~Defaults for `Animated.spring` across all three implementations (JS/iOS/Android) stay the same, so this is intended to be *a non-breaking change*.~ ~If `stiffness`, `damping`, or `mass` are provided in the config, we switch to animating the spring with the new damped harmonic oscillator model (`DHO` as described in the code).~ We replace the old RK4 integration implementation with our new analytic implementation. Tension/friction nicely correspond directly to stiffness/damping with the mass of the spring locked at 1. This is intended to be *a non-breaking change*, but there may be very slight differences in people's springs (maybe not even noticeable to the naked eye), given the fact that this implementation is more accurate. The DHO animation algorithm will calculate the _position_ of the spring at time _t_ explicitly and in an analytical fashion, and use this calculation to update the animation's value. It will also analytically calculate the velocity at time _t_, so as to allow animated value tracking to continue to work as expected. Also, docs have been updated to cover the new configuration options (and also I added docs for Animated configuration options that were missing, such as `restDisplacementThreshold`, etc). Run tests. Run "Animated Gratuitous App" and "NativeAnimation" example in RNTester. Closes https://github.com/facebook/react-native/pull/15322 Differential Revision: D5794791 Pulled By: hramos fbshipit-source-id: 58ed9e134a097e321c85c417a142576f6a8952f8
2017-09-21 09:36:11 +03:00
* Animates a value according to an analytical spring model based on
* damped harmonic oscillation.
*
* See https://reactnative.dev/docs/animated#spring
2015-09-04 05:29:04 +03:00
*/
spring,
/**
* Creates a new Animated value composed from two Animated values added
* together.
*
* See https://reactnative.dev/docs/animated#add
*/
add,
/**
* Creates a new Animated value composed by subtracting the second Animated
* value from the first Animated value.
*
* See https://reactnative.dev/docs/animated#subtract
*/
subtract,
/**
* Creates a new Animated value composed by dividing the first Animated value
* by the second Animated value.
*
* See https://reactnative.dev/docs/animated#divide
*/
divide,
/**
* Creates a new Animated value composed from two Animated values multiplied
* together.
*
* See https://reactnative.dev/docs/animated#multiply
*/
multiply,
/**
* Creates a new Animated value that is the (non-negative) modulo of the
* provided Animated value.
*
* See https://reactnative.dev/docs/animated#modulo
*/
modulo,
/**
* Create a new Animated value that is limited between 2 values. It uses the
* difference between the last value so even if the value is far from the
* bounds it will start changing when the value starts getting closer again.
*
* See https://reactnative.dev/docs/animated#diffclamp
*/
diffClamp,
2015-09-04 05:29:04 +03:00
/**
* Starts an animation after the given delay.
*
* See https://reactnative.dev/docs/animated#delay
2015-09-04 05:29:04 +03:00
*/
delay,
/**
* Starts an array of animations in order, waiting for each to complete
* before starting the next. If the current running animation is stopped, no
2015-09-04 05:29:04 +03:00
* following animations will be started.
*
* See https://reactnative.dev/docs/animated#sequence
2015-09-04 05:29:04 +03:00
*/
sequence,
/**
* Starts an array of animations all at the same time. By default, if one
* of the animations is stopped, they will all be stopped. You can override
2015-09-04 05:29:04 +03:00
* this with the `stopTogether` flag.
*
* See https://reactnative.dev/docs/animated#parallel
2015-09-04 05:29:04 +03:00
*/
parallel,
/**
* Array of animations may run in parallel (overlap), but are started in
* sequence with successive delays. Nice for doing trailing effects.
*
* See https://reactnative.dev/docs/animated#stagger
2015-09-04 05:29:04 +03:00
*/
stagger,
/**
* Loops a given animation continuously, so that each time it reaches the
* end, it resets and begins again from the start.
*
* See https://reactnative.dev/docs/animated#loop
*/
loop,
2015-09-04 05:29:04 +03:00
/**
* Takes an array of mappings and extracts values from each arg accordingly,
* then calls `setValue` on the mapped outputs.
*
* See https://reactnative.dev/docs/animated#event
2015-09-04 05:29:04 +03:00
*/
event,
2015-09-04 05:29:04 +03:00
/**
* Make any React component Animatable. Used to create `Animated.View`, etc.
*
* See https://reactnative.dev/docs/animated#createanimatedcomponent
2015-09-04 05:29:04 +03:00
*/
createAnimatedComponent,
2015-09-04 05:29:04 +03:00
/**
* Imperative API to attach an animated value to an event on a view. Prefer
* using `Animated.event` with `useNativeDrive: true` if possible.
*
* See https://reactnative.dev/docs/animated#attachnativeevent
*/
attachNativeEvent,
/**
* Advanced imperative API for snooping on animated events that are passed in
* through props. Use values directly where possible.
*
* See https://reactnative.dev/docs/animated#forkevent
*/
forkEvent,
unforkEvent,
/**
* Expose Event class, so it can be used as a type for type checkers.
*/
Event: AnimatedEvent,
};