I have some experience in this, and for basic stuff you can use css. And it
keeps your elm code nicely focused on state, without complexity of having
to manage state transitions inside state.
e.g. for displaying and hiding a sidebar-menu which slides in from the
left, or a dropdown-menu, something like:
- have an menuIsOpen flag in your model,
- and in your view add a class "open" to your menu
- and in your css have something like this:
transition: transform 400ms;
transition: opacity 400ms;
What happens here is that elm will render the new state, and after that,
css animation transitions to the new state on screen.
However, this only works for items that you can put/ which are in the DOM
both before and after the animation. And you cannot use "display: none" to
hide items (because css does not animate that). For more advanced
- Adding a new item to a list (typically the new item is not in the DOM
before it is added)
- Removing items from a list (the removed item is typically not rendered
after the removal).
- Functions or logic that should be available only after the transition
has completed. (e.g. first enlarge some square, and only afterwards display
contents of the square)
- Page transitions from one page to the next.
- Reversible animations: e.g. if the users clicks the "close" button
midway in the opening transition.
There are ways to get more done with css, but I always need more
elm-trickery too. I find that doing more complex animations fully in elm
gives me the most maintainable code.
You received this message because you are subscribed to the Google Groups "Elm
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.