These are some very good points.
I don't see how a library that doesn't store functions in the model could
deal with these situations as easy as your library does.
The only possible solution I can think of is that you could extend the
description of an animation to include possible future interruptions and
delays.
e.g.
animationDescription =
Animation {..., easing=something, onInterrupt= Delay 0.2 (Animation {...,
easing=somethingElse}) }
I don't know whether this could cover all your use cases, and it might be
difficult to use.
On Thursday, 13 October 2016 21:56:54 UTC+2, Matthew Griffith wrote:
>
>
> So it's not necessarily not having interruptible animations, it's more all
> the code that you'll need to manage them.
>
> In elm-style-animation you can just start a new animation and
> interruptions are handled automatically.
>
> When you have description and state split, you have to juggle switching
> out the animationDescription at the right time.
>
> view model =
> animate animationDescription model.animationState
>
> becomes the following when you have multiple possible animation
> descriptions. Lets say we have model.animId to keep track of what
> description is running so we can switch between them.
>
>
> view model =
> let
> myAnimationDescription = lookup model.animId
> in
> animate animationDescription model.animationState
>
> Easy peasy.
>
> What about when you want to have a delay and then an interruption, you
> have to keep track of the delay and switching out animationDescription when
> the interruption occurs. Great, we can do that.
>
> You also have to implement logic that handles what happens when multiple
> delayed interruptions are queued up. So now you have a queue of animation
> interruptions to manage. Ok then.
>
> Basically all of this is totally writable code...it's just that that's a
> large part of the built in functionality of the elm-style-animation
> library. Why write all that code if a library handles it out of the box?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thursday, October 13, 2016 at 3:25:17 PM UTC-4, Zinggi wrote:
>>
>> @Frederick
>> Yes, that's where I got my inspiration from ;)
>>
>> @Matthew
>> I don't think this is a problem, but I also don't understand what you
>> mean by "you'd have to do all the interruptions manually".
>> Could you elaborate?
>> I haven't studies your library closely, so I don't know how your library
>> currently deals with interruptions.
>>
>> I once created an animation library for react
>> <https://github.com/Zinggi/RAnimation>, it kinda works like I described
>> above and it does have interruptable animations.
>> But of course react doesn't map nicely to elm.
>>
>>
>> On Thursday, 13 October 2016 21:02:29 UTC+2, Frederick Yankowski wrote:
>>>
>>> The elm-autocomplete package does something much like you describe.
>>> Configuration data, including some functions, is defined separately from
>>> the model and is passed as an additional parameter to the update function.
>>>
>>>
>>> https://github.com/thebritican/elm-autocomplete/blob/4.0.1/src/Autocomplete.elm#L181
>>>
>>> On Thursday, October 13, 2016 at 1:34:29 PM UTC-5, Zinggi wrote:
>>>
>>> I think it would be nice to separate the *descriptions* of an animation
>>>> from the *state* of an animation.
>>>>
>>>
>>>
>>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
