DEV Community: Dwayne Crooks

Elm + Nix: A reproducible RealWorld clone

Dwayne Crooks — Fri, 13 Feb 2026 13:20:39 +0000

Nix has infected my soul. I don't know how else to describe it.

I refactored my RealWorld clone, dwayne/elm-conduit, to use Nix. It uses Nix for the development environment, building, serving, running checks, deploying, and CI.

As a bonus, if you have Nix running on your machine you can:

Run the frontend workshop environment:
- nix run github:dwayne/elm-conduit#workshop
Run the sandbox:
- nix run github:dwayne/elm-conduit#sandbox
Run the development version of the web app:
- nix run github:dwayne/elm-conduit
Run the production version of the web app, i.e. the exact version that's hosted by Netlify at https://elm-conduit.netlify.app:
- nix run github:dwayne/elm-conduit#prod

The Elm builds are all powered by dwayne/elm2nix.

The Classics

This actually completes my refactoring of "The Classics" to use Nix.

TodoMVC, Super Rentals, 7GUIs, and Conduit are now all using Nix in the same way. Check out anyone of them to help you figure out how to combine Elm and Nix for fun and profit.

TodoMVC

nix run github:dwayne/elm-todos#prod

Super Rentals

nix run github:dwayne/elm-super-rentals#prod

7GUIs

nix run github:dwayne/elm-7guis#prod

Contact me for Nix training and support

If you're interested in learning Nix or adding Nix to your workflow don't hesitate to reach out to me via the newsletter. I'd be delighted to help you achieve your goals.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Nix + pnpm + Parcel + lydell/elm-safe-virtual-dom

Dwayne Crooks — Thu, 29 Jan 2026 12:53:30 +0000

On January 12th, Flavio Corpa (kvothe) reached out on the #nix channel of the Elm Slack asking for help to make Nix and Parcel work together since he really wanted to use Simon Lydell's elm-safe-virtual-dom in his projects. Presumably, he read Juliano Solanho's (omnibs) post, on NoRedInk's blog, about adopting lydell/elm-safe-virtual-dom that got him excited about the prospects. He had some issues with browsers and auto translation of content that lydell/elm-safe-virtual-dom might be able to fix.

I had recently finished rewriting elm2nix and was on the lookout for opportunities to apply my freshly acquired knowledge so I felt it was fortuitous timing for me that his request was made when I was most able to help.

I approached my solution in two parts:

If you have Nix installed, you can try out the final result by executing:

nix run github:dwayne/elm-countries-quiz

Let's get into it.

Rewriting the project to use `dwayne/elm2nix`

In the PR, for this part, I highlighted all the noteworthy changes so I won't rehash them here but I'd make a few comments.

Name your development shell

nix develop doesn't give you any indication that you're in your development shell so to improve the situation you can give the shell a name and use it in your primary prompt string.

devShells.default = pkgs.mkShell {
  name = "elm-countries-quiz";

  shellHook = ''
    export PS1="($name)\n$PS1"
  '';
}

This way, when you enter your development shell the prompt changes and there's visual indication that you're in a different environment.

Use the programming language's package manager

In your development environment I found it's best to use Nix to install the programming language's package management tools and then use those tools to manage the project. In this way Nix becomes a way to manage your project's system dependencies while you continue to use the tools that are familiar to you from your programming language's ecosystem.

devShells.default = pkgs.mkShell {
  packages = [
    elm2nix.packages.${system}.default
    pkgs.elmPackages.elm
    pkgs.elmPackages.elm-format
    pkgs.elmPackages.elm-json
    pkgs.elmPackages.elm-test-rs
    pkgs.elmPackages.elm-review
    pkgs.nodejs_24
    pkgs.pnpm
  ];

  shellHook = ''
    pnpm install --silent
  '';
}

For e.g. anyone entering the development shell above gets access to elm2nix, elm, elm-format, elm-json, elm-test-rs, elm-review, node, npm, and pnpm.

In particular, you can now use pnpm to manage your project's dependencies like you would if you installed it in the traditional way. As a bonus, I run pnpm install --silent whenever you enter the development shell so that's one less thing you need to do to start working on the project.

Use aliases/functions to make it easier to perform common tasks

In your shellHook you can create Bash aliases or define Bash functions to provide shortcuts to the common tasks you find yourself repeating as you work on your project.

