The main problems were with setValue and interpolate so I made them not available internally and exposed it with addition class. In internal operation InternalAnimatedValue is used and it's not causing dependencies' cycles.
Changed logic of exposing nodes. Now there's no need to import whole base.js for wrapped nodes.
* add useCode hook as an alternative to Animated.Code
* Add useCode documentation to README
Added a short description of Animated.useCode to the README, with both a function signature and an example of its use in a component.
Added improved error messages to Animated.Code when wrong props are passed to the component. Also, unified the types both the exec and children can accept. Both `exec` and `children` can now accept a node or a function returning a node.
Example:
```
const node = block([...]);
const nodeFn = () => node;
// All of the following lines are now valid
<Animated.Code exec={node} />
<Animated.Code exec={nodeFn} />
<Animated.Code>{node}</Animated.Code>
<Animated.Code>{nodeFn}</Animated.Code>
```
I've created some tests to assert the error is being thrown when wrong prop types are provided. I've create a separate suite for testing Animated* components. I'm not really skilled in writing tests so this might be wrong.
Also, I've added the `jsx-uses-react` eslint rule to prevent false negatives when React is imported without using it directly, as JSX is using React implicitly. More info here: https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-uses-react.md
Proptypes are no longer supported by RN and has been removed from core of RN in favor of Flow.
It fixes this commit and merging it was a mistake.
e75377aa98
## 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.
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
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.
## 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.
When reanimated component gets re-rendered we used to create new Prop node which in turn created Style and Transform node if present.
This turns out to be a huge waste of resources as new nodes would generate additional bridge traffic while they often represent the same prop mapping.
We now extract prop, style and transform node configuration which uniquely represents node behavior and try to match that with node used previously. If config matches we reuse the node instead of creating a new one.
This also fixes#13
This PR adds new "round" and "color" nodes.
Color nodes can be used to map to color props in view (e.g. backgroundColor)
Round is required for the color math to function properly (each color component needs to be an integer).
Added demo app where you can pan view around that changes color depending on the position on HSV palette.
