I'm actually familiar with QML's animations. In many ways, they are similar to CSSTransitionGroups. You define States (a bunch of properties, think CSS styles, which get modified when that state is entered), you define Transisions between states (tell it which animations to apply on different state changes) and Animations (duration, easing, which properties are to be animated, sequential or parallel). It works very well in QML, so definitely worth learning or drawing inspiration from.
Regarding modifying the DOM directly, my original logic was that this is the most "transparent" (to the component's) way of applying animated changes - the components need not know that they are being animated. I do think most of the use cases can be achieved by wrapping the component to be animated inside an animation-aware component without needing to access the DOM directly. Accessing the DOM is, IMO, a postprocess effect. I do agree that it should be avoided, though. Brainstorming below: I was thinking about interpolators and easing. Perhaps this library should be ported to ClojureScript: https://github.com/gstamp/tween-clj That would add a more flexible set of tweening/easing than my code and we could extend it to add the missing easing functions. Also, if we added a set of generator functions to create, for example, a stream of values (after applying to easing functions) on a channel and functions for interpolating vectors and maps. Perhaps some timing functions that play nice with Om to allow for time-aware components. https://github.com/noprompt/garden#color could be used for color animations. Perhaps a set of path generation functions (circle, elipse, sine, bezier...). Some functions to easily hook into component local state or app state to "animate" their values. Perhaps with certain triggers, change notification and completion notification. Functions to pause and resume animation? (pausing: capture the elapsed time, resuming: start-time = (- current-time captured-elapsed)) Finally, some functions to "delay" an action. I'm thinking, if you have a list widget and you want to animate adding a new item to the list, you would do something like this: (delayed-action item {:start start-insert :tick do-insert-frame :end complete-insert :easing cubic-out :duration 1000}) and on removing the item from the list: (delayed-action item {:start start-remove :tick do-remove-frame :end complete-remove :easing cubic-in :duration 1000}) Essentially, a start function prepares the component for animation (eg start-insert would mount it somewhere, but not yet add it to the lists internal collection of items), a tick function would apply an animation frame and a end function would complete the animation (eg complete-insert would add it to the lists internal collection; complete-remove would unmount the item). --- Basically, a collection of tools that can be composed in many ways to create animations and animated Om components. Alternatively, something more declarative like QML's animations, but I don't have any ideas there yet. Then again, if Om is a function over app-state, which produces a visual representation, then animation is simply a time-varying element. Perhaps something declarative would fit nicely after all? On 6 May 2014 20:12, Jack Schaedler <[email protected]> wrote: > 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.htmltries 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. > -- 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.
