react-native-macos/Libraries/Animated/nodes/AnimatedDiffClamp.js

75 строки
1.7 KiB
JavaScript
Исходник Обычный вид История

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
/**
* Copyright (c) Meta Platforms, Inc. and affiliates.
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
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
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
*
* @flow
* @format
*/
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
'use strict';
const AnimatedInterpolation = require('./AnimatedInterpolation');
const AnimatedNode = require('./AnimatedNode');
const AnimatedWithChildren = require('./AnimatedWithChildren');
import type {InterpolationConfigType} from './AnimatedInterpolation';
import type {PlatformConfig} from '../AnimatedPlatformConfig';
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
class AnimatedDiffClamp extends AnimatedWithChildren {
_a: AnimatedNode;
_min: number;
_max: number;
_value: number;
_lastValue: number;
constructor(a: AnimatedNode, min: number, max: number) {
super();
this._a = a;
this._min = min;
this._max = max;
this._value = this._lastValue = this._a.__getValue();
}
__makeNative(platformConfig: ?PlatformConfig) {
this._a.__makeNative(platformConfig);
super.__makeNative(platformConfig);
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
}
interpolate<OutputT: number | string>(
config: InterpolationConfigType<OutputT>,
): AnimatedInterpolation<OutputT> {
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 new AnimatedInterpolation(this, config);
}
__getValue(): number {
const value = this._a.__getValue();
const diff = value - this._lastValue;
this._lastValue = value;
this._value = Math.min(Math.max(this._value + diff, this._min), this._max);
return this._value;
}
__attach(): void {
this._a.__addChild(this);
}
__detach(): void {
this._a.__removeChild(this);
super.__detach();
}
__getNativeConfig(): any {
return {
type: 'diffclamp',
input: this._a.__getNativeTag(),
min: this._min,
max: this._max,
};
}
}
module.exports = AnimatedDiffClamp;