devShells.default = pkgs.mkShell {
  shellHook = ''
    export PROJECT_ROOT="$PWD"

    f () {
      elm-format                   \
        "$PROJECT_ROOT"/src        \
        "$PROJECT_ROOT"/review/src \
        "$PROJECT_ROOT"/tests      \
        --yes
    }

    r () {
      elm-review
    }

    t () {
      elm-test-rs "$PROJECT_ROOT"/tests/*.elm
    }

    c () {
      rm -rf "$PROJECT_ROOT"/{.parcel-cache,dist,elm-stuff,node_modules}
    }

    s () {
      pnpm start
    }

    echo "Type 'f' to run elm-format"
    echo "Type 'r' to run elm-review"
    echo "Type 't' to run elm-test-rs"
    echo "Type 'c' to remove build artifacts"
    echo "Type 's' to start the development server"
  '';
}

N.B. I used to use aliases but after learning that for almost every purpose, shell functions are preferable to aliases I've switched to functions in my recent projects.

Building with pnpm and Parcel in Nix

pnpm and Parcel are used to build the application in nix/app.nix.

The file is structured using the conventional callPackage pattern. It uses stdenv.mkDerivation with specific attributes to be able to use pnpm and parcel.

I use file sets to specify the minimum files needed for the build to work. This ensures that rebuilds are only ever considered when those files change.

To work with pnpm I followed the advice in the pnpm section of the Nixpkgs Reference Manual. In particular, I used the fetchPnpmDeps function to create the pnpm store derivation corresponding to the project's pnpm-lock.yaml. The setup hook pnpmConfigHook prepares the build environment to install the pre-fetched dependencies.

To ensure the Elm compiler could work fully offline I use the prepareElmHomeScript function, from dwayne/elm2nix, to create a local Elm cache.

Finally, pnpm build invokes parcel build index.html which builds the project and places the generated files in the dist directory which I copy over to the current derivation's output directory to successfully complete the process.

Adopting `lydell/elm-safe-virtual-dom`

Simon Lydell does an excellent job explaining his project in its README. The tl;dr is that it's a robust virtual DOM for Elm that makes your application, among other things, resilient against browser extensions that mutate the DOM independent of Elm. One of the things this enables is browser-based translations, the very feature that kvothe wanted working with his project.

To adopt lydell/elm-safe-virtual-dom you have to patch core Elm libraries and get the Elm compiler to use the patched versions.

How it works

The first major thing I did was to create derivations of the patched core Elm libraries whose output directories were structured in a very specific way.

For e.g. lydell/browser is supposed to replace elm/browser 1.0.2 so the output produced by nix/elm-safe-virtual-dom/lydell-browser.nix looks as follows:

$ nix build github:dwayne/elm-countries-quiz#lydellBrowser -L
$ tree result
result
└── elm
    └── browser
        └── 1.0.2
            ├── elm.json
            └── src
                ├── Browser
                │   ├── AnimationManager.elm
                │   ├── Dom.elm
                │   ├── Events.elm
                │   └── Navigation.elm
                ├── Browser.elm
                ├── Debugger
                │   ├── Expando.elm
                │   ├── History.elm
                │   ├── Main.elm
                │   ├── Metadata.elm
                │   ├── Overlay.elm
                │   └── Report.elm
                └── Elm
                    └── Kernel
                        ├── Browser.js
                        ├── Browser.server.js
                        └── Debugger.js

i.e. it gets mapped to the core library it replaces and the directory structure is exactly what you'd find in the Elm cache under $ELM_HOME/0.19.1/packages. But, the contents are precisely that of lydell/browser.

nix/elm-safe-virtual-dom/lydell-virtual-dom.nix and nix/elm-safe-virtual-dom/lydell-html.nix work in a similar way. The pattern they all use was abstracted into a mkPatch builder in nix/elm-safe-virtual-dom/patch.nix.

Once you have derivations with outputs structured in that way and you know where to find the Elm cache it's a simple matter to remove the old package and replace it with the patched version in the Elm cache. That's what nix/elm-safe-virtual-dom/install-patch-script.nix does. One interesting thing to note is how I used the patched derivation's passthru attribute to get a hold of the path in which the package would be stored in the Elm cache. I use the path to remove the old package and to copy in the patched version.

nix/elm-safe-virtual-dom/patches.nix installs all the required patches. This is used by both nix/app.nix and nix/elm.nix, after the local Elm cache has been created, to install the patched versions of the packages.

N.B. The full details are available in this PR.

As you can imagine, this technique can be generalized to patch any published Elm package in any way you desire but I'm getting ahead of myself and will probably say more on that in a future post.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Making TodoMVC work with dwayne/elm2nix

Dwayne Crooks — Thu, 22 Jan 2026 11:25:54 +0000

The TodoMVC web application is one of the first web applications I ever implemented. The first time I coded it up was when I was learning Backbone.js and the second time was when I was new to Elm. Throughout the years I've iterated on it multiple times to explore a variety of ideas. Now I'm at it again trying out dwayne/elm2nix on my dwayne/elm-todos project.

There were two major highlights for me after rewriting elm-todos to use elm2nix.

Having the ability to run the web application from any machine with Nix installed.
Making CI more reliable by being able to use Nix with a Nix-aware caching solution.

Below I'll explain these two points and then I'd go over the interesting details of the changes that were made.

Run the web application from any machine with Nix installed

If you have Nix installed you can run the development version of the application using:

nix run github:dwayne/elm-todos

Or, you can run the production version using:

nix run github:dwayne/elm-todos#prod

If you don't have Nix installed, no worries, there are multiple ways to do it. The way I recommend is to use the Determinate Nix Installer.

Reliable CI

In Towards more reliable CI, Evan (evancz) explained how to make CI much more reliable and Christian Ekrem (cekrem) created a repository, cekrem/elm-ci-setup, that shows how to properly cache Elm dependencies in CI/CD pipelines. If you're not using Nix then you should definitely follow the approach they outline.

Marek Fajkus (turboMaCk), is one of the main people responsible for getting all the existing community tooling for the Elm language working with Nix with his, now defunct, turboMaCk/nix-elm-tools project. He recommends using nix as a build tool:

In the end the best option I know about is to use nix as a build tool. Nix uses immutable structure for everything and can do very granular caching because of that. By far the most robust system is to package the code using nix and instead of CI cache rely on nix-store caching or things like cachix (built using Elm btw) to immutable hash based granular caching. But it's hardly something we should be recommending to everyone.

Another Elm community member, Matt McHenry (jerith666), also shared his thoughts on Nix which I've partially quoted below:

I think it’s worth mentioning Nix in this context as well. Nix builds run in a sandbox without any network access. So when you use Nix to build your Elm code, preventing network access at build time becomes a necessity rather than a “nice to have” for added stability and performance.

I mention all this to share that once I was able get dwayne/elm-todos building with Nix using dwayne/elm2nix it was relatively easy to set up a GitHub workflow that did quality assurance on my code on every push.

Here's the workflow, check.yml:

name: Check

on:
  push

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: DeterminateSystems/nix-installer-action@main
      - uses: DeterminateSystems/magic-nix-cache-action@main
      - run: nix flake check -L

Here are several runs. Here's a run where the cache needed to be warmed up. And, here's a run where the cache was used. In the last example, you'd notice that the flake checks didn't even need to be re-run since the derivations didn't change.

I was going to use Cachix, but I stumbled upon the Magic Nix Cache and decided to give it a try. With the Magic Nix Cache there's no signup, setup, or cost and you can use it by adding just one line to your workflow. For my simple public open source project the Magic Nix Cache seems to be a good fit. For other use cases Cachix might be the better service but this is not the post to go into comparisons between them.

The changes

I started here with the following project layout of key files:

public/
    _redirects
    index.css
    index.html
src/
    Main.elm
.gitignore
Caddyfile
elm.json

and after several iterations, see PR: Use elm2nix, I ended here with the following layout of key files:

.github/workflows/
    check.yml
nix/
    build-css.nix
    build-html.nix
    build.nix
    htmlnano.nix
    serve.nix
public/
    _redirects
    index.css
    index.html
src/
    Main.elm
.gitignore
Caddyfile
elm.json
elm.lock
flake.lock
flake.nix

N.B. All the .nix files in the nix/ directory follow the callPackage convention.

HTML

nix/build-html.nix returns a function that allows you to decide whether or not you want to minify the HTML. The minification is done with htmlnano, which Parcel used before switching to its own built-in minifier.

The HTML is only ever built the first time and whenever public/index.html changes.

CSS

nix/build-css.nix returns a function that allows you to decide whether or not you want to minify the CSS. The minification is done with lightningcss.

The CSS is only ever built the first time and whenever public/index.css changes.

Elm

The Elm application is built using the buildElmApplication builder from dwayne/elm2nix. Its src is filtered to include only the files required to build the application and nothing more.

Web app

The entire web application is put together in nix/build.nix. It returns a function that allows you to configure how the HTML, CSS, and Elm files are built.

If compression is enabled it compresses your HTML, CSS, and JavaScript output using brotli and zopflli. The Caddyfile is already configured to serve these compressed files locally so you can test that it works as expected.

You have the option to include Netlify redirects, public/_redirects, for proper handling of client-side routing when you're building to deploy to Netlify.

Serving locally

nix/serve.nix returns a function that creates a shell script that runs Caddy with a derivation that contains the files to be served. The flake.nix exposes these serve-based derivations as the dev and prod apps with dev being the default. See here. That's how the nix run functionality becomes available.

Quality assurance

.github/workflows/check.yml contains the workflow that runs nix flake check -L on every push. nix flake check is a command to verify whether the flake can be evaluated successfully and that the derivations specified by the flake's checks output can be built successfully.

I check that both the development and production versions of the Elm web application can be built successfully. Thanks to the Magic Nix Cache and the way I filter the dependent files I pass to the HTML, CSS, and Elm derivations I'm able to minimize what needs to rebuilt on every push.

Conclusion

Firstly, you can run your Elm web application from any machine with Nix installed.

nix run github:dwayne/elm-todos#prod

Secondly, Nix + dwayne/elm2nix + a Nix-aware caching solution leads to reliable CI for Elm web applications.

Finally, I hope I was able to convey the benefit of using Nix to build your Elm web application. TodoMVC may be a toy application but the ideas I shared do scale to larger applications with more complicated configurations. I plan to show you more interesting projects in future posts.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Announcing dwayne/elm2nix

Dwayne Crooks — Thu, 08 Jan 2026 10:43:55 +0000

Last year I worked a lot with Nix at my consulting job and I started to love it even more. I finally ascended its steep learning curve and began to enjoy using it for my development environments, CI setups, and VM configurations.

I wasn't doing much Elm or Haskell in my day-to-day so I was longing for a practical and interesting project to work on that might be beneficial to either the Elm or Haskell community, while at the same time, would extend my skills within functional programming.

When I researched cachix/elm2nix it seemed to fit perfectly with my goals because it combined all three technologies that I love, Elm, Haskell, and Nix, to produce a useful tool for Elm developers. On reading the code and seeing how Nix and Haskell were being used I immediately saw opportunities for growing my skills while making improvements to the tool.

Fast forward by about four months and I'm happy I took the plunge. I learned so much about each technology that I didn't know before and I was also able to find little ways to positively improve upon the project.

It is with great delight that I announce dwayne/elm2nix: A rewrite of cachix/elm2nix with a few changes and improvements.

What is `dwayne/elm2nix`?

Among other things, it is primarily a tool that helps you compile your Elm web application within a Nix build environment.

How to use `dwayne/elm2nix`?

In the folder containing your Elm web application's elm.json you use

elm2nix lock

to generate an elm.lock lock file.

The lock file is used by a custom Nix build helper, called buildElmApplication, that builds your Elm web application.

myApp = buildElmApplication {
    name = "my-app";
    src = ./.;
    elmLock = ./elm.lock;
}

If you have nix installed on your machine you can build the example Elm web application as follows:

nix build github:dwayne/elm2nix?dir=example
less result/elm.js

And, that's basically it. For more details please read the usage section of the README.

What's changed or improved?

Several things actually. Let's go through them one by one.

You can input one or more `elm.json` files to create the lock file

The lock file is a JSON file that has support for multiple versions of the same package.

[
    ...
    {
        "author": "elm",
        "package": "html",
        "version": "1.0.1",
        "sha256": "1m045b6cixyqygll4cjf9d9s3k1lj839kxc3gbid0fpqc4g10i6b"
    },
    {
        "author": "elm",
        "package": "json",
        "version": "1.1.3",
        "sha256": "1hx986yqw1v2bpkrh6brszl8n8awwg1s8zi7v5qg0p1rqwvjlicz"
    },
    {
        "author": "elm",
        "package": "json",
        "version": "1.1.4",
        "sha256": "0niq7id7r78ckvgap4psq0xdlnhcv1dz2j81lrnhl4fsgn0awvs8"
    },
    {
        "author": "elm",
        "package": "parser",
        "version": "1.1.0",
        "sha256": "06xx29rmagc5r45qfpvrd393lz83ylngidfp08432f1qc8y6r3lh"
    }
    ...
]

It acts as the source of truth for your project's Elm dependencies and it contains all the information Nix needs in order to prepare your ELM_HOME with everything the Elm compiler requires to compile your project offline.

Why would you want to pass multiple elm.json files to elm2nix lock?

One use case I came across that wasn't handled well by cachix/elm2nix was being able to run elm-review within a Nix build. Your review folder contains an elm.json file that contains depedencies used by elm-review but not by your Elm web application. However, to prepare the cache, to allow elm-review to run offline, those dependencies need to be considered.

As an example, the example project's elm.lock lock file was generated using

elm2nix lock elm.json review/elm.json

`registry.dat` is automatically generated for you

buildElmApplication generates the registry.dat file for you on the fly. That's one less file you have to consider managing.

You can display any `registry.dat` file as JSON

The registry.dat file is a binary file that encodes all the Elm packages in your cache. The registry subcommand of elm2nix has a view subcommand that allows you to display any valid registry.dat file as JSON.

elm2nix registry view

You can certainly use a tool like xxd to get a sense of its contents but I found that having a human-readable view was a huge benefit for debugging purposes.

In fact, if you're curious and want to understand the binary format used by the registry.dat file you can read the binarySerializationSpec.

The `buildElmApplication` build helper allows you to build an Elm web application in a variety of ways by setting options

All the typical tasks you'd want to perform during a build of your Elm web application are possible by changing a few options.

Turn on the time-travelling debugger

debuggedMyApp = myApp.override {
    enableDebugger = true;
    output = "debugged.js";
}

Fail the build if your Elm source code is improperly formatted

formattingCheckedMyApp = myApp.override {
    doElmFormat = true;
    elmFormatSourceFiles = [ "review/src" "src" "tests" ];
    output = "formatting-checked.js";
}

It runs elm-format --validate on the Elm source code it finds in the given directories.

Fail the build if your Elm tests fail

testedMyApp = formattingCheckedMyApp.override {
    doElmTest = true;
    output = "tested.js";
}

It runs your Elm tests.

BTW, since I overrode formattingCheckedMyApp, the testedMyApp derivation will also fail for improper formatting reasons. So, you can override buildElmApplication-based derivations in the standard Nix ways and it will work as expected.

Fail the build if `elm-review` fails

reviewedMyApp = testedMyApp.override {
    doElmReview = true;
    output = "reviewed.js";
}

It runs elm-review.

Thank you to Jeroen Engels for all his help debugging the various issues I had getting elm-review working in a Nix build environment.

Turn on optimizations

optimizedMyApp = reviewedMyApp.override {
    enableOptimizations = true;
    output = "optimized.js";
}

There are three optimization levels. By default, it uses the first level which compiles your Elm code with elm make --optimize.

optimized2MyApp = optimizedMyApp.override {
    optimizeLevel = 2;
    output = "optimized2.js";
}

Levels 2 and 3 both use elm-optimize-level-2. The only difference is that level 3 provides the --optimize-speed flag to elm-optimize-level-2.

Combine multiple Elm web applications into one JavaScript file

combinedMyApp = optimizedMyApp.override {
    entry = [ "src/App1.elm" "src/App2.elm" ];
    output = "combined.js";
}

The Elm compiler provides support for combining multiple web applications into one JavaScript file and buildElmApplication supports that use case as well through the entry option.

However, it must be noted that since elm-optimize-level-2 doesn't support that use case, you will not be able to combine multiple Elm web applications when level 2 or 3 optimization is turned on. In fact, this situation is correctly detected by buildElmApplication and explicitly disallowed.

Enable minification with UglifyJS or Terser

minifiedMyApp = optimized2MyApp.override {
    doMinification = true;
    useTerser = true;
    output = "minified.js";
}

By default it uses UglifyJS as recommended by What I've learned about minifying Elm code.

Minification is done in a separate minification phase, called minificationPhase, that's easily customizable. What this means is that you can configure it to do anything that lydell suggested in his Elm Discourse post.

In fact, everything I've shown you up to this point and will show you afterwards happens in independent phases so it's all easily customizable once you understand how phases work in Nix.

Enable compression with gzip and brotli

compressedMyApp = minifiedMyApp.override {
    doCompression = true;
    output = "compressed.js";
}

It compresses the JavaScript file using both gzip and brotli. By default, it passes the -9 flag to gzip and the -Z flag to brotli. You can configure both by passing the relevant flags to the gzipFlags and brotliFlags options as you see fit.

Show a report about the changes in your file size due to minification and compression

reportedMyApp = compressedMyApp.override {
    doReporting = true;
    output = "reported.js";
}

When you turn on reporting and build the derivation using nix build -L you will see a report detailing the impact that minification and compression had on the output size of the JavaScript that's produced. If you forget to build with -L then you can always view the logs generated by a build of your derivation using nix log.

The report is similar to the one used in the Asset Size section of the Elm Guide.

Enable content hashing for cache busting purposes

hashedMyApp = reportedMyApp.override {
    doContentHashing = true;
    output = "hashed.js";
}

Content hashing or fingerprinting takes your hashed.js, finds its sha256sum, and rewrites the name of the file to be something like hashed.abcd1234.js. This is useful for cache busting purposes.

By default, it uses a hash length of 8 and it removes the files with no hash in their names. Use the hashLength option to change the hash length and set keepFilesWithNoHashInFilenames to true so as not to remove the original files.

In addition, a manifest.json is generated to help you map the original filenames to their hashed equivalents when referring to them in your HTML or other resources.

All at once

Up to this point, I presented the possibilities by overriding previous derivations. However, you can definitely just configure it all at once.

As an example, the hashedMyApp derivation that we ended with is equivalent to the following finalMyApp derivation which configures everything in one go:

finalMyApp = buildElmApplication {
    name = "my-app";
    src = ./.;
    elmLock = ./elm.lock;

    doElmFormat = true;
    elmFormatSourceFiles = [ "review/src" "src" "tests" ];

    doElmTest = true;
    doElmReview = true;

    enableOptimizations = true;
    optimizeLevel = 2;

    doMinification = true;
    useTerser = true;

    doCompression = true;
    doReporting = true;
    doContentHashing = true;

    output = "hashed.js";
}

In my opinion, the best way to understand the extent of what's possible is to read the Nix code for buildElmApplication.

Advanced: The derivations and scripts that make `buildElmApplication` work are readily available for you to use for your own purposes

The elm2nix flake gives you access to several derivations and scripts which you can access as follows:

inherit (elm2nix.lib.elm2nix pkgs)
    buildElmApplication
    generateRegistryDat
    prepareElmHomeScript
    dotElmLinks
    symbolicLinksToPackagesScript
    fetchElmPackage
    ;

You've already seen buildElmApplication. Let's talk about prepareElmHomeScript and dotElmLinks.

`prepareElmHomeScript`

elmLock = ./elm.lock;

registryDat = generateRegistryDat {
    inherit elmLock;
};

examplePrepareElmHomeScript = prepareElmHomeScript {
    inherit elmLock registryDat;
};

It returns a string of Bash commands that will be used to configure ELM_HOME. If you have nix installed on your machine you can view the script from the example Elm web application as follows:

nix repl
> :lf github:dwayne/elm2nix?dir=example
> :p outputs.scripts.x86_64-linux.examplePrepareElmHomeScript
echo "Prepare .elm and set ELM_HOME=.elm"
cp -LR "/nix/store/wr561wqfhpr98xvji2q1g72y5ylgmq3p-dot-elm-links" .elm
chmod -R +w .elm
export ELM_HOME="$PWD/.elm"

N.B. The above example assumes an x86_64-linux system but there is also support for aarch64-darwin, aarch64-linux, and x86_64-darwin.

`dotElmLinks`

exampleDotElmLinks = dotElmLinks {
    inherit elmLock registryDat;
};

The derivation creates an Elm cache containing precisely the dependencies in your elm.lock lock file. If you have nix installed on your machine you can view the output of the exampleDotElmLinks derivation from the example Elm web application as follows:

nix build github:dwayne/elm2nix?dir=example#exampleDotElmLinks -L
tree result

Recently, there's been a lot of interesting discussions in the Elm community about issues compiling Elm web applications on external machines, for example in CI or on Digital Ocean VMs. If all you need is an Elm cache of your application's dependencies, then dotElmLinks can be used to prepare it for you. Either way, if you're using elm2nix then those issues won't be issues for you at all.

Conclusion

Nix may have a steep learning curve but I'm convinced it's an immensely valuable tool to have in your toolbox. dwayne/elm2nix brings the power of Nix to Elm and doesn't compromise on the versatility of Nix. The possibilities are endless and this is just the beginning. I hope we can all get to see the full power of Nix applied to the Elm ecosystem.

Finally, thank you to Domen Kožar for sharing his ideas, back in 2016, that's almost 10 years ago, on how elm2nix could work in the first place (elm2nix 0.1). Over the years a lot of developers have contributed to molding cachix/elm2nix to what it is today and it is their work that I've been able to build upon and improve, so I'm immensely greatful to all the contributors of that project as well.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Frontend Mentor's Contact form challenge built with Elm

Dwayne Crooks — Mon, 29 Sep 2025 12:23:52 +0000

My motivation for completing Frontend Mentor's Contact form challenge was to test-drive my field and form packages. I also recently started using and enjoying Astro so I wanted to explore what it would be like to use it as my frontend workshop environment. I even ended up experimenting with Makefiles, Nushell, and Nix flakes within this project. Overall, I learned a lot and gained some new skills. In this post I'm sharing the highlights of my experience.

How I built the form

I followed the typical process I've used for all my Elm web applications. In general, I build the UI first using just HTML/CSS, then I translate the UI to elm/html, then I implement the business logic, and finally I combine the UI and business logic.

For this project, here's the specific steps I followed:

I implemented the UI, using HTML and Sass, in a custom Astro frontend workshop environment.
I translated the UI into elm/html.
I used my field and form packages to implement the form's logic.
And finally, I wrote trivial glue code to connect the UI and form logic.

The UI

The UI was implemented in the workshop directory using Astro. I structured the HTML and Sass using a combination of BEM, data attributes, and utility classes. Each block was implemented using an Astro component. Pages were assembled to test out colors, typography, each individual block, combinations of blocks, and entire page states.

The workshop acted as the single source of truth for the HTML and CSS. For this project, the artifacts were a CSS file and a font file (.ttf).

`elm/html`

Based on the HTML structure and CSS styles developed in the frontend workshop environment I built the corresponding Elm views.

As an example, let's take a look at the path to get to the LabelledRadio component.

Astro component

---
import Radio from "@/components/Radio.astro";

const { labelProps, text = "Text", ...rest } = Astro.props;
---
<label class:list={["labelled-radio", labelProps?.class]}>
  <Radio {...rest} />
  {text}
</label>

Sass

@use "colors";
@use "spaces";
@use "typography";

.labelled-radio {
  display: flex;
  align-items: center;
  gap: spaces.get-space(150);

  min-width: fit-content;
  width: 100%;

  border: 1px solid colors.get-color("grey-500");
  border-radius: spaces.get-space(100);

  padding: spaces.get-space(150) spaces.get-space(300);

  cursor: pointer;

  background-color: colors.get-color("white");
  color: colors.get-color("grey-900");

  @include typography.body-m;

  &:hover {
    border-color: colors.get-color("green-600");
  }

  &:has(.input[type="radio"]:checked) {
    border-color: colors.get-color("green-600");
    background-color: colors.get-color("green-200");

    &:hover {
      background-color: colors.get-color("white");
    }
  }
}

Elm view

module View.LabelledRadio exposing (ViewOptions, view)

import Html as H
import Html.Attributes as HA
import Lib.View.Generic as Generic
import View.Radio as Radio


type alias ViewOptions msg =
    { text : String
    , radioAttrs : List (H.Attribute msg)
    }


view : ViewOptions msg -> List (H.Attribute msg) -> H.Html msg
view { text, radioAttrs } attrs =
    Generic.view
        { element = H.label
        , preAttrs =
            [ HA.class "labelled-radio"
            ]
        , postAttrs = []
        }
        attrs
        [ Radio.view radioAttrs
        , H.text text
        ]

I even wrote unit tests for all the Elm views. Here's the test for the LabelledRadio:

module Test.View.LabelledRadio exposing (suite)

import Html.Attributes as HA
import Test exposing (Test, describe, test)
import Test.Html.Query as Query
import Test.Html.Selector as Sel
import View.LabelledRadio as LabelledRadio


suite : Test
suite =
    describe "View.LabelledRadio"
        [ describe "general enquiry" <|
            let
                view =
                    LabelledRadio.view
                        { text = "General Enquiry"
                        , radioAttrs =
                            [ HA.name "query-type"
                            , HA.checked True
                            ]
                        }
                        []
            in
            [ test "label" <|
                \_ ->
                    view
                        |> Query.fromHtml
                        |> Query.has
                            [ Sel.tag "label"
                            , Sel.exactClassName "labelled-radio"
                            , Sel.exactText "General Enquiry"
                            ]
            , test "radio" <|
                \_ ->
                    view
                        |> Query.fromHtml
                        |> Query.find
                            [ Sel.attribute (HA.type_ "radio")
                            ]
                        |> Query.has
                            [ Sel.attribute (HA.name "query-type")
                            , Sel.checked True
                            ]
            ]
        ]

The two most interesting views to test were actually View.Field and View.QueryType.

Form logic

The form's logic is independent of the form's view. It was implemented in app/src/elm/Data/Contact/Form.elm.

module Data.Contact.Form exposing
    ( Accessors
    , Error(..)
    , Form
    , Output
    , State
    , form
    )

import Data.Contact.Bool as Bool
import Data.Contact.Email as Email exposing (Email)
import Data.Contact.QueryType as QueryType exposing (QueryType)
import Data.Contact.Text as Text exposing (Text)
import Field.Advanced as Field exposing (Field, Validation)
import Form exposing (Accessor)



-- FORM


type alias Form =
    Form.Form State Accessors Error Output


type alias State =
    { firstName : Field Text.Error Text
    , lastName : Field Text.Error Text
    , email : Field Email.Error Email
    , queryType : Field QueryType.Error QueryType
    , message : Field Text.Error Text
    , consent : Field Bool.Error Bool
    }


type alias Accessors =
    { firstName : Accessor State (Field Text.Error Text)
    , lastName : Accessor State (Field Text.Error Text)
    , email : Accessor State (Field Email.Error Email)
    , queryType : Accessor State (Field QueryType.Error QueryType)
    , message : Accessor State (Field Text.Error Text)
    , consent : Accessor State (Field Bool.Error Bool)
    }


type Error
    = FirstNameError Text.Error
    | LastNameError Text.Error
    | EmailError Email.Error
    | QueryTypeError QueryType.Error
    | MessageError Text.Error
    | ConsentError Bool.Error


type alias Output =
    { firstName : Text
    , lastName : Text
    , email : Email
    , queryType : QueryType
    , message : Text
    }


form : Form
form =
    Form.new
        { init = init
        , accessors = accessors
        , validate = validate
        }



-- INIT


init : State
init =
    { firstName = Field.empty (Text.fieldType { min = 1, max = 25 })
    , lastName = Field.empty (Text.fieldType { min = 1, max = 25 })
    , email = Field.empty Email.fieldType
    , queryType = Field.empty QueryType.fieldType
    , message = Field.empty (Text.fieldType { min = 1, max = 300 })
    , consent = Field.empty Field.true
    }



-- ACCESSSORS


accessors : Accessors
accessors =
    { firstName =
        { get = .firstName
        , modify = \f state -> { state | firstName = f state.firstName }
        }
    , lastName =
        { get = .lastName
        , modify = \f state -> { state | lastName = f state.lastName }
        }
    , email =
        { get = .email
        , modify = \f state -> { state | email = f state.email }
        }
    , queryType =
        { get = .queryType
        , modify = \f state -> { state | queryType = f state.queryType }
        }
    , message =
        { get = .message
        , modify = \f state -> { state | message = f state.message }
        }
    , consent =
        { get = .consent
        , modify = \f state -> { state | consent = f state.consent }
        }
    }



-- VALIDATE


validate : State -> Validation Error Output
validate state =
    always Output
        |> Field.succeed
        |> Field.applyValidation (state.consent |> Field.mapError ConsentError)
        |> Field.applyValidation (state.firstName |> Field.mapError FirstNameError)
        |> Field.applyValidation (state.lastName |> Field.mapError LastNameError)
        |> Field.applyValidation (state.email |> Field.mapError EmailError)
        |> Field.applyValidation (state.queryType |> Field.mapError QueryTypeError)
        |> Field.applyValidation (state.message |> Field.mapError MessageError)

And, extensively tested in app/tests/Test/Data/Contact/Form.elm.

module Test.Data.Contact.Form exposing (suite)

import Data.Contact.Form as Contact
import Data.Contact.Text as Text
import Expect
import Field.Advanced as Field
import Form
import Fuzz
import Test exposing (Test, describe, fuzz, test)


suite : Test
suite =
    describe "Data.Contact.Form"
        [ test "all fields are clean and empty" <|
            \_ ->
                let
                    apply2 f g a =
                        Expect.equal True (f a && g a)
                in
                Contact.form
                    |> Form.toState
                    |> Expect.all
                        [ .firstName >> apply2 Field.isClean Field.isEmpty
                        , .lastName >> apply2 Field.isClean Field.isEmpty
                        , .email >> apply2 Field.isClean Field.isEmpty
                        , .queryType >> apply2 Field.isClean Field.isEmpty
                        , .message >> apply2 Field.isClean Field.isEmpty
                        , .consent >> apply2 Field.isClean Field.isEmpty
                        ]
        , describe "firstName"
            [ fuzz (Fuzz.intRange 0 30) "it is required and must be less than 25 characters long" <|
                \n ->
                    let
                        form =
                            Contact.form
                                |> Form.modify .firstName (Field.setFromString (String.repeat n "f"))
                    in
                    if n == 0 then
                        form
                            |> Form.get .firstName
                            |> Field.toResult
                            |> Expect.equal (Err [ Field.blankError ])

                    else if n > 25 then
                        form
                            |> Form.get .firstName
                            |> Field.toResult
                            |> Expect.equal (Err [ Field.customError (Text.TooLong { actual = n, max = 25 }) ])

                    else
                        form
                            |> Form.get .firstName
                            |> Field.isValid
                            |> Expect.equal True
            ]
        , describe "lastName"
            [ fuzz (Fuzz.intRange 0 30) "it is required and must be less than 25 characters long" <|
                \n ->
                    let
                        form =
                            Contact.form
                                |> Form.modify .lastName (Field.setFromString (String.repeat n "l"))
                    in
                    if n == 0 then
                        form
                            |> Form.get .lastName
                            |> Field.toResult
                            |> Expect.equal (Err [ Field.blankError ])

                    else if n > 25 then
                        form
                            |> Form.get .lastName
                            |> Field.toResult
                            |> Expect.equal (Err [ Field.customError (Text.TooLong { actual = n, max = 25 }) ])

                    else
                        form
                            |> Form.get .lastName
                            |> Field.isValid
                            |> Expect.equal True
            ]
        , describe "email"
            [ test "it is required" <|
                \_ ->
                    Contact.form
                        |> Form.modify .email (Field.setFromString "")
                        |> Form.get .email
                        |> Field.toResult
                        |> Expect.equal (Err [ Field.blankError ])
            , test "it must contain @" <|
                \_ ->
                    Contact.form
                        |> Form.modify .email (Field.setFromString "ab.c")
                        |> Form.get .email
                        |> Field.toResult
                        |> Expect.equal (Err [ Field.syntaxError "ab.c" ])
            ]
        , describe "queryType"
            [ test "it is required" <|
                \_ ->
                    Contact.form
                        |> Form.modify .queryType (Field.setFromString "")
                        |> Form.get .queryType
                        |> Field.toResult
                        |> Expect.equal (Err [ Field.blankError ])
            ]
        , describe "message"
            [ fuzz (Fuzz.intRange 0 350) "it is required and must be less than 300 characters long" <|
                \n ->
                    let
                        form =
                            Contact.form
                                |> Form.modify .message (Field.setFromString (String.repeat n "m"))
                    in
                    if n == 0 then
                        form
                            |> Form.get .message
                            |> Field.toResult
                            |> Expect.equal (Err [ Field.blankError ])

                    else if n > 300 then
                        form
                            |> Form.get .message
                            |> Field.toResult
                            |> Expect.equal (Err [ Field.customError (Text.TooLong { actual = n, max = 300 }) ])

                    else
                        form
                            |> Form.get .message
                            |> Field.isValid
                            |> Expect.equal True
            ]
        , describe "consent"
            [ test "it is required" <|
                \_ ->
                    Contact.form
                        |> Form.modify .consent (Field.setFromString "")
                        |> Form.get .consent
                        |> Field.toResult
                        |> Expect.equal (Err [ Field.blankError ])
            , test "it cannot be false" <|
                \_ ->
                    Contact.form
                        |> Form.modify .consent (Field.setFromValue False)
                        |> Form.get .consent
                        |> Field.toResult
                        |> Expect.equal (Err [ Field.validationError "false" ])
            , test "it must be true" <|
                \_ ->
                    Contact.form
                        |> Form.modify .consent (Field.setFromValue True)
                        |> Form.get .consent
                        |> Field.isValid
                        |> Expect.equal True
            ]
        ]

Glue code

The code that connects the UI to the form's logic lives in app/src/elm/Main.elm and is implemented like any other Elm web application that uses TEA. There's no use of nested TEA. There's nothing special about it. For me, that's the point. The glue code loosely couples the UI and form logic and that's it.

Astro as a frontend workshop environment

I was never able to take a web design and directly implement it in a web application in one go. I always needed somewhere where I could experiment with ideas for how I wanted to write the HTML and CSS before I settled on a final solution. In this regard, I would always have a folder in my project where these experiements lived. For e.g. when I was building 2048 I had both an experiments and a prototype folder that served the purpose.

I called my process prototyping and the idea behind the experiments and prototype folders for UI development has helped my work tremendously. More examples include:

It's only recently that I learned about Brad Frost's frontend workshop environment idea and how Storybook is a specific instance of that idea. These other ideas and tools have only reinforced my belief that there's enormous value in having this extra prototyping step in my process.

Astro components are relatively easy to make and it doesn't enforce any particular workflow on you. Since I'm still experimenting with my workflow I value the freedom Astro gives me over Storybook. I can use Astro as a foundation to tailor the features of my frontend workshop environment to my needs and the needs of the particular project.

Project structure

For this project I also experimented with a new project structure.

I used two top-level directories called app and workshop. app contained the main Elm web application and workshop contained the frontend workshop environment.

I worked within workshop to build the UI and its artifacts (a CSS file and a font file) became inputs into app. The connection can be seen from the app prepare script.

To build the Elm web application you build the workshop, copy the artifacts over to the app's public directory and then build the app. All of this is handled by make (or equivalently make build).

Miscellaneous

I used Nushell for the bin/app and bin/workshop scripts. I have to use it some more to say whether or not it's worth it. I did like how easy it was to write a script with subcommands, document the subcommands, and wrap pre-exisiting scripts.

How to Create Custom CLIs for Internal Developer Platforms with Nushell

I packaged my deployment script with Nix and Nix flakes then added it as a dependency in my devbox.json. When you enter the developer environment you have access to the deploy Bash script which I then wrapped up into app deploy. Previously, I would copy and paste all the Bash scripts I needed from past projects into my current project but this approach was much nicer.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Announcing elm-field

Dwayne Crooks — Mon, 18 Aug 2025 12:36:14 +0000

I'm happy to announce the release of dwayne/elm-field.

dwayne/elm-field is an Elm package for constructing valid data from unreliable string inputs. It provides a Field data structure that models the non-UI related aspects of an input field. I extracted this package from my work on L-System Studio.

Think about a Field in a similar way as you'd think about Maybe, Result, and Validation. Suppose you're parsing a String into a value of some type, say a. There's the potential for one or more errors to occur. If you just want to know that an error occurred but you don't care about the specific error that occurred you'd use Maybe. If you do care to track the specific errors then you'd switch to Result. Furthermore, if you care to accumulate multiple specific errors you'd change to a Validation.

A Field is like a Validation in that it allows you to accumulate multiple specific errors. But, it also does a little bit more.

It remembers the original raw String you were trying to parse.
It remembers whether or not it's the first time you're changing the String to be parsed, i.e. whether or not your field is clean or dirty.
It keeps track of the function used to parse the String. And,
It keeps track of the function used to convert the value back to a String.

The last two constitute the Type of a Field.

The package provides two modules: Field and Field.Advanced. The difference between them is that Field.Advanced allows you to use a custom type to track your errors whereas Field uses strings for errors.

An example

Suppose you need to accept input from a user for a positive integer, i.e. an integer greater than or equal to 1. Here's what that might look like:

import Field as F exposing (Field)
...

type alias Model =
    { n : Field Int
    , ...
    }

init : Model
init =
    { n = F.empty F.positiveInt
    , ...
    }

type Msg
    = Input String
    | ...

update : Msg -> Model -> Model
update msg model =
    case msg of
        Input s ->
            { model | n = F.setFromString s model.n }

        ...

view : Model -> H.Html Msg
view model =
    ...
    H.input
        [ HA.type_ "text"
        , HA.value (F.toRawString model.n)
        , ...
        , HE.onInput Input
        ]
        []
    ...

In general, you can easily create a field out of any of Elm's primitive types: Int, Float, Bool, Char, and String.

For many more examples you can read the README, play with the demos, and examine the unit tests.

No UI

I want to stress that a Field data structure models the non-UI related aspects of an input field. This means you can implement the business logic for a form and reuse that logic to render your form in infinitely many ways. Take the sign up form example. The simple view and the complex view are different renderings of the same underlying form. You have complete control over the UI.

Richard's comment

If you resonate with Richard's comment then my package attempts to provide a better tool for working with forms as programs. Give it a try and let me know what you think.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Diary of an Elm Developer - From fields to forms

Dwayne Crooks — Thu, 10 Jul 2025 12:21:33 +0000

When Dillon introduced his form library he shared an Ellie demo containing a sign up form and a check in form in order to illustrate the capabilities of his library. The forms featured validation on blur, validations that depend on multiple form fields and the ability to reuse your form definitions.

I tried to recreate his demo starting from my Field type and discovered several beautiful (to me at least) abstractions along the way, Form and InteractionTracker.

Let's start by implementing the sign up form.

Sign Up form

Initialize

The sign up form consists of four form fields: username, password, password confirmation, and role.

type alias Fields =
    { username : Field Username
    , password : Field Password
    , passwordConfirmation : Field PasswordConfirmation
    , role : Field Role
    }

The username field is initialized to the string "dillon", the role field is initializied to the role SuperAdmin and the password fields are left empty.

init : Fields
init =
    { username = F.fromString Username.fieldType "dillon"
    , password = F.empty Password.fieldType
    , passwordConfirmation = F.empty PasswordConfirmation.fieldType
    , role = F.fromValue Role.fieldType Role.SuperAdmin
    }

Update

We need to control how the fields are set so that we can enforce the rules of the form. We do it by providing functions to set the fields.

type alias Setters =
    { setUsername : String -> Fields -> Fields
    , setPassword : String -> Fields -> Fields
    , setPasswordConfirmation : String -> Fields -> Fields
    , setRole : Role -> Fields -> Fields
    }

setters : Setters
setters =
    { setUsername =
        \s fields ->
            { fields | username = F.setFromString s fields.username }
    , setPassword =
        \s fields ->
            let
                password =
                    F.setFromString s fields.password
            in
            { fields | password = password, passwordConfirmation = updatePasswordConfirmation password fields.passwordConfirmation }
    , setPasswordConfirmation =
        \s fields ->
            let
                passwordConfirmation =
                    F.setFromString s fields.passwordConfirmation
            in
            { fields | passwordConfirmation = updatePasswordConfirmation fields.password passwordConfirmation }
    , setRole =
        \role fields ->
            { fields | role = F.setFromValue role fields.role }
    }

updatePasswordConfirmation : Field Password -> Field PasswordConfirmation -> Field PasswordConfirmation
updatePasswordConfirmation passwordField passwordConfirmationField =
    (\password passwordConfirmation ->
        if Password.toString password == PasswordConfirmation.toString passwordConfirmation then
            passwordConfirmationField

        else
            F.setError "The password confirmation does not match." passwordConfirmationField
    )
        |> F.get passwordField
        |> F.and passwordConfirmationField
        |> F.withDefault passwordConfirmationField

All the fields validate their own values like before, see Diary of an Elm Developer - Exploring an API for form fields, but notice how the password confirmation matching validation is handled. When you set the password or the password confirmation we check to see whether or not they match. If they don't match we set a validation error.

In this example, custom field errors are of type String but you have the freedom to use any error type you desire. For e.g. in another example not shown here I used F.setError PasswordConfirmation.Mismatch passwordConfirmationField.

Validate

Finally, we need to say how to validate the form and parse the user's input into an output data structure of our choosing.

type Error
    = UsernameError F.Error
    | PasswordError F.Error
    | PasswordConfirmationError F.Error
    | RoleError F.Error


type alias Output =
    { username : Username
    , password : Password
    , role : Role
    }

validate : Fields -> Validation Error Output
validate fields =
    (\username password _ role ->
        Output username password role
    )
        |> F.get (fields.username |> F.mapError UsernameError)
        |> F.and (fields.password |> F.mapError PasswordError)
        |> F.and (fields.passwordConfirmation |> F.mapError PasswordConfirmationError)
        |> F.and (fields.role |> F.mapError RoleError)

Putting it all together

module Dillon.SignUp exposing
    ( Error
    , Fields
    , Output
    , Setters
    , SignUp
    , form
    )

type alias SignUp =
    Form Fields Setters Error Output

form : SignUp
form =
    Form.new
        { init = init
        , setters = setters
        , validate = validate
        }

Let's take a step back to understand what we've achieved. All the requirements of the sign up form has been encapsulated into a reusable module, Dillon.SignUp, such that there is no way for a consumer of our form module to mess up the requirements of the form. At the same time anyone using the module is free to render the form and provide whatever UX they deem necessary.

If you don't believe me then let me show you by building a simple view and then extending it to work just like Dillon's sign up form demo.

A simple view of the Sign Up form

Model

type alias Model =
    { signUp : SignUp
    , maybeOutput : Maybe SignUp.Output
    }

init : Model
init =
    { signUp = SignUp.form
    , maybeOutput = Nothing
    }

Update

type Msg
    = InputUsername String
    | InputPassword String
    | InputPasswordConfirmation String
    | InputRole Role
    | Submit

update : Msg -> Model -> Model
update msg model =
    case msg of
        InputUsername s ->
            { model | signUp = Form.update .setUsername s model.signUp }

        InputPassword s ->
            { model | signUp = Form.update .setPassword s model.signUp }

        InputPasswordConfirmation s ->
            { model | signUp = Form.update .setPasswordConfirmation s model.signUp }

        InputRole role ->
            { model | signUp = Form.update .setRole role model.signUp }

        Submit ->
            { model | maybeOutput = Form.validateAsMaybe model.signUp }

View

view : Model -> H.Html Msg
view { signUp, maybeOutput } =
    let
        fields =
            Form.toFields signUp
    in
    H.div []
        [ H.h2 [] [ H.text "Sign Up" ]
        , H.form
            [ HA.novalidate True
            , HE.onSubmit Submit
            ]
            [ viewInput
                { id = "username"
                , label = "Username"
                , type_ = "text"
                , field = fields.username
                , errorToString = Username.errorToString
                , isRequired = True
                , isDisabled = False
                , attrs = [ HA.autofocus True ]
                , onInput = InputUsername
                }
            , viewInput
                { id = "password"
                , label = "Password"
                , type_ = "password"
                , field = fields.password
                , errorToString = Password.errorToString
                , isRequired = True
                , isDisabled = False
                , attrs = []
                , onInput = InputPassword
                }
            , viewInput
                { id = "passwordConfirmation"
                , label = "Password Confirmation"
                , type_ = "password"
                , field = fields.passwordConfirmation
                , errorToString = PasswordConfirmation.errorToString
                , isRequired = True
                , isDisabled = False
                , attrs = []
                , onInput = InputPasswordConfirmation
                }
            , viewSelect
                { id = "role"
                , label = "Role"
                , field = fields.role
                , options =
                    case F.toMaybe fields.role of
                        Just role ->
                            Selection.select role defaultRoleOptions

                        Nothing ->
                            defaultRoleOptions
                , toOption = roleToString
                , errorToString = Role.errorToString
                , isRequired = True
                , isDisabled = False
                , onInput = InputRole
                }
            , H.p []
                [ H.button
                    [ HA.disabled <| Form.isInvalid signUp ]
                    [ H.text "Sign Up" ]
                ]
            ]
        , case maybeOutput of
            Just { username, password, role } ->
                H.div []
                    [ H.h2 [] [ H.text "Output" ]
                    , H.p [] [ H.text <| "Username: " ++ Username.toString username ]
                    , H.p [] [ H.text <| "Password: " ++ Password.toString password ]
                    , H.p [] [ H.text <| "Role: " ++ roleToString role ]
                    ]

            Nothing ->
                H.text ""
        ]

defaultRoleOptions : Selection Role
defaultRoleOptions =
    Selection.fromList [] Role.Admin [ Role.SuperAdmin, Role.Regular ]

roleToString : Role -> String
roleToString role =
    case role of
        Role.Regular ->
            "Regular"

        Role.Admin ->
            "Admin"

        Role.SuperAdmin ->
            "Super Admin"

That's it. The form abstraction fits quite nicely into TEA such that the view code you write remains very similar to what you would have written without the abstractions.

But, that's a simple view. What about adding blur on validation? Well, let's see.

A complex view of the Sign Up form

Blur on validation is a UI concern so the changes SHOULD show up in the UI part of the code. If they show up anywhere else then something is wrong with the abstraction.

Model

type alias Model =
    { signUp : SignUp
    , usernameTracker : InteractionTracker.State
    , passwordTracker : InteractionTracker.State
    , passwordConfirmationTracker : InteractionTracker.State
    , timer : Timer
    , isSubmitting : Bool
    , maybeOutput : Maybe SignUp.Output
    }


init : () -> ( Model, Cmd msg )
init _ =
    ( { signUp = SignUp.form
      , usernameTracker = InteractionTracker.init
      , passwordTracker = InteractionTracker.init
      , passwordConfirmationTracker = InteractionTracker.init
      , timer = Timer.init
      , isSubmitting = False
      , maybeOutput = Nothing
      }
    , Cmd.none
    )


timerConfig : Timer.Config Msg
timerConfig =
    Timer.config
        { wait = 5000
        , onExpire = ExpiredTimer
        , onChange = ChangedTimer
        }

I added five new record fields to the model.

usernameTracker, passwordTracker, and passwordConfirmationTracker keeps track of the UI state (Not visited, Focused, Changed, and Blurred) of the corresponding form fields.

timer and isSubmitting are used to simulate submitting a form to a backend that takes some time, about 5 seconds.

Update

We have a few new messages to handle.

type Msg
    -- The old messages remain the same
    = InputUsername String
    | InputPassword String
    | InputPasswordConfirmation String
    | InputRole Role
    | Submit
    -- The new messages
    | ChangedUsernameTracker (InteractionTracker.Msg Msg)
    | ChangedPasswordTracker (InteractionTracker.Msg Msg)
    | ChangedPasswordConfirmationTracker (InteractionTracker.Msg Msg)
    | ExpiredTimer
    | ChangedTimer Timer.Msg

Except for Submit the old message implementations in update remain the same.

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        -- The old messages remain the same except for Submit
        -- ...

        Submit ->
            let
                ( timer, cmd ) =
                    Timer.setTimeout timerConfig model.timer
            in
            ( { model | timer = timer, isSubmitting = True }
            , cmd
            )

        -- The new messages

        ChangedUsernameTracker subMsg ->
            let
                ( usernameTracker, cmd ) =
                    InteractionTracker.update subMsg model.usernameTracker
            in
            ( { model | usernameTracker = usernameTracker }
            , cmd
            )

        ChangedPasswordTracker subMsg ->
            let
                ( passwordTracker, cmd ) =
                    InteractionTracker.update subMsg model.passwordTracker
            in
            ( { model | passwordTracker = passwordTracker }
            , cmd
            )

        ChangedPasswordConfirmationTracker subMsg ->
            let
                ( passwordConfirmationTracker, cmd ) =
                    InteractionTracker.update subMsg model.passwordConfirmationTracker
            in
            ( { model | passwordConfirmationTracker = passwordConfirmationTracker }
            , cmd
            )

        ExpiredTimer ->
            ( { model
                | signUp = SignUp.form
                , usernameTracker = InteractionTracker.init
                , passwordTracker = InteractionTracker.init
                , passwordConfirmationTracker = InteractionTracker.init
                , timer = Timer.init
                , isSubmitting = False
                , maybeOutput = Form.validateAsMaybe model.signUp
              }
            , Cmd.none
            )

        ChangedTimer subMsg ->
            ( model
            , Timer.update timerConfig subMsg model.timer
            )

View

We have replaced viewInput with viewInteractiveInput which takes two extra fields: tracker and onChange. Everything else remains the same.

view : Model -> H.Html Msg
view { signUp, usernameTracker, passwordTracker, passwordConfirmationTracker, timer, isSubmitting, maybeOutput } =
    let
        fields =
            Form.toFields signUp
    in
    H.div []
        [ H.h2 [] [ H.text "Sign Up" ]
        , H.form
            [ HA.novalidate True
            , HE.onSubmit Submit
            ]
            [ viewInteractiveInput
                { id = "username"
                , label = "Username"
                , type_ = "text"
                , field = fields.username
                , tracker = usernameTracker
                , errorToString = Username.errorToString
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs = [ HA.autofocus True ]
                , onInput = InputUsername
                , onChange = ChangedUsernameTracker
                }
            , viewInteractiveInput
                { id = "password"
                , label = "Password"
                , type_ = "password"
                , field = fields.password
                , tracker = passwordTracker
                , errorToString = Password.errorToString
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs = []
                , onInput = InputPassword
                , onChange = ChangedPasswordTracker
                }
            , viewInteractiveInput
                { id = "passwordConfirmation"
                , label = "Password Confirmation"
                , type_ = "password"
                , field = fields.passwordConfirmation
                , tracker = passwordConfirmationTracker
                , errorToString = PasswordConfirmation.errorToString
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs = []
                , onInput = InputPasswordConfirmation
                , onChange = ChangedPasswordConfirmationTracker
                }
            , viewSelect
                { id = "role"
                , label = "Role"
                , field = fields.role
                , options =
                    case F.toMaybe fields.role of
                        Just role ->
                            Selection.select role defaultRoleOptions

                        Nothing ->
                            defaultRoleOptions
                , toOption = roleToString
                , errorToString = Role.errorToString
                , isRequired = True
                , isDisabled = isSubmitting
                , onInput = InputRole
                }
            , H.p []
                [ H.button
                    [ HA.disabled (Form.isInvalid signUp || isSubmitting) ]
                    [ H.text <|
                        if isSubmitting then
                            "Signing Up..."

                        else
                            "Sign Up"
                    ]
                ]
            ]
        , case maybeOutput of
            Just { username, password, role } ->
                H.div []
                    [ H.h2 [] [ H.text "Output" ]
                    , H.p [] [ H.text <| "Username: " ++ Username.toString username ]
                    , H.p [] [ H.text <| "Password: " ++ Password.toString password ]
                    , H.p [] [ H.text <| "Role: " ++ roleToString role ]
                    ]

            Nothing ->
                H.text ""
        ]

A few points to note

We didn't have to touch Dillon.SignUp at all. It's truly reusable.
The UI is an orthogonal concern and changes to the UI led to corrresponding changes in the view code as we had hoped.
A moderate increase in complexity in the UI led to a moderate increase in complexity in the view code.

These things seem significant and promising from my point of view since they were sources of contention anytime I had to write Elm forms in the past.

Let's move on to the check in form.

Check In form

Initialize

type alias Fields =
    { name : Field String
    , checkIn : Field Date
    , checkInTime : Field Time
    , checkOut : Field Date
    , subscribe : Field Bool
    }

init : Fields
init =
    { name = F.fromString F.nonBlankString "dillon"
    , checkIn = F.empty Date.fieldType
    , checkInTime = F.empty Time.fieldType
    , checkOut = F.empty Date.fieldType
    , subscribe = F.fromValue F.bool True
    }

I use the String type for name but I validate it as a non-blank string such that the empty string and strings of whitespace are not valid values for the field. However, I created custom types for Date and Time.

Update

type alias Setters =
    { setName : String -> Fields -> Fields
    , setCheckIn : { today : Date, s : String } -> Fields -> Fields
    , setCheckInTime : String -> Fields -> Fields
    , setCheckOut : String -> Fields -> Fields
    , setSubscribe : Bool -> Fields -> Fields
    }

Notice how setting the check in date depends on today's date and it's explicit in the type.

setters : Setters
setters =
    { setName =
        \s fields ->
            { fields | name = F.setFromString s fields.name }
    , setCheckIn =
        \{ today, s } fields ->
            --
            -- N.B. You can pass in whatever data you need from the outside via a tuple or record.
            --
            let
                checkIn =
                    F.setFromString s fields.checkIn
            in
            case F.toMaybe checkIn of
                Just date ->
                    if date |> Date.isAfter today then
                        { fields | checkIn = checkIn }

                    else
                        { fields | checkIn = F.setError "You must check in after today." checkIn }

                Nothing ->
                    { fields | checkIn = checkIn }
    , setCheckInTime =
        \s fields ->
            let
                checkInTime =
                    F.setFromString s fields.checkInTime
            in
            case F.toMaybe checkInTime of
                Just time ->
                    if time |> Time.isBetween Time.nineAm Time.fivePm then
                        { fields | checkInTime = checkInTime }

                    else
                        { fields | checkInTime = F.setError "You must check in between the hours of 9am to 5pm." checkInTime }

                Nothing ->
                    { fields | checkInTime = checkInTime }
    , setCheckOut =
        \s fields ->
            let
                checkOut =
                    F.setFromString s fields.checkOut

                maybeCheckOutIsAfterCheckIn =
                    Date.isAfter
                        |> F.get fields.checkIn
                        |> F.and checkOut
                        |> F.andMaybe
            in
            case maybeCheckOutIsAfterCheckIn of
                Just checkOutIsAfterCheckIn ->
                    if checkOutIsAfterCheckIn then
                        { fields | checkOut = checkOut }

                    else
                        { fields | checkOut = F.setError "You must check out after you've checked in." checkOut }

                Nothing ->
                    { fields | checkOut = checkOut }
    , setSubscribe =
        \b fields ->
            { fields | subscribe = F.setFromValue b fields.subscribe }
    }

Take note of how the validation dependencies are handled.

Validate

type Error
    = NameError F.Error
    | CheckInError F.Error
    | CheckInTimeError F.Error
    | CheckOutError F.Error
    | SubscribeError F.Error

type alias Output =
    { name : String
    , stay : Stay
    , isSubscribed : Bool
    }

type alias Stay =
    { date : Date
    , time : Time
    , nights : Int
    }

validate : Fields -> Validation Error Output
validate fields =
    (\name checkIn checkInTime checkOut subscribe ->
        Output
            name
            (Stay checkIn checkInTime (Date.nights checkIn checkOut))
            subscribe
    )
        |> F.get (fields.name |> F.mapError NameError)
        |> F.and (fields.checkIn |> F.mapError CheckInError)
        |> F.and (fields.checkInTime |> F.mapError CheckInTimeError)
        |> F.and (fields.checkOut |> F.mapError CheckOutError)
        |> F.and (fields.subscribe |> F.mapError SubscribeError)

Putting it all together

module Dillon.CheckIn exposing
    ( CheckIn
    , Error
    , Fields
    , Output
    , Setters
    , form
    )

type alias CheckIn =
    Form Fields Setters Error Output

form : CheckIn
form =
    Form.new
        { init = init
        , setters = setters
        , validate = validate
        }

A view of the Check In form

Model

type alias Model =
    { today : Date
    , checkIn : CheckIn
    , nameTracker : InteractionTracker.State
    , checkInTracker : InteractionTracker.State
    , checkInTimeTracker : InteractionTracker.State
    , checkOutTracker : InteractionTracker.State
    , subscribeTracker : InteractionTracker.State
    , timer : Timer
    , isSubmitting : Bool
    , maybeOutput : Maybe CheckIn.Output
    }


init : () -> ( Model, Cmd Msg )
init _ =
    ( { today = Date.jul1st2025
      , checkIn = CheckIn.form
      , nameTracker = InteractionTracker.init
      , checkInTracker = InteractionTracker.init
      , checkInTimeTracker = InteractionTracker.init
      , checkOutTracker = InteractionTracker.init
      , subscribeTracker = InteractionTracker.init
      , timer = Timer.init
      , isSubmitting = False
      , maybeOutput = Nothing
      }
    , Date.today GotDate
    )


timerConfig : Timer.Config Msg
timerConfig =
    Timer.config
        { wait = 5000
        , onExpire = ExpiredTimer
        , onChange = ChangedTimer
        }

Update

type Msg
    = GotDate Date
    | InputName String
    | ChangedNameTracker (InteractionTracker.Msg Msg)
    | InputCheckIn String
    | ChangedCheckInTracker (InteractionTracker.Msg Msg)
    | InputCheckInTime String
    | ChangedCheckInTimeTracker (InteractionTracker.Msg Msg)
    | InputCheckOut String
    | ChangedCheckOutTracker (InteractionTracker.Msg Msg)
    | ToggleSubscribe
    | ChangedSubscribeTracker (InteractionTracker.Msg Msg)
    | Submit
    | ExpiredTimer
    | ChangedTimer Timer.Msg


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        GotDate date ->
            ( { model | today = date }
            , Cmd.none
            )

        InputName s ->
            ( { model | checkIn = Form.update .setName s model.checkIn }
            , Cmd.none
            )

        ChangedNameTracker subMsg ->
            let
                ( nameTracker, cmd ) =
                    InteractionTracker.update subMsg model.nameTracker
            in
            ( { model | nameTracker = nameTracker }
            , cmd
            )

        InputCheckIn s ->
            ( { model | checkIn = Form.update .setCheckIn { today = model.today, s = s } model.checkIn }
            , Cmd.none
            )

        ChangedCheckInTracker subMsg ->
            let
                ( checkInTracker, cmd ) =
                    InteractionTracker.update subMsg model.checkInTracker
            in
            ( { model | checkInTracker = checkInTracker }
            , cmd
            )

        InputCheckInTime s ->
            ( { model | checkIn = Form.update .setCheckInTime s model.checkIn }
            , Cmd.none
            )

        ChangedCheckInTimeTracker subMsg ->
            let
                ( checkInTimeTracker, cmd ) =
                    InteractionTracker.update subMsg model.checkInTimeTracker
            in
            ( { model | checkInTimeTracker = checkInTimeTracker }
            , cmd
            )

        InputCheckOut s ->
            ( { model | checkIn = Form.update .setCheckOut s model.checkIn }
            , Cmd.none
            )

        ChangedCheckOutTracker subMsg ->
            let
                ( checkOutTracker, cmd ) =
                    InteractionTracker.update subMsg model.checkOutTracker
            in
            ( { model | checkOutTracker = checkOutTracker }
            , cmd
            )

        ToggleSubscribe ->
            let
                { subscribe } =
                    Form.toFields model.checkIn

                b =
                    subscribe
                        |> F.toMaybe
                        |> Maybe.map not
                        |> Maybe.withDefault False
            in
            ( { model | checkIn = Form.update .setSubscribe b model.checkIn }
            , Cmd.none
            )

        ChangedSubscribeTracker subMsg ->
            let
                ( subscribeTracker, cmd ) =
                    InteractionTracker.update subMsg model.subscribeTracker
            in
            ( { model | subscribeTracker = subscribeTracker }
            , cmd
            )

        Submit ->
            let
                ( timer, cmd ) =
                    Timer.setTimeout timerConfig model.timer
            in
            ( { model | timer = timer, isSubmitting = True }
            , cmd
            )

        ExpiredTimer ->
            ( { model
                | checkIn = CheckIn.form
                , nameTracker = InteractionTracker.init
                , checkInTracker = InteractionTracker.init
                , checkInTimeTracker = InteractionTracker.init
                , checkOutTracker = InteractionTracker.init
                , timer = Timer.init
                , isSubmitting = False
                , maybeOutput = Form.validateAsMaybe model.checkIn
              }
            , Cmd.none
            )

        ChangedTimer subMsg ->
            ( model
            , Timer.update timerConfig subMsg model.timer
            )

View

view : Model -> H.Html Msg
view { today, checkIn, nameTracker, checkInTracker, checkInTimeTracker, checkOutTracker, subscribeTracker, timer, isSubmitting, maybeOutput } =
    let
        fields =
            Form.toFields checkIn
    in
    H.div []
        [ H.h2 [] [ H.text "Check In" ]
        , H.form
            [ HA.novalidate True
            , HE.onSubmit Submit
            ]
            [ viewInteractiveInput
                { id = "name"
                , label = "Name"
                , type_ = "text"
                , field = fields.name
                , tracker = nameTracker
                , errorToString = CheckIn.nameErrorToString
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs = [ HA.autofocus True ]
                , onInput = InputName
                , onChange = ChangedNameTracker
                }
            , viewInteractiveInput
                { id = "checkIn"
                , label = "Check In"
                , type_ = "date"
                , field = fields.checkIn
                , tracker = checkInTracker
                , errorToString = Date.errorToString "check in"
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs =
                    let
                        maybeMax =
                            fields.checkOut
                                |> F.toMaybe
                                |> Maybe.map (Date.toString << Date.add -1)
                    in
                    [ HA.min (Date.toString <| Date.add 1 today)
                    ]
                        ++ (case maybeMax of
                                Just max ->
                                    [ HA.max max ]

                                Nothing ->
                                    []
                           )
                , onInput = InputCheckIn
                , onChange = ChangedCheckInTracker
                }
            , viewInteractiveInput
                { id = "checkInTime"
                , label = "Check In Time"
                , type_ = "time"
                , field = fields.checkInTime
                , tracker = checkInTimeTracker
                , errorToString = Time.errorToString "check in"
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs = []
                , onInput = InputCheckInTime
                , onChange = ChangedCheckInTimeTracker
                }
            , viewInteractiveInput
                { id = "checkOut"
                , label = "Check Out"
                , type_ = "date"
                , field = fields.checkOut
                , tracker = checkOutTracker
                , errorToString = Date.errorToString "check out"
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs =
                    [ fields.checkIn
                        |> F.toMaybe
                        |> Maybe.map (Date.add 1)
                        |> Maybe.withDefault (Date.add 2 today)
                        |> Date.toString
                        |> HA.min
                    ]
                , onInput = InputCheckOut
                , onChange = ChangedCheckOutTracker
                }
            , viewCheckbox
                { id = "subscribe"
                , label = "Sign Up for Email Updates"
                , field = fields.subscribe
                , tracker = subscribeTracker
                , isRequired = True
                , isDisabled = isSubmitting
                , attrs = []
                , onToggle = ToggleSubscribe
                , onChange = ChangedSubscribeTracker
                }
            , H.p []
                [ H.button
                    [ HA.disabled (Form.isInvalid checkIn || isSubmitting) ]
                    [ H.text <|
                        if isSubmitting then
                            "Checking In..."

                        else
                            "Check In"
                    ]
                ]
            ]
        , case maybeOutput of
            Just { name, stay, isSubscribed } ->
                H.div []
                    [ H.h2 [] [ H.text "Output" ]
                    , H.p [] [ H.text <| "Name: " ++ name ]
                    , H.p [] [ H.text <| "Nights: " ++ String.fromInt stay.nights ]
                    , H.p [] [ H.text <| "Email Updates: " ++ boolToString isSubscribed ]
                    ]

            Nothing ->
                H.text ""
        ]

Notice how the min and max attributes of the date input fields are set. Everything else is pretty much similar to how the complex sign up view was implemented.

Bonus: `InteractionTracker`

I didn't want to worry about which form control you needed to track. I figured the logic was independent of all that. After several refactoring sessions I realized I just needed a way to hijack the event handlers you placed on your controls so that I could hook into them and do my tracking.

module Lib.InteractionTracker exposing
    ( Messages
    , Msg
    , State
    , Status(..)
    , init
    , toMessages
    , toStatus
    , update
    )

import Lib.Task as Task

State

The internal state I need to know about over time.

type State
    = State
        { status : Status
        }


type Status
    = NotVisited
    | Focused
    | Changed
    | Blurred


init : State
init =
    State
        { status = NotVisited
        }

toStatus : State -> Status
toStatus (State { status }) =
    status

Update

type Msg msg
    = Focus
    | Input (String -> msg) String
    | Blur


update : Msg msg -> State -> ( State, Cmd msg )
update msg (State state) =
    case msg of
        Focus ->
            if state.status == Blurred then
                ( State state, Cmd.none )

            else
                ( State { state | status = Focused }
                , Cmd.none
                )

        Input onInput s ->
            ( if state.status == Blurred then
                State state

              else
                State { state | status = Changed }
            , Task.dispatch (onInput s)
            )

        Blur ->
            ( State { state | status = Blurred }
            , Cmd.none
            )

Messages

I will give you the messages you can use on your controls if you want to track the user's interactions with your widget. I can't know ahead of time which HTML elements they'd need to be placed on, that's for you to decide.

type alias Messages msg =
    { focus : msg
    , input : (String -> msg) -> String -> msg
    , blur : msg
    }


toMessages : (Msg msg -> msg) -> Messages msg
toMessages onChange =
    let
        onInput toMsg =
            onChange << Input toMsg
    in
    { focus = onChange Focus
    , input = onInput
    , blur = onChange Blur
    }

So how do we reuse this?

Enter `InteractiveInput`

InteractiveInput is a reusable view for tracking user interactions. It doesn't care what control you're tracking.

module Lib.InteractiveInput exposing
    ( InputOptions
    , ViewOptions
    , view
    )

import Field as F exposing (Error, Field)
import Html as H
import Html.Attributes as HA
import Lib.InteractionTracker as InteractionTracker


type alias ViewOptions a msg =
    { id : String
    , label : String
    , field : Field a
    , tracker : InteractionTracker.State
    , errorToString : Error -> String
    , debug : Bool
    , toInput : InputOptions a msg -> H.Html msg
    , onChange : InteractionTracker.Msg msg -> msg
    }


type alias InputOptions a msg =
    { id : String
    , field : Field a
    , focus : msg
    , input : (String -> msg) -> String -> msg
    , blur : msg
    }


view : ViewOptions a msg -> H.Html msg
view { id, label, field, tracker, errorToString, debug, toInput, onChange } =
    let
        status =
            InteractionTracker.toStatus tracker

        { focus, input, blur } =
            InteractionTracker.toMessages onChange
    in
    H.p [] <|
        [ H.label [ HA.for id ] [ H.text (label ++ ": ") ]
        , H.text " "
        , toInput
            { id = id
            , field = field
            , focus = focus
            , input = input
            , blur = blur
            }
        ]
            ++ (if debug then
                    [ H.text " "
                    , H.span [] [ H.text <| statusToString status ]
                    ]

                else
                    []
               )
            ++ [ if status == InteractionTracker.Blurred then
                    field
                        |> F.allErrors
                        |> List.map
                            (\e ->
                                H.li [ HA.style "color" "red" ] [ H.text <| errorToString e ]
                            )
                        |> H.ul []

                 else
                    H.text ""
               ]


statusToString : InteractionTracker.Status -> String
statusToString status =
    case status of
        InteractionTracker.NotVisited ->
            "Not visited"

        InteractionTracker.Focused ->
            "Focused"

        InteractionTracker.Changed ->
            "Changed"

        InteractionTracker.Blurred ->
            "Blurred"

`viewInteractiveInput`

viewInteractiveInput :
    { id : String
    , label : String
    , type_ : String
    , field : Field a
    , tracker : InteractionTracker.State
    , errorToString : Error -> String
    , isRequired : Bool
    , isDisabled : Bool
    , attrs : List (H.Attribute msg)
    , onInput : String -> msg
    , onChange : InteractionTracker.Msg msg -> msg
    }
    -> H.Html msg
viewInteractiveInput { id, label, type_, field, tracker, errorToString, isRequired, isDisabled, attrs, onInput, onChange } =
    InteractiveInput.view
        { id = id
        , label = label
        , field = field
        , tracker = tracker
        , errorToString = errorToString
        , debug = False
        , toInput =
            toFieldInput
                { isRequired = isRequired
                , isDisabled = isDisabled
                , onInput = onInput
                , attrs = attrs ++ [ HA.type_ type_ ]
                }
        , onChange = onChange
        }


toFieldInput :
    { isRequired : Bool
    , isDisabled : Bool
    , onInput : String -> msg
    , attrs : List (H.Attribute msg)
    }
    -> InteractiveInput.InputOptions a msg
    -> H.Html msg
toFieldInput { isRequired, isDisabled, onInput, attrs } { id, field, focus, input, blur } =
    Input.view
        { field = field
        , isRequired = isRequired
        , isDisabled = isDisabled
        , onInput = input onInput
        , attrs =
            attrs
                ++ [ HA.id id
                   , HE.onFocus focus
                   , HE.onBlur blur
                   ]
        }

Conclusion

After completing this exercise I'm getting more confident that my field abstraction which builds on dwayne/elm-validation and a few other ideas is a good starting point for a form abstraction. It seems to be allowing me to achieve the separation of concerns that I want in a form library. I want to be able to write down the requirements of my forms once and for all and then I want to be able to view that form however I please with any UX I desire.

I didn't even get to talk about the unit testing story. Suffice it to say that's it's easy to test your forms and you don't have to use avh4/elm-program-test to test your form logic. See this comment to understand what I'm referring to.

I plan to find more examples to rebuild with my abstractions in order to see where, if at all, my abstractions fall apart. It will be a while before I release anything.

Request for feedback

In the meantime, I'd be happy to receive stories or examples of forms you found quite challenging to build with the current form abstractions that the Elm ecosystem provides.

What do you think is difficult about forms that I may have overlooked?

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Diary of an Elm Developer - Exploring debounced input

Dwayne Crooks — Thu, 03 Jul 2025 12:14:12 +0000

Debouncing in general is about taking control of when a given action is performed.

If a user is entering their username and you want to check if their username is available via an API call then you don't want to make that check everytime they type a letter. You want to give them ample time to enter their username before making the check. Debouncing allows you to control when you make that check.

There are many more use cases for debouncing and a related idea called throttling which you can explore further in elm-debouncer Examples.

Today I'm going to share the work I'm doing to integrate debouncing (dwayne/elm-debouncer) with form fields (not yet released).

`Lib.DebouncedField`

The idea that came naturally to me was to bundle the field and the debouncer and create a new type of field called a DebouncedField.

type DebouncedField e a
    = DebouncedField (State e a)


type alias State e a =
    { field : Field e a
    , ready : Bool
    , debouncer : Debouncer String
    }

I encountered several problems doing it this way.

Firstly, a debounced field isn't really a field. It contains a field but it's not a field. To operate on the field I had to provide specific functions for working on the field. After seeing how many functions I needed in order to reclaim unfettered access to the field I caved and decided I needed the following API:

fromField : Field e a -> DebouncedField e a
changeField : (Field e a -> Field e a) -> DebouncedField e a -> DebouncedField e a
toField : DebouncedField e a -> Field e a

With that API, DebouncedField has access to the field to do what it needs and you have access to do what you need. A win-win. However, the nagging issue became which field is going to be the source of truth. I decided to let it slide for the time being.

But I couldn't overlook the following change to my signup form.

Before:

type alias Fields =
    { username : Field Username
    , email : Field Email
    , password : Field Password
    , passwordConfirmation : Field PasswordConfirmation
    }

After:

type alias Fields =
    { username : DebouncedField Username
    , email : Field Email
    , password : Field Password
    , passwordConfirmation : Field PasswordConfirmation
    }

N.B. The error type e has been specialized to String and elided by using a type alias in these examples.

What that meant was that every function in my sign up form module that touched username had to be changed.

You may be wondering why that's such a huge problem. So let me explain.

The sign up form module without DebouncedField captures all the requirements of the sign up form regardless of how you eventually choose to display it. That's fantastic because it means we can write form modules that capture the data requirements of all our forms and reuse them over several applications and render them differently in each one. So currently the form logic is independent of the way the form looks and independent of how you will be able to interact with it.

When I made username a DebouncedField all that went out the window because I was committing to the username field being debounced when rendered. At the same time I was also committing to email, password, and passwordConfirmation not being debounced now and in the future.

A good architecture makes the system easy to change, in all ways that it must change, by leaving options open.

A good architect will want to separate the UI portions of a use case from the business rule portions in such a way that they can be changed independently of each other, while keeping those use cases visible and clear.

The business rules should be the most independent and reusable code in the system.

Depend on things that have few to no reasons to change.

Clean Architecture: A Craftsman's Guide to Software Structure and Design
by Robert C. Martin

What I've come to realize in hindsight is that deboucing is a UI concern. My sign up form module captures the business rules of the application. As a result, my sign up form module should NEVER depend on whether or not you decide you want to debounce the username field.

Enter `Lib.DebouncedInput`

What I want instead is a reusable view for rendering a field whose input I want to debounce. My sign up form remains unchanged and reusable. Great! And, I get to decide when I'm building the UI if I want to add debouncing to any of the fields.

type DebouncedInput
    = DebouncedInput State


type alias State =
    { debouncer : Debouncer String
    , ready : Bool
    }

Here's how I use it in a deboucing example:

type alias Model =
    { status : Status
    , username : Field Username
    , usernameDebouncedInput : DebouncedInput
    , timer : Timer
    }

init : () -> ( Model, Cmd msg )
init _ =
    ( { status = Normal
      , username = F.empty Username.fieldType
      , usernameDebouncedInput = DebouncedInput.init
      , timer = Timer.init
      }
    , Cmd.none
    )

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        InputUsername s ->
            ( { model
                | status = Normal
                , username = F.setFromString s model.username
                , timer =
                    case model.status of
                        Checking _ ->
                            Timer.cancel model.timer

                        _ ->
                            model.timer
              }
            , Cmd.none
            )

        ReadyUsername s ->
            let
                usernameField =
                    F.setFromString s model.username

                ( timer, cmd ) =
                    Timer.setTimeout timerConfig model.timer

                newModel =
                    { model | username = usernameField, timer = timer }
            in
            ( case F.toMaybe usernameField of
                Just username ->
                    { newModel | status = Checking username }

                Nothing ->
                    newModel
            , cmd
            )

        FocusUsername ->
            ( model, Cmd.none )

        ChangedUsernameDebouncedInput subMsg ->
            let
                ( usernameDebouncedInput, cmd ) =
                    DebouncedInput.update usernameDebouncedInputConfig subMsg model.usernameDebouncedInput
            in
            ( { model | usernameDebouncedInput = usernameDebouncedInput }
            , cmd
            )

        TimerExpired ->
            ( model
            , Random.generate GotResult <|
                Random.weighted
                    ( 1, False )
                    [ ( 3, True )
                    ]
            )

        ChangedTimer timerMsg ->
            ( model
            , Timer.update timerConfig timerMsg model.timer
            )

        GotResult isFree ->
            case model.status of
                Checking _ ->
                    ( { model
                        | status =
                            if isFree then
                                Success

                            else
                                Error
                      }
                    , focus "username" FocusUsername
                    )

                _ ->
                    ( model, Cmd.none )

view : Model -> H.Html Msg
view model =
    H.form [ HA.style "margin" "10px" ]
        [ H.label [ HA.for "username" ] [ H.text "Username: " ]
        , DebouncedInput.view
            { field = model.username
            , debouncedInput = model.usernameDebouncedInput
            , isRequired = True
            , isDisabled =
                case model.status of
                    Checking _ ->
                        True

                    _ ->
                        False
            , config = usernameDebouncedInputConfig
            , attrs =
                [ HA.autofocus True
                , HA.id "username"
                ]
            }
        , H.p []
            [ case model.status of
                Normal ->
                    H.text ""

                Checking username ->
                    H.em
                        []
                        [ H.text <| "Checking if \"" ++ Username.toString username ++ "\" is free..."
                        ]

                Success ->
                    H.span
                        [ HA.style "color" "green" ]
                        [ H.text "The username is available."
                        ]

                Error ->
                    H.span
                        [ HA.style "color" "red" ]
                        [ H.text "The username is already taken."
                        ]
            ]
        ]

usernameDebouncedInput tracks the state required for debouncing. It is decoupled from the field, explicit in the code, and doesn't need to be there if later on we decide we want to remove debouncing.

Conclusion

The outcome of this exploration is that debouncing is a UI concern and as a result it will not be present in my field library. I will probably have to write a separate library for a reusable debounced input view.

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Diary of an Elm Developer - Exploring an API for form fields

Dwayne Crooks — Tue, 24 Jun 2025 13:27:13 +0000

My implementation of L-System Studio required me to use a lot of form fields in interesting ways.

It has input fields that take non-empty strings, non-negative integers, bounded integers, non-negative floats, bounded floats and angles in degrees.

The ability to zoom in depends on the value of zoom increment and window size. For e.g. if the zoom increment is 100 but the window size is 50 then the user shouldn't be allowed to zoom in. The user is only allowed to zoom in if the window size is at least twice the value of the zoom increment.

I found that my field abstraction allowed me to implement these requirements quite simply and because of this I've decided to explore these ideas even further.

More examples of usage

These are the fields I keep in the model:

type alias Model =
    { preset : Field Preset
    , axiom : Field String
    , iterations : Field Int
    , startHeading : Field Angle
    , lineLength : Field Float
    , lineLengthScaleFactor : Field Float
    , turningAngle : Field Angle
    , windowPositionX : Field Float
    , windowPositionY : Field Float
    , windowSize : Field Float
    , fps : Field Int
    , ipf : Field Int
    , panIncrement : Field Float
    , zoomIncrement : Field Float
    -- ...
    }

This is how I initialize the fields:

{ preset = F.fromValue F.preset isInitial preset
, axiom = F.fromString F.nonEmptyString True settings.axiom
, iterations = F.fromValue F.nonNegativeInt True settings.iterations
, startHeading = F.fromValue F.angle True settings.startHeading
, lineLength = F.fromValue F.nonNegativeFloat True settings.lineLength
, lineLengthScaleFactor = F.fromValue F.nonNegativeFloat True settings.lineLengthScaleFactor
, turningAngle = F.fromValue F.angle True settings.turningAngle
, windowPositionX = F.fromValue F.float True settings.windowPosition.x
, windowPositionY = F.fromValue F.float True settings.windowPosition.y
, windowSize = F.fromValue F.nonNegativeFloat True settings.windowSize
, fps = F.fromValue F.fps True settings.fps
, ipf = F.fromValue F.ipf True settings.ipf
, panIncrement = F.fromValue F.panIncrement True 10
, zoomIncrement = F.fromValue F.zoomIncrement True 10
-- ...
}

This is how I validate the fields before rendering:

render : Model -> ( Model, Cmd msg )
render model =
    let
        oldSettings =
            model.settings

        resultNewSettings =
            (\axiom iterations startHeading lineLength lineLengthScaleFactor turningAngle windowPositionX windowPositionY windowSize fps ipf ->
                { oldSettings
                    | rules = Rules.toValue model.rules
                    , axiom = axiom
                    , iterations = iterations
                    , startHeading = startHeading
                    , lineLength = lineLength
                    , lineLengthScaleFactor = lineLengthScaleFactor
                    , turningAngle = turningAngle
                    , windowPosition = { x = windowPositionX, y = windowPositionY }
                    , windowSize = windowSize
                    , fps = fps
                    , ipf = ipf
                }
            )
                |> F.get model.axiom
                |> F.and model.iterations
                |> F.and model.startHeading
                |> F.and model.lineLength
                |> F.and model.lineLengthScaleFactor
                |> F.and model.turningAngle
                |> F.and model.windowPositionX
                |> F.and model.windowPositionY
                |> F.and model.windowSize
                |> F.and model.fps
                |> F.and model.ipf
    in
    case resultNewSettings of
        Ok newSettings ->
            ( { model | settings = newSettings, renderer = initRenderer newSettings }
            , clear ()
            )

        Err _ ->
            ( model
            , Cmd.none
            )

This is how I pan to the left:

ClickedLeft ->
    F.apply2
        (\windowPositionX panIncrement ->
            render { model | windowPositionX = F.fromValue F.float False (windowPositionX - panIncrement) }
        )
        model.windowPositionX
        model.panIncrement
        |> Result.withDefault ( model, Cmd.none )

This is how I zoom out:

ClickedOut ->
    let
        resultWindow =
            F.apply4
                (\x y size inc ->
                    let
                        inc2 =
                            2 * inc
                    in
                    { x = x - inc
                    , y = y - inc
                    , size = size + inc2
                    }
                )
                model.windowPositionX
                model.windowPositionY
                model.windowSize
                model.zoomIncrement
    in
    case resultWindow of
        Ok { x, y, size } ->
            render
                { model
                    | windowPositionX = F.fromValue F.float False x
                    , windowPositionY = F.fromValue F.float False y
                    , windowSize = F.fromValue F.nonNegativeFloat False size
                }

        Err _ ->
            ( model, Cmd.none )

This is how I decide whether or not to disable the zoom in button:

H.button
    [ HA.type_ "button"
    , if isValidZoomIncrement { isZoomingIn = True, windowSize = windowSize, zoomIncrement = zoomIncrement } then
        HE.onClick ClickedIn

      else
        HA.disabled True
    ]
    [ H.text "In" ]

Features

Fields keep track of the raw string that the user entered.
When you first create the field it's considered clean but if you make changes then it's considered dirty.
Fields keep track of the processed value.
The processed value could be anything you want. In the examples above it was Int, Float, String, Angle, and Preset.
The processed value is stored in a Result so that we can track errors.
There's a concept of a field type, Type. A field type can be thought of as an interface of functions that concrete types, like Int, String, or Angle, implement in order to be used as fields. If you're familiar with Haskell, you might make Type a type class. If you're familiar with Rust, you might make Type a trait.

The main types used to achieve the features above:

type Field a
    = Field (State a)


type alias State a =
    { raw : Raw
    , processed : Result Error a
    }


type Raw
    = Initial String
    | Dirty String


type Error
    = Required
    | ParseError
    | ValidationError


type alias Type a =
    { toString : a -> String
    , toValue : String -> Result Error a
    , validate : a -> Result Error a
    }

Here's the full implementation of Field as I envisioned it at the time for L-System Studio.

How I made `Angle` into a field

Data.Angle was implemented with no regards for fields. But, when I was ready to accept angle input all I had to do was implement toString, toValue, and validate from the Type interface:

angle : F.Type Angle
angle =
    { toString = Angle.toDegrees >> String.fromFloat
    , toValue = F.trim >> Result.andThen (String.toFloat >> Maybe.map (Ok << Angle.fromDegrees) >> Maybe.withDefault F.validationError)
    , validate = Ok
    }

Here's the implementation of all the custom fields not directly provided by the Field module.

What lies ahead?

I'm currently still exploring the space and working on more diverse examples in order to figure out a good API for everything I'm going to need but the work I'm doing is looking really promising.

Most recently I finished a sign up form example. Here's what the code looks like:

module Example1.Data.SignUp exposing
    ( Error(..)
    , SignUp
    , Submission
    , errorToString
    , init
    , setEmail
    , setPassword
    , setPasswordConfirmation
    , setUsername
    , submit
    , toFields
    )

import Example1.Data.Email as Email exposing (Email)
import Example1.Data.Password as Password exposing (Password)
import Example1.Data.Username as Username exposing (Username)
import Field as F exposing (Field)


type SignUp
    = SignUp Fields


type alias Fields =
    { username : Field Username
    , email : Field Email
    , password : Field Password
    , passwordConfirmation : Field Password
    }


init : SignUp
init =
    SignUp
        { username = F.empty Username.fieldType
        , email = F.empty Email.fieldType
        , password = F.empty Password.fieldType
        , passwordConfirmation = F.empty Password.fieldType
        }


setUsername : String -> SignUp -> SignUp
setUsername s (SignUp fields) =
    SignUp { fields | username = F.setFromString s fields.username }


setEmail : String -> SignUp -> SignUp
setEmail s (SignUp fields) =
    SignUp { fields | email = F.setFromString s fields.email }


setPassword : String -> SignUp -> SignUp
setPassword s (SignUp fields) =
    let
        password =
            F.setFromString s fields.password
    in
    SignUp { fields | password = password, passwordConfirmation = updatePasswordConfirmation password fields.passwordConfirmation }


setPasswordConfirmation : String -> SignUp -> SignUp
setPasswordConfirmation s (SignUp fields) =
    let
        passwordConfirmation =
            F.setFromString s fields.passwordConfirmation
    in
    SignUp { fields | passwordConfirmation = updatePasswordConfirmation fields.password passwordConfirmation }


updatePasswordConfirmation : Field Password -> Field Password -> Field Password
updatePasswordConfirmation passwordField passwordConfirmationField =
    (\password passwordConfirmation ->
        if password == passwordConfirmation then
            passwordConfirmationField

        else
            F.fail (F.customError "The password confirmation does not match.") passwordConfirmationField
    )
        |> F.get passwordField
        |> F.and passwordConfirmationField
        |> F.withDefault passwordConfirmationField


type Error
    = UsernameError F.Error
    | EmailError F.Error
    | PasswordError F.Error
    | PasswordConfirmationError F.Error


type alias Submission =
    { username : Username
    , email : Email
    , password : Password
    }


submit : SignUp -> Result (List String) Submission
submit (SignUp fields) =
    (\username email password _ ->
        Submission username email password
    )
        |> F.get (fields.username |> F.mapError UsernameError)
        |> F.and (fields.email |> F.mapError EmailError)
        |> F.and (fields.password |> F.mapError PasswordError)
        |> F.and (fields.passwordConfirmation |> F.mapError PasswordConfirmationError)
        |> F.andResult
        |> Result.mapError (List.map errorToString)


errorToString : Error -> String
errorToString error =
    case error of
        UsernameError e ->
            Username.errorToString e

        EmailError e ->
            Email.errorToString e

        PasswordError e ->
            Password.errorToString "password" e

        PasswordConfirmationError e ->
            Password.errorToString "password confirmation" e


toFields : SignUp -> Fields
toFields (SignUp fields) =
    fields

And here's what it looks like to use it:

import Example1.Data.SignUp as S

S.init
    |> S.setEmail "ab.c"
    |> S.submit
-- Err ["The username is required.","The email is not valid.","The password is required.","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.submit
-- Err ["The username is required.","The password is required.","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dw"
    |> S.submit
-- Err ["The username must have at least 3 characters.","The password is required.","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne aaaaaaaaaaaaaaaaaaaaaaaaa"
    |> S.submit
-- Err ["The username must have at most 25 characters.","The password is required.","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne"
    |> S.submit
-- Err ["The password is required.","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne"
    |> S.setPassword "1234"
    |> S.submit
-- Err ["The password must have at least 8 characters.","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne"
    |> S.setPassword "12345678"
    |> S.submit
-- Err ["The password must contain at least 1 of each of the following: a lowercase character, an uppercase character, a number, and a special character in the set \"(!@#$%^&*)\".","The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne"
    |> S.setPassword "12345678aB$"
    |> S.submit
-- Err ["The password confirmation is required."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne"
    |> S.setPassword "12345678aB$"
    |> S.setPasswordConfirmation "12345678aB$%"
    |> S.submit
-- Err["The password confirmation does not match."]

S.init
    |> S.setEmail "a@b.c"
    |> S.setUsername "dwayne"
    |> S.setPassword "12345678aB$"
    |> S.setPasswordConfirmation "12345678aB$"
    |> S.submit
-- Ok { email = Email "a@b.c", password = Password "12345678aB$", username = Username "dwayne" }

It has a nice unit testing story.

`Field` and `Field.Advanced`

I've also decided there's going to be two modules, Field and Field.Advanced. The main difference being that Field would use String for custom errors but with Field.Advanced you're able to use your custom error types to delay converting to a string representation for as long as you need.

Debounced input and async fields

Nothing to talk about here as yet. I'll be looking into this soon.

Request for feedback

How has your experience been with forms in Elm? Do you have examples of where current Elm libraries fall short? What would you like to see in a form library for Elm?

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Diary of an Elm Developer - Improving Rules.lookup

Dwayne Crooks — Mon, 19 May 2025 11:33:36 +0000

In the previous post, I mentioned that:

The only issue I have with lookup is that for missing keys it creates a new singleton sequence each time.

Jeroen also pointed out, and rightly so, that:

It's even worse than that: you always create this singleton, because Maybe.withDefault is eager. The fix is simple for this part: use a case expression instead.

lookup : Char -> Rules -> Sequence Char
lookup ch (Rules table) =
    case Dict.get ch table of
        Just replacement ->
            replacement

        Nothing ->
            Sequence.singleton ch

But now we're back to square one and I still don't have a fix for my original issue with lookup.

What are my options?

I considered two options:

Have lookup return a Maybe (Sequence Char) and deal with it downstream.
Have lookup return (Sequence Char, Rules) so that we can update the rules with the missing replacement such that the next time we'd find it in rules and return it.

But there were problems with both approaches.

With the first approach, it just puts off the inevitable, i.e. we'd still be recreating the singleton every time just somewhere else downstream.

With the second approach, we'd have to keep track of the changes to rules within Sequence.concatMap. It could kinda work but I didn't like the API changes that needed to occur for it to happen so I abandoned this idea.

After taking a break and a nice long walk another option revealed itself. Why not determine all the characters that would be looked up ahead of time? L-system generation uses both the rules and axiom. Every character that appears in the final generated sequence comes from one of these values.

Enter `Rules.build`

Rules.build replaces Rules.fromList. It takes both the rules and axiom and builds a dictionary that contains a key for every possible character that could occur in the final generated sequence.

import Dict exposing (Dict)
import Sequence exposing (Sequence)
import Set


build : List ( Char, String ) -> String -> Rules
build rules axiom =
    let
        identity =
            buildIdentity rules axiom
    in
    rules
        |> List.map (Tuple.mapSecond Sequence.fromString)
        |> Dict.fromList
        |> Dict.union identity
        |> Rules


buildIdentity : List ( Char, String ) -> String -> Dict Char (Sequence Char)
buildIdentity rules axiom =
    let
        axiomSet =
            axiom
                |> String.toList
                |> Set.fromList

        ( keySet, valueSet ) =
            rules
                |> List.foldl
                    (\( ch, replacement ) ( prevKeySet, prevValueSet ) ->
                        ( Set.insert ch prevKeySet
                        , replacement
                            |> String.toList
                            |> Set.fromList
                            |> Set.union prevValueSet
                        )
                    )
                    ( Set.empty, Set.empty )

        identityKeySet =
            Set.diff (Set.union axiomSet valueSet) keySet
    in
    identityKeySet
        |> Set.foldl
            (\ch ->
                Dict.insert ch (Sequence.singleton ch)
            )
            Dict.empty

buildIdentity is where the main action happens. It builds a dictionary of characters mapped to their singleton sequences. It's easier to understand how it works via an example.

An example

Input:

rules = [ ( 'F', "F+F-F-FF+F+F-F" ) ]
axiom = "F+F+F+F"

Then,

axiomSet = Set.fromList [ 'F', '+' ]
keySet = Set.fromList [ 'F' ]
valueSet = Set.fromList [ 'F', '+', '-' ]

Since identityKeySet = Set.diff (Set.union axiomSet valueSet) keySet we have:

identityKeySet = Set.fromList [ '+', '-' ]

Therefore, the dictionary that buildIdentity returns is:

Dict.fromList
    [ ( '+', Sequence.singleton '+' )
    , ( '-', Sequence.singleton '-' )
    ]

This dictionary is united with the dictionary we build from the rules:

Dict.fromList
    [ ( 'F', Sequence.fromString "F+F-F-FF+F+F-F" )
    ]

to produce the final dictionary. This allows us to change our implementation of lookup.

The new `lookup`

lookup doesn't need to create singleton sequences anymore because of how the Rules data structure is built and subsequently used. So it changes to:

lookup : Char -> Rules -> Sequence Char
lookup ch (Rules table) =
    case Dict.get ch table of
        Just replacement ->
            replacement

        Nothing ->
            --
            -- This branch would actually never be called by the generation
            -- algorithm but since Elm requires total functions we have to
            -- include it.
            --
            Sequence.empty

Reflections

It's interesting how to improve lookup we actually didn't have to change it much. But it makes sense. build is used once. lookup is used for every character in the sequence, which could be in the millions and billions. So pushing more processing into build in order to improve lookup ever so slightly is a good tradeoff in hindsight.

Diary of an Elm Developer - Lazy L-System generation

Dwayne Crooks — Fri, 16 May 2025 13:58:06 +0000

L-System Studio is an environment for creating and exploring L-Systems. It was built with Elm by Hunor Geréd. I learnt about the project when he decided to submit it to Built with Elm back in April 2023. It's a fun application for exploring L-Systems but it can be quite resource intensive. My browser has even crashed on several occasions. Definitely not a good look for Elm. Could the performance be improved whilst using Elm or do we have to resort to mutable generation in JavaScript? That was the nagging question.

What's the problem?

The first thing that caught my attention was the huge number of SVG nodes that were being generated in the DOM. Those SVG nodes are created by looping over the array of characters returned by LSys.generateSequence. It's not one to one but the number of SVG nodes that are added to the DOM can be very close to the number of characters in the array. And that array gets really large really quickly.

> import LSys
> import Array

> LSys.generateSequence 4 "F+F+F+F" [('F', String.toList "F+F-F-FF+F+F-F")] |> Array.length
30427 : Int

> LSys.generateSequence 5 "F+F+F+F" [('F', String.toList "F+F-F-FF+F+F-F")] |> Array.length
243419 : Int

> LSys.generateSequence 6 "F+F+F+F" [('F', String.toList "F+F-F-FF+F+F-F")] |> Array.length
1947355 : Int

> LSys.generateSequence 7 "F+F+F+F" [('F', String.toList "F+F-F-FF+F+F-F")] |> Array.length

<--- Last few GCs --->

[17075:0x2724f250]    11351 ms: Scavenge 2022.8 (2062.0) -> 2022.6 (2073.0) MB, 3.52 / 0.00 ms  (average mu = 0.173, current mu = 0.111) allocation failure; 
[17075:0x2724f250]    11359 ms: Scavenge 2029.6 (2073.0) -> 2030.4 (2073.7) MB, 5.33 / 0.00 ms  (average mu = 0.173, current mu = 0.111) allocation failure; 
[17075:0x2724f250]    11668 ms: Scavenge 2030.4 (2073.7) -> 2029.6 (2096.7) MB, 309.40 / 0.00 ms  (average mu = 0.173, current mu = 0.111) allocation failure; 


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0xab10e4 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 2: 0xe6de60 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 3: 0xe6e244 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 4: 0x109d907  [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 5: 0x10b6479 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 6: 0x108f0e7 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 7: 0x108fd24 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 8: 0x106f04e v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
 9: 0x14d8d70 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/nix/store/dcdc33kdjdhjnzg6rkmd0cx4kpwl8cac-nodejs-20.17.0/bin/node]
10: 0x719fe2699ef6

N.B. I used my fork of the repository which I shared as an example in GitHub Actions, Devbox, and Elm.

I can't even check the length of the array after 7 iterations because the algorithm used for generation is using up too much memory.

How does `LSys.generateSequence` work?

generateSequence : Float -> String -> List ( Char, List Char ) -> Array Char
generateSequence iterations axiom rules =
    let
        expandSymbol symbol =
            case Extra.find (\( s, _ ) -> s == symbol) rules of
                Just ( _, replacement ) ->
                    Array.fromList replacement

                Nothing ->
                    Array.fromList [ symbol ]
    in
    List.foldl
        (\_ seq ->
            Array.map expandSymbol seq
                |> Array.toList
                |> List.map Array.toList
                |> List.concat
                |> Array.fromList
        )
        (String.toList axiom |> Array.fromList)
        (List.range 1 (round iterations))

iterations - The number of iterations
axiom - The initial string
rules - The rewrite rules

Recall List.foldl : (a -> b -> b) -> b -> List a -> b.

For each character in the array we apply expandSymbol to it. expandSymbol attempts to find a rewrite string (represented as a list of characters) for a given character. A new array of lists is built which is eventually transformed back into an array of characters. A lot of intermediate lists and arrays are built up along the way. This is done round iterations number of times over arrays of increasing length.

expandSymbol searches an association list multiple times for the same symbol and each time it creates a new array from the replacement list of characters it finds.

It seems then that a poor choice of data structures and algorithms has led to performance and memory issues.

Thoughts after the investigation

Why is iterations even a Float?
rules would be easier to enter via elm repl if it had the type List ( Char, String ).
rules should be processed into a data structure that has good lookup performance.
The replacements returned by a rule lookup should be created exactly once.
An array or a list is not the right data structure for storing the characters generated by a given L-System since when stored in memory it will take up too much space. We need to be able to represent the whole value that could be generated but only generate what's needed at any given point in time. Could lazy evaluation work here?
Maybe I could repurpose Logic.Stream from my The Reasoned Schemer (2nd Edition) project to use as the data structure for the in-memory representation of the entire L-System.

The new API

This is the new API I came up with:

module LSystem exposing (generate)

generate : Int -> List ( Char, String ) -> String -> Sequence Char

module Rules exposing
    ( Rules

    -- Create
    , fromList

    -- Query
    , lookup
    )

type Rules

fromList : List ( Char, String ) -> Rules

lookup : Char -> Rules -> Sequence Char

module Sequence exposing
    ( Sequence

    -- Create
    , singleton, fromString

    -- Combine
    , concat, concatMap

    -- Query
    , length

    -- Convert
    , uncons, toList
    )

type Sequence a

singleton : a -> Sequence a
fromString : String -> Sequence Char

concat : Sequence a -> Sequence a -> Sequence a
concatMap : (a -> Sequence b) -> Sequence a -> Sequence b

length : Sequence a -> Int

uncons : Sequence a -> Maybe ( a, Sequence a )
toList : Sequence a -> List a

`LSystem`

module LSystem exposing (generate)

import Rules exposing (Rules)
import Sequence exposing (Sequence)


generate : Int -> List ( Char, String ) -> String -> Sequence Char
generate n rules axiom =
    generateHelper n (Rules.fromList rules) (Sequence.fromString axiom)


generateHelper : Int -> Rules -> Sequence Char -> Sequence Char
generateHelper n rules current =
    if n <= 0 then
        current

    else
        let
            next =
                Sequence.concatMap (flip Rules.lookup rules) current
        in
        generateHelper (n - 1) rules next


flip : (a -> b -> c) -> b -> a -> c
flip f b a =
    f a b

The number of iterations, n, is represented as an Int.

rules input has changed to List ( Char, String ) which should make it easier to enter on the elm repl or for tests but that's not the way rules are used internally. They are processed into a data structure, Rules.fromList rules, that has better lookup performance than an association list.

The looping is done using generateHelper which is implemented tail-recursively to ensure we don't blow the stack. Though that may not have been necessary since n doesn't need to be too large. For e.g. 50 iterations is probably over doing it. Either way, the implementation can handle millions of iterations now.

The workhorse of the algorithm is Sequence.concatMap. It is used to transform the sequence from one iteration to the next.

`Rules`

module Rules exposing (Rules, fromList, lookup)

import Dict exposing (Dict)
import Sequence exposing (Sequence)


type Rules
    = Rules (Dict Char (Sequence Char))


fromList : List ( Char, String ) -> Rules
fromList =
    Rules << Dict.fromList << List.map (Tuple.mapSecond Sequence.fromString)


lookup : Char -> Rules -> Sequence Char
lookup ch (Rules table) =
    Dict.get ch table
        |> Maybe.withDefault (Sequence.singleton ch)

Rules is an opaque type that is implemented as a dictionary. The keys are characters and the values are preprocessed, List.map (Tuple.mapSecond Sequence.fromString), into sequences that get reused each time a key is looked up.

lookup finds the expansion for a given character.

N.B. The only issue I have with lookup is that for missing keys it creates a new singleton sequence each time. Any ideas to avoid doing that would be appreciated.

`Sequence`

module Sequence exposing
    ( Sequence
    , singleton, fromString
    , concat, concatMap
    , length
    , uncons, toList
    )


type Sequence a
    = Empty
    | Cons a (Sequence a)
    | Thunk (() -> Sequence a)

A sequence is a combination of a list and a lazy list. An idea I stole from The Reasoned Schemer (2nd Edition).

If you remove the Thunk constructor then you have a list.

type List a
    = Empty
    | Cons a (List a)

If you combine the Cons and Thunk constructors then you have a lazy list.

type LazyList a
    = Empty
    | Cons a (() -> LazyList a)

Create

singleton : a -> Sequence a
singleton x =
    Cons x Empty


fromString : String -> Sequence Char
fromString s =
    Thunk (\_ -> String.foldr Cons Empty s)

Combine

concat : Sequence a -> Sequence a -> Sequence a
concat a b =
    case a of
        Empty ->
            b

        Cons head tail ->
            Cons head (concat tail b)

        Thunk t ->
            Thunk (\_ -> concat (t ()) b)


concatMap : (a -> Sequence b) -> Sequence a -> Sequence b
concatMap f s =
    case s of
        Empty ->
            Empty

        Cons head tail ->
            concat
                (f head)
                (concatMap f tail)

        Thunk t ->
            Thunk (\_ -> concatMap f (t ()))

The major difference between this implementation and Logic.Stream is that Sequence.concat which corresponds to Logic.Stream.append doesn't interleave between sequences.

Query

length : Sequence a -> Int
length =
    lengthHelper 0


lengthHelper : Int -> Sequence a -> Int
lengthHelper n s =
    case s of
        Empty ->
            n

        Cons _ tail ->
            lengthHelper (n + 1) tail

        Thunk t ->
            lengthHelper n (t ())

Sequences can get very long after relatively few iterations, much longer than the value an Int can store. So this length is really only useful for debugging purposes and it has to be implemented tail-recursively to ensure it gets optimized into a loop. Otherwise, it won't even be helpful for debugging.

Convert

uncons : Sequence a -> Maybe ( a, Sequence a )
uncons s =
    case s of
        Empty ->
            Nothing

        Cons head tail ->
            Just ( head, tail )

        Thunk t ->
            uncons (t ())


toList : Sequence a -> List a
toList s =
    case s of
        Empty ->
            []

        Cons head tail ->
            head :: toList tail

        Thunk t ->
            toList (t ())

uncons allows you to process the sequence one character at time. It's not used for generation but my plan is to use it for rendering.

toList is only useful for debugging purposes on small sequences. I didn't even bother to make it tail-recursive.

Results

> import LSystem
> import Sequence

> Sequence.length <| LSystem.generate 6 [('F', "F+F-F-FF+F+F-F")] "F+F+F+F"
1947355 : Int

> Sequence.length <| LSystem.generate 7 [('F', "F+F-F-FF+F+F-F")] "F+F+F+F"
15578843 : Int

> Sequence.length <| LSystem.generate 8 [('F', "F+F-F-FF+F+F-F")] "F+F+F+F"
124630747 : Int

> Sequence.length <| LSystem.generate 9 [('F', "F+F-F-FF+F+F-F")] "F+F+F+F"
997045979 : Int

> Sequence.length <| LSystem.generate 10 [('F', "F+F-F-FF+F+F-F")] "F+F+F+F"
7976367835 : Int

> Sequence.uncons <| LSystem.generate 100 [('F', "F+F-F-FF+F+F-F")] "F+F+F+F"
Just ('F',Cons '+' (Cons 'F' (Cons '-' (Cons 'F' (Cons '-' (Cons 'F' (Cons 'F' (Cons '+' (Cons 'F' (Cons '+' (Cons 'F' (Cons '-' (Cons 'F' (Cons '+' (Thunk <function>)))))))))))))))

Iteration 10 of the L-System we started off with has over 7 billion characters. 🤯

We can now generate and store the result of 100 iterations of the L-System and process it one character at time. 🎉

How are we going to render the L-System if we can't store it in a list or put billions of SVG nodes in the browser? These are questions best left for another day.

Interesting Related Resources

Why Functional Programming Matters by John Hughes at Functional Conf 2016
- Word-at-a-time programming vs whole value programming
  - One Word at a Time
- Lazy evaluation implied whole value programming was possible
  - John Hughes was interested in separating the decision of how many things to compute from the code you have to compute
  - Lazy Evaluation
Recursive Programming Techniques
- Section 3.10 - Sequences, Coroutines, and Streams

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

Diary of an Elm Developer

Dwayne Crooks — Thu, 15 May 2025 14:00:45 +0000

Every morning I gift myself 90 mins to work on anything I desire. Sometimes I read interesting books (1, 2, 3, 4), other times I learn new skills (5, 6) but most times I work on programming projects.

For a long time now those programming projects have been Elm related. What can I say? I simply enjoy using Elm. I've tried to share my knowledge along the way by taking the time to reflect on what I've done and by writing about it from my perspective. On many occasions I just shared the work and put off sharing my thoughts about the work for so long that it became a chore to write about it.

Reflecting and writing about my programming selfishly helps me improve my software development skills. Writing in public forces me to think more deeply about what I'm doing and why I'm doing it such that it gives me a richer understanding of my craft. A positive side effect is that what I share could also potentially help others. Though, I try to temper my hubris and not fool myself into thinking that random people on the internet actually care about what I have to say.

Given that I sometimes don't share and write about my work as often as I'd like and that I think sharing and writing about my work helps myself and others, I've decided to start a new series on this blog called "Diary of an Elm Developer". It's a way for me to give myself permission to share more frequently about my Elm related excursions in an open and freer format.

I'm feeling excited about this new series. Stay tuned!

Subscribe to my newsletter

If you're interested in improving your skills with Elm then I invite you to subscribe to my newsletter, Elm with Dwayne. To learn more about it, please read this announcement.

DEV Community: Dwayne Crooks

Elm + Nix: A reproducible RealWorld clone

The Classics

TodoMVC

Super Rentals

7GUIs

Related posts

Contact me for Nix training and support

Subscribe to my newsletter

Nix + pnpm + Parcel + lydell/elm-safe-virtual-dom

Rewriting the project to use dwayne/elm2nix

Name your development shell

Use the programming language's package manager

Use aliases/functions to make it easier to perform common tasks

Building with pnpm and Parcel in Nix

Adopting lydell/elm-safe-virtual-dom

How it works

Further reading

Subscribe to my newsletter

Making TodoMVC work with dwayne/elm2nix

Run the web application from any machine with Nix installed

Reliable CI

The changes

HTML

CSS

Elm

Web app

Serving locally

Quality assurance

Conclusion

Further reading

Subscribe to my newsletter

Announcing dwayne/elm2nix

What is dwayne/elm2nix?

How to use dwayne/elm2nix?

What's changed or improved?

You can input one or more elm.json files to create the lock file

registry.dat is automatically generated for you

You can display any registry.dat file as JSON

The buildElmApplication build helper allows you to build an Elm web application in a variety of ways by setting options

Turn on the time-travelling debugger

Fail the build if your Elm source code is improperly formatted

Fail the build if your Elm tests fail

Fail the build if elm-review fails

Turn on optimizations

Combine multiple Elm web applications into one JavaScript file

Enable minification with UglifyJS or Terser

Enable compression with gzip and brotli

Show a report about the changes in your file size due to minification and compression

Enable content hashing for cache busting purposes

All at once

Advanced: The derivations and scripts that make buildElmApplication work are readily available for you to use for your own purposes

prepareElmHomeScript

dotElmLinks

Conclusion

Subscribe to my newsletter

Frontend Mentor's Contact form challenge built with Elm

How I built the form

The UI

elm/html

Form logic

Glue code

Astro as a frontend workshop environment

Project structure

Miscellaneous

Subscribe to my newsletter

Announcing elm-field

An example

No UI

Richard's comment

Subscribe to my newsletter

Diary of an Elm Developer - From fields to forms

Sign Up form

Initialize

Update

Validate

Putting it all together

A simple view of the Sign Up form

Model

Update

Rewriting the project to use `dwayne/elm2nix`

Adopting `lydell/elm-safe-virtual-dom`

What is `dwayne/elm2nix`?

How to use `dwayne/elm2nix`?

You can input one or more `elm.json` files to create the lock file

`registry.dat` is automatically generated for you

You can display any `registry.dat` file as JSON

The `buildElmApplication` build helper allows you to build an Elm web application in a variety of ways by setting options

Fail the build if `elm-review` fails

Advanced: The derivations and scripts that make `buildElmApplication` work are readily available for you to use for your own purposes

`prepareElmHomeScript`

`dotElmLinks`

`elm/html`

Bonus: `InteractionTracker`

Enter `InteractiveInput`

`viewInteractiveInput`

`Lib.DebouncedField`

Enter `Lib.DebouncedInput`

How I made `Angle` into a field

`Field` and `Field.Advanced`

Enter `Rules.build`

The new `lookup`

How does `LSys.generateSequence` work?

`LSystem`

`Rules`

`Sequence`