xilnocas/step/3.0.0

NOTE: the latest version is 4.1.4

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 18ad678611f3 of https://github.com/nicklawls/step (zip prefix xilnocas-step-18ad678/, America/Los_Angeles times): the zip is byte-identical to the one package.elm-lang.org recorded, SHA-1 0a36bf5a51bb6b0b9bc0ccdd31263ed51c1c8cc7.

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/3.0.0/

Step

Some stuff

type Step s msg o

Step

A Step s msg o describes one step of an interaction. Here's a few things about the interactions we're talking about her

  • Interactions can involve the end user of your app, external servers, javascript: anything you might need to coordinate with in an Elm app
  • Interactions can be in one of a finite set of states. The states are represented by the type s
  • Interactions change state in response to messages, actions from the outside world. The messages are represented by the type msg
  • When responding to a message, the state of the interaction might change, and Cmds may be fired, potentially producing more messages.
  • Interactions might go on indefinitely, or end. If they end, they result in a final value of type o. This might seem a little weird, but it has some nice properties

Step s msg o is inteneded to be the return value of an update function. It encodes a bunch of common update function patterns, uniting them under a simple mental model, that simultaneously reduces boilerplate and eases composition.

map : (a -> b) -> Step a msg o -> Step b msg o

Apply a function to the state inside a step, if it's there

Most useful in building a bigger step out of a sub-step you happen to have lying around

stay : Step s msg o

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 myHttpCall
orElse : Step s msg o -> Step s msg o -> Step s msg o

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 }
run : Step state msg Never -> Maybe ( state, Cmd msg )

Turn a Step into the usual TEA update tuple

It must be a step in an interaction that continues forever. We know it is if the type variable o isn't a specifc type, and can thus be chosen to be Never

to : s -> Step s msg o

Step to a new state in the interaction

withCmd : Cmd msg -> Step s msg o -> Step s msg o

If we're stepping to a new state, add an action to fire off

mapMsg : (a -> b) -> Step state a o -> Step state b o

Apply a function to any msgs conteined in the step

Also used for building larger interaction steps out of smaller ones

exit : o -> Step s msg o

End the interaction by returning a value of type o

mapExit : (o -> p) -> Step s msg o -> Step s msg p

Map over the output of an interaction, if we've reached the end

onExit : (o -> Step s msg p) -> Step s msg o -> Step s msg p

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.

(msg -> model -> Step model msg Never)
-> msg
-> model
-> ( model, Cmd msg )

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

(msg -> model -> Step model msg o)
-> Step model msg o
-> List msg
-> Step model msg o

starting from an initial state, fold an update function over a list of messages

withAttempt : (Result x a -> msg) -> Task x a -> Step s msg o -> Step s msg o

A helper for building steps out of tasks

fromUpdate : ( s, Cmd msg ) -> Step s msg o

Build a step from a normal elm update tuple

fromMaybe : Maybe a -> Step a msg o

Step to the state denoted by the a in the Just case, and stay otherwise