Renamed to nicklawls/step. That is where the repository lives now. It has not been published as a package under the new name.
Versions published as xilnocas/step still install under that name. 11 versions of 15 come from the new location (see their notes).
Rerouted (renamed, verified). The GitHub user or repository was renamed. The tag is still there, at the new name. The Lamdera package server serves a copy recovered from https://github.com/nicklawls/step.
What we checked: The repo moved to github.com/nicklawls/step. Rebuilt with git archive from commit 04b6001f955f of https://github.com/nicklawls/step (zip prefix xilnocas-step-04b6001/, America/Los_Angeles times): the zip is byte-identical to the one package.elm-lang.org recorded, SHA-1 98a7cfde4102ad85d97437833e1cfd67bb5afcb6.
The Lamdera compiler uses this copy and prints a one-line notice saying so. elm itself fails to download this version.
Details · package.elm-lang.org's zip: https://github.com/xilnocas/step/zipball/4.0.1/
elm-state-transition
Keep the interaction in the state it was in.
NOTE: This will prevent any commands from being returned
Step.stay == (Step.stay |> Step.withCmd myHttpCall)If you want to stay in the same state, but run some commands, use Step.to explicitly
Step.to MySameState |> Step.withCmd myHttpCallIf we're stepping to a new state, add an command to fire off
This can be called on a Step multiple times, and all the commands will fire.
No commands are fired if the Step turns out to be a stay or an exit
A helper for building Steps out of tasks
All of these functions help you build functions that return steps out of other functions that return steps
Apply a function to the state inside a Step, if it's there
Most useful in building a Step out of another Step returned from some other update function you're calling
Apply a function to any msgs conteined in the Step
Also used for building larger interaction steps out of smaller ones
Map over the output of an interaction, if we've reached the end
Run the first suceeding Step, with priority given to the second argument
Intended to be used pipeline style
Step.to { loading = True } |> Step.orElse (Step.to { loading = False }) == Step.to { loading = True }
Step.noop |> Step.orElse Step.to { loading = True } == Step.to { loading = True }Choose a Step based on the result of another interaction
You can use this in combination with map and mapMsg to glue the end of one interaction to the beginning of another.
Notice that it looks a lot like Maybe.andThen and Maybe.result, but operating on the last type variable.
Turn a Step into the usual TEA update tuple
It must be a Step that doesn't exit. We know it is if the type variable a is still lowercase, i.e. not a specifc type, and can thus be chosen to be Never when calling this function.
turn an update function that returns a Step to a normal Elm Architecture update function
uses run internally to default with the provided model in case of a stay
Build a Step from a normal elm update tuple
Step to the state denoted by the model in the Just case, and stay otherwise
A
Step model msg adescribes one state transition of an application, and is inteneded to be what gets returned from an update function.It's helpful to look at how a
Stepis (roughly) represented under the hoodWe provide a constructor for each of these options, but we hide the internal representation to make sure you're combining steps in principled ways.
That being said, if you find something that makes you want the data structure fully exposed, let me know what the use case is!