Agree with everything Dylan said. It looks like the React team are working on this issue too:
Scroll down to the 'Animations' header: http://facebook.github.io/react/blog/ As a random thought, QML has an interesting set of mechanisms for declaratively specifying animations that should trigger on property and state changes. The situation is probably a bit more complex in the Om->React->Mutable Dom situation, but there might be some inspiration or at least things to learn from the QML implementation: http://qt-project.org/doc/qt-4.8/qdeclarativeanimation.html Just a random thought! On Tuesday, May 6, 2014 8:33:32 PM UTC+2, Dylan Butman wrote: > I've thought about React and Om animation a lot and have been meaning to > strip the animation code out of some of my projects and get it organized. I > wrote https://github.com/pleasetrythisathome/react.animate for react a little > while ago, and haven't quite got around to porting all the functionality to > cljs. > > Your easing functions are definitely helpful. > > To me it seems like an anti pattern and a generally dangerous thing to do to > mutate the DOM directly. The whole point of using something like React or Om > is that the DOM is the result of a pure render function that takes props > (app-state) and component state as inputs. If you mutate the DOM yourself, > this is no longer true. > > For my uses, I'd greatly prefer a more minimal library that will transition > two values with an easing function over a set duration. Automatic > interpolation of standard data types would also be great (like the d3 > interpolators I use in react.animate) > > I'll spend some time tonight and the next few days on getting something going > and then we can compare notes! > > The big question for me has always been how to deal with the add/remove item > from a list enter/exit animation that Jack is talking about. > > Ideally animation could shouldn't pollute your application, and should be an > arbitrary addition. > > It's straightforward to init-state at some state (say :width 0) and then > start a transition to :width 100 in IWillMount, which would happen for any > entering component. IWillUnmount is called when a component exits, but since > the component is actually unmounted right after it'd be useful to call a > transition here. > > ReactTransitionGroup http://facebook.github.io/react/docs/animation.html > tries to solve this by providing methods like componentWillLeave(callback) > where you are intended to call the callback when you're done with whatever > animation to actually trigger DOM removal. > > You could definitely do something similar with Om, but I think there are > probably more elegant ways...I need to spend some time experimenting and see > what happens... -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
