I really wonder why Facebooks own react-native-animated, which also works for regular React isn't more popular. It's easily the most simple, efficient and powerful. It does not re-render components, you can pass "native" animated values instead of wrapping stuff into functions. It has support for friction springs, time-based easings, interpolations, gestures and so on.
> I really wonder why Facebooks own react-native-animated, which also works for regular React isn't more popular
It seems like it's because there's been zero documentation on it?
How am I supposed to find out about this library and that it can be used in regular React? When I search for "react animated" the only official docs I get are https://facebook.github.io/react/docs/animation.html, which are now deprecated and have no relation to react-native-animated.
So I guess my questions are: how do I find out about regular, official React libraries like this? And how do I know this isn't an internal library that won't be changed at some point?
Yes, that's a shame. Facebook isn't currently pushing it, and who knows they might just abandon it. I don't understand it though, given that animated is such a boon for react-native users and this would only increase shareable code. It also plays in another ballpark compared to its competition.
In the webpackbin it demonstrates the use if you want to test it. You install it with: npm install animated --save
You're in the wrong place. If anyone was going for readability, it'd just be _.sample(['red', 'blue', 'yellow']). 0 chance of OP's bug, 0 chance of nathan's bug. Understand exactly what's going on as soon as you finish physically reading it.
This looks great, but I still prefer the model of react-motion for most use cases. The main difference between the two is that react-move uses preset durations, whereas react-motion uses a physics model where the durations are dynamic at runtime, directly following from the physics calculations.
They definitely both have their place in the sun. I feel like most of the time, I'm looking for a preset duration, which requires some experimenting in react-motion. The physics are cool, but can be decently imitated with some good easing functions.
This sort of declarative transition comes in handy for us all the time. Two features I don't see yet in React-Move that we find useful is a prop for more precise control over the staggering (orderBy), and custom interpolation (interpolate).
Custom interpolation is on the way, along with custom easing functions. As for the staggering, It would be fairly trivial to add some more customization to the parameters that go into it. Join this slack org and maybe we can chat about it? https://react-chat-signup.herokuapp.com/
How does performance compare to CSS transitions? Every animation framework I've tried has been a failure by comparison, even though CSS transitions are a nightmare to work with a lot of the time.
(an aside, but boasting about a 12KB minified size for an animation library baffles me. That's huge!)
You will almost always get better performance with CSS, unless you are using something like GSAP (which actually beats hardware accelerated CSS in some case). There are times though when you need animation to be dynamic, and React can be difficult to use with the more established framework agnostic animation libraries. This is also still a very young project, so I'm sure there are optimizations to be had. At some point, you will always be able to overwhelm the browser thread with too much to animate in under 16ms. I hope to get as close to (or under) that target as React and RAF will allow. As for the size, you may be right compared to standalone animation libraries. I am mostly comparing it to something like React-Motion (30kb I think?)
I wonder if it would be possible to get "dynamic" (state-dependent) animations such as these but by generating keyframed CSS animations and injecting them into the styles. I'm no guru but I think this would give you the absolute best of both worlds?
That's very sad! React-Move may implement very simple animation "concepts" that you could perform on your own, but there is immense value in the reusable API that React-Move exposes. If you were to utilize d3-interpolate, or a tweening library directly, you would still need to: handle proper react-lifecycle updates, animation-frame batching, detect when to reanimate, provide a deterministic and reusable api that promotes good composition, support as much of the ecosystem as possible, and at the same time keep dependencies and component footprint as small as possible. React-Move provides all of these things in a battle tested package that, given its rapid growth, has already proved its suitability for the majority use-case and general animation needs of React users.
On the topic of hardware acceleration, there are a some good perks to using class-based/keyframe CSS animation, but you immediately forfeit any ability to utilize dynamic run-time values. It's also important to note that even though React-Move's animation loop is being executed in Javascript instead of the browser's GPU thread, doesn't mean React-Move doesn't utilize hardware acceleration. By mapping these interpolated values to hardware-accelerated css properties, you are in fact using hardware-accelerated transitions, albeit at the speed of the JS thread.
If all of these amazing features aren't your cup of tea, then I would most definitely suggest that you roll your own solution. :)
Yes, d3-interpolate does a lot of the heavy lifting, but claiming that react-move doesn't provide any value is clearly untrue.
- Animation frame management, skipping frames if the cpu is overloaded
- React component API: you may not put value here, but some people find that easier to use, especially given the lifecycle hooks
Feel free to wire together your own solution if that works better for you. As for me, react-move is exactly what I need.
As far as I can tell this lib is just animating props, so its up to you what you do with those changing props ... rendering to DOM or native shouldn't make a difference?
Perhaps a stupid question but why is there a compatibility gap between React Native and React Browser? As an outsider, I get the impression that React Native is an unfinished product.
Not at all. React Native renders native elements, so CSS does not exist, just a CSS-like syntax that maps to native styles on Android and iOS. React Native is finished enough to do mature apps in, as Facebook is already using it in production on their mobile app, ads app, Instagram, etc. Other companies using it include Baidu, Tesla, Wal-Mart, AirBnb: https://facebook.github.io/react-native/showcase.html
It's certainly an evolving product and not every native function (such as video recording) is available as an easy-to-use component. In those cases, you can use a 3rd party NPM component or write your own Java/ObjC and link it in with your own custom component. Even if you have to write a little bit of Java/ObjC, it's a huge time saver.
Most of these projects use CSS or the DOM to provide animations, which aren't available on react-native. Usually, all compatibility problems between the two come from that.
It's just CSS-like syntax for describing styles. They don't claim to be compatible with CSS. But if you already know CSS, it's super intuitive. However, not every CSS property is available.
Unfortunately react-storybook is not very mobile friendly. I would suggest using the Codepen demo instead. Here is the full screen link for that: http://codepen.io/tannerlinsley/full/dWYEwd/
We're still working on some edge cases that will result in frames dropped. There will soon be a way to prioritize frame rate over duration precision and visa versa. Stay tuned!
Not sure what you're referring to here. React state is UI state. Components are of course visual (the "V" in MVC), and component state is what you use for UI state. So there's no separation of concerns being violated, unless you believe in a strict separation of style and component, which I think is a fallacy.
Animation stuff in Redux state would not be as nice.
Keep in mind, this is not a replacement for class css transitions, but stylesheets can only go so far. It may feel a bit funny at first, but it truly opens up new possibilities that were not previously possible with simple css animations. The most obvious being state-dependent dynamic styles. And since you can animate any value you want (not just styles), the applications are only as limited as your imagination! Cheers! :)
Examples:
https://www.webpackbin.com/bins/-KfKys3S2mgEH9UsE8GL
http://react-springy-parallax.surge.sh/
API examples:
http://animatedjs.github.io/interactive-docs/