opvasger/msg-replay/1.0.0

NOTE: the latest version is 1.0.1

Rerouted (cache, needs approval). The original is gone. This copy comes from a Lamdera package cache made before it went. The Lamdera package server serves a copy recovered from a Lamdera package cache from 2021-02-13.

What we checked: Rebuilt from the unpacked sources in a Lamdera package cache (5 copies agree), which Elm only writes after the published SHA-1 checked out; elm.json differs from package.elm-lang.org's; the exposed modules match docs.json; the zip is our own, so its SHA-1 is not the published one.

We could not verify this copy against what was published, so the Lamdera compiler asks before using it (y/n). Without a terminal, as in CI, it stops with an error unless approved:

  • lamdera make --auto-approve-package-rerouting approves rerouted versions for that run,
  • LAMDERA_AUTO_APPROVE_PACKAGE_REROUTING=1 does the same for every run in that environment,
  • LAMDERA_CACHE=off skips the Lamdera package server altogether: packages come from package.elm-lang.org and GitHub only, as with elm, and a rerouted version then fails to download.

Details · package.elm-lang.org's zip: https://github.com/opvasger/msg-replay/zipball/1.0.0/

Elm Msg-Replay

Automatic message-replay for Elm!

This project sets out to solve the same problems as "hot-reloading" known from JavaScript.

Demo Gif

As the Elm architecture makes you model your interactions (usually dubbed Msg), I've designed the programs in this module to record those interactions, and then replay them instantly when the program is reloaded. This enables some very nice features:

  1. You can change any part of your program without breaking replay. Even if you modify/remove a message, it will still replay every message up until the first that is not part of the program anymore.
  2. Replaying messages rather than storing the state of your application makes for very interactive programming, where you can change bits of logic and instantly see the results of the change you made without having to get the application back into the right state.
  3. This approach has no weird edge-cases that can cause confusion during development. It simply remembers the messages that flow through your program and replay them without performing commands.

This makes for reliable and immediate feedback during development.

As this project makes no assumptions about how your persist your messages in between reloads, you have to clear that cache yourself to reinitialize the program. If you, for example, decided to use localStorage, you can call localStorage.clear() & location.reload() in the developer-console to do so.