Hi Jack,
No worries! I am working on an updated version, as mentioned in my previous
messages, which I think will be much better. Unfortunately, I won't have
time to work on it until Thursday at the earliest, though the code in both
master and animated-components branches are usable right now.
In the meantime, I will think about your use case - I hadn't really thought
about that before now, but I think that is likely a very common use case
for animated components.
With that said - watch should work. It takes in the cursor and should
return a boolean - if true, the animation is started. The code is literally:
(when (and watch (watch props))
(async/put! (om/get-state owner :anim-ch) true))
I don't have an example ready to right now (I will write more examples over
the weekend), but you should be able to use it like this:
(ominate
example-component
{:watch #(> (:foo %) 10)
:duration 5000
:easing ease/sine-in
:anim anims/fade)
Note however that I have not tested a watch function which continues
returning true - I've only tested one which returns true once and then
false again. I will test and make sure this works properly in my next
release.
On 5 May 2014 22:25, Jack Schaedler <jwschaed...@gmail.com> wrote:
> HI Daniel,
>
> Apologies in advance for the probably stupid question:
>
> My main use case is to animate elements as they enter and leave the Dom.
> Something similar to the way that CSSTransitionGroups work, but hopefully
> with more of the power you are providing with the easing functions and
> timing mechanisms. I just had a go at incorporating the Ominate library
> with Goya and I'm not entirely sure about the best way to proceed for this
> use case. I tried using the :watch config option, but didn't have much
> luck. Should I be explicitly sending a request to trigger the animation via
> the channel, or is the watch facility sufficient for this use-case? Do you
> have an example of this behavior somewhere I could look at?
>
> Sorry again, it's late here and my head is starting to swim a bit. Let me
> know if the question makes sense!
>
>
> On Monday, May 5, 2014 10:09:53 AM UTC+2, Daniel Kersten wrote:
> > Excuse the typos in my previous mail, typing on a phone.
> >
> > I wanted to add that I think it makes sense to move all of the public
> animation state into the child components local state rather than passing
> it in as a cursor as IMHO app state should be reserved for domain data
> while local state makes sense for transient visual data like animation.
> Also, the child will never transact! it (as it would be overwritten next
> frame anyway), so a cursor seems unnecessary.
> >
> >
> > I'll make that change to animated-components later.
> >
> > On 5 May 2014 08:57, "Daniel Kersten" <dker...@gmail.com> wrote:
> >
> >
> > I think there's definitely merit in your suggestion as it allows
> components to animate themselves, plays nicer with Om and React and
> potentially will have smoother animation too, but I'm not yet sure what it
> should look like.
> >
> >
> >
> > I've rewritten ominate to use your approach in the animated-components
> branch (I'll be pushing an update soon that puts its features almost on par
> with master, the only thing missing is auto repeating animations). Would
> love your feedback on it.
> >
> >
> >
> > Does it really make sense to wrap a component that knows it's being
> animated in animation logic rather than providing something that can be
> used internally?
> >
> > It seems odd to require the component consumer to know Scott the nitty
> gritty animation details when the component itself also has to know about
> it.
> >
> > On the other hand, I can see a lot of value in using animated components
> as wrappers to other components that don't know their being animated kind
> of like om component versions of my existing animation functions.
> >
> >
> >
> > Again would love feedback especially on api design.
> >
> > Over all, I see three types of animation: a component that animates
> itself internally (eg your example code), a component which is animated
> that contains sub components (possibly by rendering animated borders or
> overlays around or over the sub component) and post processing a component
> by modifying and animating a dom node after rendering (eg, the code in
> master).
> >
> >
> >
> > I think the code in animated-components could easily address second and
> third, but as I said above, I'm unsure about how the first should look.
> I'll give that use case some hammock time :-)
> >
> > Re easing functions - absolutely, go for it! Move them into their own
> lib if you wish (but note that not all currently work...). I ported them
> from another library anyway (url in comments in the source).
> >
> >
> >
> > I am wondering if they should be rewritten though. I saw another library
> which has a set of functions (eg quadratic, cubic, sine etc) and a separate
> set of functions for ease-in, ease-out, ease-in-out. I already provide
> composable functions for reversing and such, maybe in/out should simply
> compose with the interpolation functions too? Seems more flexible.
> Definitely should be it's own library then, though.
> >
> >
> >
> > On 5 May 2014 03:37, "Dave Della Costa" <ddell...@gmail.com> wrote:
> >
> >
> > I was more just curious if there was a benefit to one over the other! I
> >
> > can see it potentially being useful to have animations outside of
> >
> > Om/React's control flow--but in that case it would probably make more
> >
> > sense as a separate library.
> >
> >
> >
> > In any case glad it sparked some ideas.
> >
> >
> >
> > I'll probably put my simpler version out as a simple Om component, since
> >
> > I need something minimal (and I'll probably reference/include your handy
> >
> > easing functions if you don't mind). But I'll keep my eye on ominate to
> >
> > see how it goes...good luck with it!
> >
> >
> >
> > DD
> >
> >
> >
> > (2014/05/05 4:01), Daniel Kersten wrote:
> >
> > > So, I've spent the past 45 minutes thinking about this and here's what
> >
> > > I've come up with:
> >
> > >
> >
> > > * I love the idea of animated components - components that react to a
> >
> > > certain bit of app-state to animate themselves
> >
> > > * I like the idea of animated wrapper components - that is,
> components
> >
> > > which wrap non-animated components in order to make them animated
> >
> > > (this is essentially what my animation functions do) - things that
> >
> > > cause basic style changes to the components they wrap would fall
> >
> > > into this category (eg, I have a component and I want it to fade to
> >
> > > black - that component doesn't need to know that its being
> animated).
> >
> > > * I would like to be able to control my components: start, stop,
> >
> > > restart at the very least.
> >
> > > * When starting an animation, it would be nice to be able to override
> >
> > > the configuration
> >
> > > * I want to provide a collection of standard animations that can be
> >
> > > applied to other (non-animated) components
> >
> > > * I want to be able to manually trigger animations, or tie them to
> >
> > > app-state changes
> >
> > > * I want to be able to be notified when the animations complete
> >
> > > * I want to be able to set animations to run once, repeat multiple
> >
> > > times or to loop forever (until I manually stop them)
> >
> > >
> >
> > > To meet these goals, I've started rewriting ominate.core to work
> similar
> >
> > > to what you wrote and expanding on it. I have still got to think about
> >
> > > how wrapper components should work. The rest should be doable without
> >
> > > too much trouble.
> >
> > >
> >
> > > I'm experimenting with this in the animated-components branch, if
> you're
> >
> > > interested:
> https://github.com/danielytics/ominate/tree/animated-components
> >
> > >
> >
> > >
> >
> > > On 4 May 2014 19:09, Daniel Kersten <dker...@gmail.com
> >
> > > <mailto:dker...@gmail.com>> wrote:
> >
> > >
> >
> > > Honestly, I did what I was familiar with. Your approach is seems
> better.
> >
> > >
> >
> > > I'm happy to update my implementation to work in a similar fashion.
> >
> > > Can you outline a bit how you envisioned something like this to
> >
> > > work? Any thoughts on desired functionality or API design?
> >
> > >
> >
> > > I threw mine together in a few hours yesterday, so I'm not
> >
> > > particularly attached to it and am happy to incorporate new ideas
> :)
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > On 4 May 2014 18:38, Dave Della Costa <ddell...@gmail.com
> >
> > > <mailto:ddell...@gmail.com>> wrote:
> >
> > >
> >
> > > Daniel, this is cool and is something I've been thinking about
> for a
> >
> > > month or so. However I've been prototyping a leaner approach
> which
> >
> > > leverages Om/React more heavily.
> >
> > >
> >
> > > So following from that I have a question: why create your own
> timing
> >
> > > loop, rather than use the underlying update mechanism in Om,
> which
> >
> > > already does the same thing using requestAnimationFrame (for
> that
> >
> > > matter, I'm also curious why David does it this way here:
> >
> > >
> https://github.com/swannodette/om/blob/master/examples/animation/src/core.cljs
> )?
> >
> > >
> >
> > > This simplifies the code significantly and obviates the need
> for
> >
> > > specialized animation functions, instead allowing for animation
> >
> > > *components* which seems preferable to me.
> >
> > >
> >
> > > I've got a working implementation of what I'm talking about,
> >
> > > using your
> >
> > > easing functions, here:
> >
> > >
> >
> > > https://github.com/ddellacosta/animation-proto
> >
> > >
> >
> > > DD
> >
> > >
> >
> > > (2014/05/04 9:25), Daniel Kersten wrote:
> >
> > > > Hey everyone,
> >
> > > >
> >
> > > > I've just pushed my little Om project to Clojars and Github
> :)
> >
> > > > It's still early in development, but I'd love some feedback
> on
> >
> > > how it
> >
> > > > should progress.
> >
> > > >
> >
> > > > Ominate allows you to animate any Om component by wrapping
> the
> >
> > > component
> >
> > > > in (ominate ...) before passing it to build, specifying
> >
> > > duration, easing
> >
> > > > function and animation.
> >
> > > >
> >
> > > > https://github.com/danielytics/ominate
> >
> > > >
> >
> > > > ---
> >
> > > >
> >
> > > > Animations are simply functions which take in a value between
> >
> > > 0 and 1
> >
> > > > and the DOM node of the component being animated and then do
> >
> > > "something"
> >
> > > > to the DOM node (typically changing it's style).
> Additionally,
> >
> > > > animations may provide begin and end functions which get
> >
> > > applied to the
> >
> > > > DOM node before and after the animation runs, allowing them
> to
> >
> > > modify
> >
> > > > the node to prepare for the animation and then clean up again
> >
> > > afterwards.
> >
> > > >
> >
> > > > Currently, Ominate is only packaged with two animations:
> fading
> >
> > > > (changing opacity over time) and color-fading (blending? -
> >
> > > placing a
> >
> > > > color overlay above the component and then fading that). I
> plan on
> >
> > > > adding many more animations after I've finalized the API.
> >
> > > Right now,
> >
> > > > animations are triggered by putting a value on a channel.
> >
> > > >
> >
> > > > I'm still deciding what the final API should look
> >
> > > like.*Feedback and
> >
> > > > suggestions welcome!*
> >
> > > >
> >
> > > > Some ideas I'm thinking about:
> >
> > > >
> >
> > > > * I would like to allow animations to be triggered by app
> state
> >
> > > > change, perhaps by passing a cursor to Ominate and a
> predicate
> >
> > > > function to apply to the cursor - when it returns true,
> the
> >
> > > > animation is triggered.
> >
> > > > * Ominate should also report animation completion back to
> >
> > > the user - a
> >
> > > > callback passed to (ominate ...) is probably the best way
> >
> > > to do this.
> >
> > > > * It would be cool if different animations can be "sent"
> to the
> >
> > > > component rather than only supporting preset animations.
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > > 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 clojurescrip...@googlegroups.com
> >
> > > <mailto:clojurescript%2bunsubscr...@googlegroups.com>
> >
> > > > <mailto:clojurescript+unsubscr...@googlegroups.com
> >
> > > <mailto:clojurescript%2bunsubscr...@googlegroups.com>>.
> >
> > > > To post to this group, send email to
> >
> > > clojur...@googlegroups.com
> >
> > > <mailto:clojur...@googlegroups.com>
> >
> > > > <mailto:clojur...@googlegroups.com
> >
> > > <mailto:clojur...@googlegroups.com>>.
> >
> > > > 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 clojurescrip...@googlegroups.com
> >
> > > <mailto:clojurescript%2bunsubscr...@googlegroups.com>.
> >
> > > To post to this group, send email to
> >
> > > clojur...@googlegroups.com
> >
> > > <mailto:clojur...@googlegroups.com>.
> >
> > > 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 clojurescrip...@googlegroups.com
> >
> > > <mailto:clojurescript+unsubscr...@googlegroups.com>.
> >
> > > To post to this group, send email to clojur...@googlegroups.com
> >
> > > <mailto:clojur...@googlegroups.com>.
> >
> > > 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 clojurescrip...@googlegroups.com.
> >
> > To post to this group, send email to clojur...@googlegroups.com.
> >
> > 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 clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> 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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
