Animated regular/calculated issue
I am currently having an optional interpolation depending on an optional animated value
~transform=[|
Transform.translateY(
~translateY=
Animated.(
animatedFloat(
scrollYAnimatedValue
->Option.map(scrollYAnimatedValue =>
Animated.Value.add(
state.animation,
Value.interpolate(
scrollYAnimatedValue,
Interpolation.(
config(
~inputRange=[|(-200.), 1.|],
~outputRange=
fromFloatArray([|(-200.), 1.|]),
(),
)
),
),
)
)
->Option.getWithDefault(state.animation),
)
),
),
|],
This code should work but doesn't compile, complaining that ->Option.getWithDefault(state.animation) isn't the same type as the interpolation.
Error: This expression has type
ReactNative.Animated.value(ReactNative.Animated.regular) =
ReactNative.Animated.value(ReactNative.Animated.regular)
but an expression was expected of type
ReactNative.Animated.value(ReactNative.Animated.calculated) =
ReactNative.Animated.value(ReactNative.Animated.calculated)
Type ReactNative.Animated.regular = ReactNative.Animated.regular
is not compatible with type
ReactNative.Animated.calculated = ReactNative.Animated.calculated
We should have something to tell that a regular & calculated are the same at the end, don't we?
ReactNative.Animated.value('a) is a polymorphic Animated.value type. I suggest you change the order of the execution so that the output from different branches is Transform. You might also try playing with the type system in some other way.
I suppose we could use a method to convert a value(calculated) to value(regular) but perhaps we don't really need to differentiate between those types in the first place. I had that opinion when reworking the Animated module, but as I don't know the motivation behind the differentiation in the first place, decided against raising the point as I might be missing the intention.
@grabbou Since this came from your Rebolt effort, perhaps you know the intention behind it? It appears first with https://github.com/reasonml-community/bs-react-native/commit/ccb44f47bd2be5085a1dd31a4ea379efe906ff02.
If you plug regular in functions that expect calculated (and vice versa) you’ll get runtime errors (unless something changed in more recent RN versions)
If you plug
regularin functions that expectcalculated(and vice versa) you’ll get runtime errors (unless something changed in more recent RN versions)
Do you have any concrete examples to try? Looking at function types, I'd expect chaining Interpolation.interpolate would be what causes runtime errors, such as
x -> Interpolation.interpolate(configA) -> Interpolation.interpolate(configB)
However, perhaps add or multiply can still be `(value('a), value('a)) => value('a)'.
@sgny you'd have to try. My memory might be failing me but I think those type definitions are correct.
@sgny you'd have to try. My memory might be failing me but I think those type definitions are correct.
@wokalski I've been trying and it appears that the disctinction is still necessary. Chained interpolation is fine (at least so far as not causing runtime errors), but setValue on value(calculated) is definitely not allowed, whether it is the result of interpolation or add. I was under the mistaken impression that operations such as add created a new Animated value, separate from the components (which I suppose would be mostly useless were that true), but as the result should track changes in its components, then operations such as setValue are meaningless.
TLDR; current bindings represent a subtle understanding of provided functionality.
Ok, thanks for the explanation @wokalski @sgny. I will close this issue when this will be explained in the doc to avoid future similar question :)