## Motivation
I attach example illustrating this issue. The problem appears when we use `evaluateOnce` method (e.g. via `setValue`) for updating node which could be detached in the same time.
## Changes
I observe I haven't deeply understood flow of reanimataed while writing this logic. Actually always node representing evaluation should not have children which has be informed about changes (it's pointless). In fact, always node has to be a child of these nodes, because we want to have these nodes attached (make them not sensitive for other detachments), because they states input for given node.
This commit fix error "Could not resolve all artifacts for configuration ':react-native-reanimated:classpath'". I just up grade version and add google repo
Fix Mapping declaration since [native event can be a function](https://github.com/kmagiera/react-native-reanimated/pull/83)
Otherwise, you will get an error like this:
"Type '{ nativeEvent: ({ translationY: y, state }: { translationY: number; state: State; }) => AnimatedNode<number>; }' is not assignable to type 'Mapping'.
Probably not super important because these functions are symmetric with `Math.cos` and `Math.sin` but I thought maybe some people might find it useful.
## Motivation
On evaluating clock for the first time it was equal to zero
## Changes
Observing `_displayLink` I noticed that for the first time when it's being set, the value of `_displayLink.timestamp` (and `_displayLink.targetTimestamp` as well) was equal zero from some unknown reason.
However, I have found it pointless to look for bug here and actually cannot see why it's somehow better than `CACurrentMediaTime`.
What's more, I made `_wantRunUpdates` usable again.
Made some refactor.
With the latest react-native version RN >= 0.57 the android build tools were updated and now using `compile` in the build.gradle file generates the following error:
WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'.
It will be removed at the end of 2018. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html
Adds the `<Animated.Code>` component and a props type for a render or `exec` prop. Is it right that this should always return an `AnimatedNode<number>`?
Render prop or `exec` should be exclusive, based on how its implemented (`exec` takes precedence), but my TypeScript experience is too limited to figure that out.
Trying to use reanimated with typescript results in bunch of `Namespace 'Animated' has no exported member 'EasingFunction'` errors because `Animated.EasingFunction` is not being exported.
👋
This morning I tried testing the Examples via Snack, but since it wasn't working I tried to have them work in my local folder... and well, I ended up wanting to test with RN0.57 😅
I didn't have to modify anything about the "main" lib, but I thikn it would be good to -as a separate PR- try to update it too to newer versions of both JS and Native sides.
The changes to the gradle files have been done [following this](https://github.com/ncuillery/rn-diff/compare/rn-0.55.4...rn-0.57.0) comparison map.
I've tested it with both iOS simulator and an Android device and it works fine on both (aside from a crash I'll report separately if I can manage to repro "outside" of the Examples)
When value gets detached from all component it can be still kept in memory and attached to some other component at later time. But because we don't know when JS reference is dropped we need to delete native counterpart of the value when it gets detached. This has led to a situation in which the value was reinstantiated on the native site. In that case if the value has changed we expect it to persist that changes when it gets attached again. This wasn't happening and each time the value was instantiated we'd always use the initial value.
With this change we are solving that issue by querying the value right before we detach the native node and then we use that value to update config such that next time when it gets instantiated it uses updated value instead of the initial one.
## Motivation
I found it pretty fancy to write `nativeEvent` (or some field of `nativeEvent`) as a function which is evaluating on each event's frame.
## Changes
Because it must be done fully natively I do not relate `nativeEvent` function with any View but use list of `AlwaysNodes` instead, which may seems to be similar to `Animated.Code` and behave conceptually in the same way.
On executing code it performs "evalution" which fill required (by function) fields of `nativeEvent` by `Animated.Value`s and connect it to `AlwaysNode`. I decided to use `Proxy` to manage it, but it is not supported currently by Android because of anscient version of JSC, which is going to be replaced soon (kindly ping @pmlocek), so I have done some kind of case-specic polyfill.
merge firstly: https://github.com/kmagiera/react-native-gesture-handler/pull/287
This PR adds an implementation of Interactable.View to examples folder. The implementation is pretty feature full with the exception of alertAreas that I haven't had time yet to work on.
If there's expo used or debugger enabled RNR's `debug` node is supposed to show messages in console/terminal.
RNR should should logs only in `__DEV__` mode
+ Patch createAnimatedComponent using Set with dodgy instances from ebd0e94aab (😍)
+ Revert previously added workarounds that's been there to fix problem with animated node objects being frozen as a result of sending them over the bridge
I noticed this error when porting this code to RN implementation. Sometimes the flag is called `_refHasChanged` and sometimes `_refHasChanges` which causes it to stay true forever if set.
Edit: Actually the fact that it stays true forever hid a bug, `setNativeView` needs to always be called in `componentDidUpdate` because it is possible that `_propsAnimated` changed and the new instance does not have the view set. In this case we need to call it even if the ref did not change. `setNativeView` already no-ops if the ref is the same so no need to do any checks.
On iOS the behavior of running node updates was unpredictable for the case when new view has been attached. In such a case if it was required to run some updates (e.g. view has a transform that links to another nodes that require updates) we may ended up only running these in the next frame. The reason was that we'd use CADisplayLink to schedule animation callback but since we already run on UI thread the callback would only run in the next frame. As a result the view would first render with default params (e.g. no transform), then on the next frame the transform would update to the initial values. This was causing the view to flash with unexpected props applied for a single frame and only then be placed as expected.
In this change we force trigger onAnimationFrame callback if we suspect module operations (e.g. connect node to view) have requested updates. It does not matter if they didn't, as worse case we would run update loop twice. In that case the queues should be empty and when we run it for the second time there should be no additional computation being made.
This fix is not necessary on Android where we use ReactChoreographer. The reason is that choreographer has several buckets of callbacks that can be enqueued. We use `CallbackType.NATIVE_ANIMATED_MODULE` bucket which always runs after `DISPATCH_UI` which is used to run all module operations. So if operation requests an update the animation callback will run in the same frame in which it's been requested.
## Motivation
Logic of evaluation was strictly connected with views but it should not be like because some logic could be abstracted from views
## Changes
Add `Animated.Code` which behaves like view, but indeed is not related to any layout.
