On Oct 13, 2016, at 1:36 PM, Zinggi wrote:
>
> 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.
Right there may be the argument for why keeping functions out of the model
whil
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 interr
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
@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
curre
That's interesting as well. Though I think you'd run into challenges when
trying to handle interruptible animations. Specifically you'd have to do
all the interruptions manually. This would be even more challenging in the
context of interruptions that have a delay before they're supposed to
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.el
I also thought about this problem for a bit.
I came up with a slightly different solution.
I was not only not happy with storing functions in my model, but also with
storing static values in the model (e.g. stuff that wont change often).
I think it would be nice to separate the *descriptions* of
That's an interesting approach, though I'm not sure it would work for
elm-style-animation, at least in its current form. In elm-style-animation
you compose an animation under one Msg, and send animation
updates(basically tick the animation forward) via a separate Msg.
The `apply` and `apply
