_offset is always undefined? about react-native-reanimated

[osdnk]

Hi, @ckknight
We wish you not to care about JS files. At the very begging proof of concept of RNR was done only in JS and then implemented in Java and ObjC. So JS code could be described as "dead" as it's not executed at all and will be removed soon I suppose.
We were basing on Animated from RN's core and there "_offset" is done right, but currently we do not support offset at all.
If you wish to implement it or have other idea how to improve RNR, PRs are welcome 😄

[ckknight]

This is still a legitimate bug that would cause the __getValue of AnimatedValue to always return NaN.

[osdnk]

Is it a bug?
We do not support using __getValue because in fact all operations are performed on native side and actually there's no access to node's values from JS (except call node).
So it's not a good idea to use __getValue and I suppose this method will be removed soon. It's a relic of this proof of concept I mentioned before

[ckknight]

(Sorry, I mentioned __getValue, but it's actually __onEvaluate called from __getValue)

If that's the case, then why not explicitly throw within __onEvaluate if you definitely don't want people calling it? Seems more prudent than a silent failure of returning NaN.

[osdnk]

@ckknight
I suppose than "__" a the beginning of method is quite enough to say not to use it. React Native Reanimated is a library for performing animations in declarative way and this operation is calling for a method in node's object which is not a good idea.

It's not in documentation (readme) and it's used by us for testing mocks. In stable version it will be removed I suppose.

[ckknight]

Glad to hear it's going away in the future. I'm just trying to help improve the library and squash any bugs I can find, as I discovered a few when writing TypeScript definitions.

It seems imprudent to leave a method to silently fail by returning NaN instead of either returning a correct value or throwing.

You're free to do what you want with #54. I'm not going to fight this any further.

[osdnk]

Thank you for this contribution, but in fact these changes don't fix the problem. If you you wish to check it, run some animation on this node and check its value via some listener (e.g. with setInterval).