Part III: Building Real Applications

https://leanpub.com/elm-for-react-devs",{"_483":484,"_43":44,"_47":48,"_45":46,"_65":66,"_485":486,"_606":481},"previewContent","

\n \n
- \nIntroduction\n
- \nAbout the Author\n
\n
\nPart I: From React to Elm: Getting Started\n
- \nChapter 1: Elm: Delightful Constraints\n
  - \nReact Recommends, Elm Requires and Enables\n
  - \nWhen Constraints Give Freedom\n
  - \nThe Debugging Clarity\n
  - \nRefactoring with Confidence\n
  - \nThe Architectural Discipline\n
  - \nWhat This Costs You\n
  - \nWhat Elm Teaches You\n
  \n
- \nChapter 2: The Elm Architecture – A Recipe for Reliable Apps\n
  - \nThe Recipe: Four Simple Ingredients\n
  - \nIngredient 1: Model - Your State Shape\n
  - \nIngredient 2: Msg - Things That Can Happen\n
  - \nIngredient 3: update - How State Changes\n
  - \nIngredient 4: view - Rendering Your State\n
  - \nPutting It All Together: Counter with Undo\n
  - \nThe Elm Runtime Loop\n
  - \nWhat React Developers Already Know\n
  - \nWhat Makes TEA Different\n
  - \nThe Price of Explicitness\n
  - \nWhat You Just Learned (The FP Hiding in Plain Sight)\n
  - \nWhat’s Next\n
  \n
- \nChapter 3: Your First Elm App\n
  - \nInstalling Elm\n
  - \nEditor Setup\n
  - \nSetting Up Your Project\n
  - \nThe obligatory “Hello, world!”\n
  - \nTwo Flavors of main\n
  - \nThe LGTM Generator: Building It Step by Step\n
  - \nBuilding Your First Elm App\n
  - \nCompiler-Driven Development in Action\n
  - \nWhat You Just Built\n
  \n
- \nChapter 4: Starting Small: Elm in Your React Codebase\n
  - \nWidget-by-widget Incremental Adoption Strategy\n
  - \nIntegrating One Elm Component into React\n
  - \nBuild Systems and Toolchain Integration\n
  - \nScaling This Approach\n
  \n
\n
\nPart II: The Outside World: Randomness, APIs, and JavaScript\n
- \nChapter 5: Commands and Randomness\n
  - \nUpgrading from Browser.sandbox to Browser.element\n
  - \nThe Cmd Type and How It Works\n
  - \nAdding Randomness to the LGTM Generator\n
  - \nWhat You Just Learned\n
  \n
- \nChapter 6: HTTP and Remote Data\n
  - \nFrom Random.generate to Http.get\n
  - \nSetting Up the Server\n
  - \nInstalling elm/http\n
  - \nThe Shape of HTTP in Elm\n
  - \nSuccess | Loading | Error\n
  - \nCreating the HTTP Request\n
  - \nUpdating init\n
  - \nRefactoring the GotPhrase Message\n
  - \nHandling Results in update\n
  - \nRendering Different States\n
  - \nThe Complete Code\n
  - \nCommands Are Just Commands\n
  - \nWhat You Just Learned\n
  \n
- \nChapter 7: JSON Decoders and Type Safety\n
  - \nWhy JSON Needs Decoding in Elm\n
  - \nSupporting JSON in Our LGTM Generator\n
  - \nWhat About Sending JSON?\n
  - \nWhat You Just Learned\n
  - \nFurther Reading\n
  \n
- \nChapter 8: JavaScript Interop: Ports and Flags\n
  - \nJavaScript as Infrastructure\n
  - \nUpgrading Our Build for Manual Bootstrapping\n
  - \nFlags as Program Input\n
  - \nPorts for Communicating with JavaScript\n
  - \nAdding Clipboard Support to the LGTM Generator\n
  - \nWhat You Just Learned\n
  \n
\n
\nPart III: Building Real Applications\n
- \nChapter 9: Organizing Files and Modules\n
  - \nMoving Beyond the Single-File Approach?\n
  - \nElm is Different\n
  - \nLet’s Build an Advent Calendar App\n
  - \nBasic Advent Calendar Spec\n
  - \nStarting Simple: The Mock Date Version\n
  - \nGetting the Real Date: Enter Tasks\n
  - \nWhen to Split: Modules for Data Structures\n
  - \nThe Freedom of Safe Refactoring\n
  - \nWhat We’ve Learned\n
  \n
- \nChapter 10: Modules Around Data Structures\n
  - \nOpaque Types: Hiding What Shouldn’t Be Seen\n
  - \nGoing Further: Phantom Types\n
  - \nThe Complete Calendar Module\n
  - \nUsing the Calendar Module\n
  - \nWhat We Gained\n
  - \nThe Broader Pattern: State Machines in Types\n
  - \nWhen to Use Each Pattern\n
  - \nThe Freedom to Reorganize\n
  - \nWhat We’ve Learned\n
  \n
- \nChapter 11: Forms and Validation\n
  - \nA Simple Contact Form\n
  - \nWhen Validation Enters the Picture\n
  - \nFinding the Right Abstraction\n
  - \nWhat We Learned\n
  \n
- \nChapter 12: Building a Feedback Wizard\n
  - \nThe Problem: A Feedback Widget\n
  - \nModeling the Top-Level State\n
  - \nThe OutMsg Pattern\n
  - \nWhy OutMsg Works\n
  - \nNative Dialogs and Ports\n
  - \nThe Complete Main Module\n
  - \nThe Api Module\n
  - \nPatterns Worth Noting\n
  - \nWhat We Learned\n
  \n
\n
\nParts III-V\n
- \nWhat’s Coming\n
- \nAppendix B: The Scary Words You Already Understand\n
  - \nWhy Elm Avoids This Terminology\n
  - \nFunctors: Things You Can Map Over\n
  - \nApplicatives: When You Have Multiple Wrapped Values\n
  - \nMonads: Chaining Operations That Might Fail\n
  - \nThe Elm to Haskell Rosetta Stone\n
  - \nCommands and Tasks: The IO Monad in Disguise\n
  - \nWhere to Go From Here\n
  \n
\n

Introduction

\n\n\n

If you’re a React developer, chances are you’ve felt the framework’s power and complexity. Hooks are incredibly flexible, TypeScript catches many errors—yet runtime surprises still slip through. useEffect dependencies that never feel quite right. Performance bugs requiring strategic React.memo and useCallback. These aren’t signs you’re doing React wrong; they’re the inherent trade-offs of React’s flexibility.

Some of my most-read posts are the deep-dive React articles—especially on React.memo and reconciliation. A few are used in React courses, and some have even been translated to Korean(!). This popularity reflects a truth: once you step beyond the basics, React’s complexity increases dramatically and the good can become challenging faster than you expect.

Elm takes a very different approach. Elm isn’t a UI library. It’s a small language with one way to build applications, designed for reliability and clarity. With Elm, you trade flexibility for focus. There’s exactly one architecture (The Elm Architecture, or TEA), exactly one way to represent side effects, and a type system that works relentlessly to prevent runtime errors. The result is a developer experience that feels—at least at first—strangely quiet. You don’t spend hours debugging why your component didn’t re-render or why state mutated unexpectedly. Instead, you spend time modeling your problem domain.

For React developers, the first encounter with Elm can feel almost too simple. There are no hooks to juggle, no contexts to configure, no class vs. function components. Just a Model, an Update function, and a View. And yet, that simplicity scales to codebases with hundreds of thousands of lines.

So why consider Elm if you already know React?

\nTo catch more errors at compile time. Many React/TypeScript errors show up only in the browser. Elm’s compiler is famously strict: if it compiles, it’s very likely to work.\n
\nTo simplify mental overhead. Fewer concepts mean fewer ways to get things wrong. Instead of choosing between a dozen state management solutions, Elm gives you one—TEA.\n
\nBecause it’s actually fun. Many developers describe Elm as enjoyable to work with. The compiler points you toward fixes, the language encourages clear modeling, and your app tends to just work once it compiles.\n

But there’s a deeper reason to learn Elm, even if you never use it professionally: it’s the fastest way to truly learn functional programming. Not watered-down FP, not FP-flavored JavaScript patterns, but real, uncompromising functional programming—the kind that changes how you think about code in any language. Haskell has too many language features and quirks, making it notoriously hard to get started with something practical. Elm, by contrast, is remarkably small and focused—the entire language fits in your head. And crucially, you’re working in a domain you already know: building web UIs. This combination of strict FP discipline and immediate practical application makes Elm uniquely effective as a learning tool. If you’ve ever wanted to “level up” as a developer by learning functional programming, Elm is your shortest path. Especially if you’re already familiar with React.

This book is not about convincing you to abandon React. Instead, it’s a guided tour for React developers: what Elm looks like, how it compares, and how you might start using Elm—even if only as a single widget inside a React app. By the end, you should have a feel for whether Elm can play a role in your work. And, perhaps even more importantly: you will have learned functional programming along the way!

If React has been your main frontend toolkit, think of Elm as a chance to see what frontend development feels like with different trade-offs. It may not be for every project—but once you’ve experienced the calm of Elm’s compiler, you may find yourself wishing more of your codebases worked this way.

And, quite frankly, learning Elm will be worthwhile whether you end up using it professionally or not.

To give you a taste of what I mean, let me show you the kind of guarantees Elm provides. Throughout this book, you’ll see what I call “Elm Hooks” in each chapter—compelling previews of what makes Elm delightful for that particular topic. React has hooks for state management, but Elm has hooks that keep you hooked on the language itself.

Let’s try one right away. It’ll demonstrate two of Elm’s main selling points: the friendly compiler and the strict type system (or, good cop / bad cop, if you prefer).

\n\n\n\n

$\"An$

Elm Hook

Given the following Elm code

 1 type Animal = Cat | Dog | Penguin\n 2 \n 3 \n 4 animalToString : Animal -> String\n 5 animalToString animal =\n 6     case animal of\n 7         Dog ->\n 8             \"dog\"\n 9 \n10         Cat ->\n11             \"cat\"\n12 \n13         -- Ooops, forgot about that Penguin!\n

\n\n

The compiler answers the following:

 1 -- MISSING PATTERNS --------------- /path-to-your/src/Main.elm\n 2 This `case` does not have branches for all possibilities:\n 3 \n 4 306|>    case animal of\n 5 307|>        Dog ->\n 6 308|>            \"dog\"\n 7 309|>\n 8 310|>        Cat ->\n 9 311|>            \"cat\"\n10 \n11 Missing possibilities include:\n12 \n13     Penguin\n14 \n15 I would have to crash if I saw one of those. Add branches for them!\n16 \n17 Hint: If you want to write the code for each branch later, use `Debug.todo` as a\n18 placeholder. Read <https://elm-lang.org/0.19.1/missing-patterns> for more\n19 guidance on this workflow.\n

\n\n

Sure beats all those ensureNever helpers you’ve written in TypeScript, huh?

About the Author

Christian Ekrem is a Staff Engineer with over 12 years of experience building production systems at scale. He works daily in a production Elm codebase with over 125,000 lines of code at Lovdata, Norway’s leading legal information provider. This real-world experience—not just toy projects—informs every comparison and recommendation in this book.

His journey spans multiple platforms and languages: six years at Vipps MobilePay (Norway’s leading mobile payment platform) working across backend development in Go and React, Android development in Kotlin, and eventually becoming the first engineer to work across both simultaneously. This diversity gives him a unique perspective on what makes code maintainable and genuinely better.

Christian’s background extends beyond tech—he’s taught at a special-needs high school and worked as a film director. This varied experience taught him how to explain complex concepts clearly and meet people where they are, which is exactly what this book aims to do for React developers learning Elm.

Why this book exists: Christian believes Elm is the fastest way for developers to truly learn functional programming. Whether you adopt Elm professionally or not, learning it will make you a better developer in any language. This book is his way of sharing that insight with React developers ready to level up.

You can read more of his writing on technology and functional programming at cekrem.github.io.

Part I: From React to Elm: Getting Started

Chapter 1: Elm: Delightful Constraints

\n\n\n

Remember that Penguin example from the introduction? That kind of exhaustive checking isn’t just for pattern matching; it’s actually how Elm approaches everything. Let me show you what this means for everyday development.

You refactor a type. You rename a field from status to orderStatus. You update the code, run your tests, and ship it. A week later, production errors start rolling in: Cannot read property 'status' of undefined.

You missed one usage. It was buried in an error handler that only runs when a specific edge case triggers. TypeScript didn’t catch it because that file had an any type. Your tests didn’t catch it because you hadn’t written a test for that exact scenario. ESLint was silent because the code was syntactically fine.

This isn’t a story about carelessness. You’re a good developer. You ran the tests. You checked your work. But in a codebase of any size, it’s impossible to keep every usage of every field in your head. You rely on tools to catch what you forget.

And sometimes, your tools don’t catch everything.

React Recommends, Elm Requires and Enables

Here’s something I’ve noticed working with both React and Elm: they’re heading in the same direction, but taking different paths to get there.

Look at how React has evolved:

\nHooks moved us toward functional components and immutable state\n
\nRedux brought predictable state management to the mainstream\n
\nTypeScript went from optional to essential for serious projects\n
\nServer Components push side effects to the server\n

Each change pushes React toward functional programming principles. Immutability, pure functions, explicit state management—these are all things the React community now considers best practices.

A senior React developer I know put it this way: “Good React code in 2025 looks suspiciously like Elm code from 2015.”

But here’s the key difference: React recommends functional programming. Elm requires it. The constraints that feel limiting at first actually free you—you stop worrying about entire classes of bugs and start focusing on solving actual problems instead of debugging state mutations.

In React, you can still mutate variables. You can mix paradigms. You can create runtime errors. The language allows it. The community discourages it, but JavaScript (or TypeScript) doesn’t stop you.

In Elm, it’s simply impossible. Not hard. Not discouraged. Impossible. The language won’t compile if you try to mutate data.

This isn’t about React being bad—React’s flexibility is a feature. But that flexibility comes with a cost: you have to maintain the discipline yourself.

When Constraints Give Freedom

It sounds paradoxical: how can stricter constraints give you more freedom? But consider a common debugging scenario in JavaScript:

1 const user = { name: \"Ada\", age: 29 };\n2 someFunction(user);\n3 console.log(user.name); // What's the name now?\n

\n\n

You can’t know without reading someFunction. Maybe it mutates the user. Maybe it doesn’t. Maybe it mutates it conditionally? You have to trace through the code to be sure. Even the most elaborate typings can’t give complete compile-time guarantees that an object will not be mutated; it’s simply not possible. There are ways to prevent this at runtime with recursive variations of Object.freeze, but imposing such restrictions in TypeScript requires discipline. And ironically, even the Object.freeze method itself can be mutated!

This isn’t just a theoretical problem. I’ve spent hours debugging issues where data was mutated in unexpected places. A function I thought was safe was actually changing my state. The bug only appeared in specific conditions, which is why the tests didn’t catch it.

Now look at the Elm equivalent:

1 user = { name = \"Ada\", age = 29 }\n2 \n3 -- This doesn't compile, whether done inline like here or in a function you pass it to:\n4 user.name = \"Grace\"  -- ERROR: Elm doesn't have variable mutation\n5 \n6 -- The right way:\n7 updatedUser = { user | name = \"Grace\" }  -- Creates a new record\n

\n\n

The compiler makes mutation impossible. When you pass user to a function, you know it comes back unchanged. Not because you trust the function author. Not because code review caught it. But because the language doesn’t allow anything else. If you’ve ever used Rust, you know that the distinction between a variable and a mutable variable is an important one. In Elm, they’re all immutable.

This constraint eliminates entire categories of bugs. You stop wondering “who changed this value?” because nothing can. The constraint gives you freedom from a whole class of debugging sessions.

The Debugging Clarity

This immutability guarantee changes how you reason about code. In React, when state is wrong, you have to trace backward: Where was this set? What changed it? Did something mutate it accidentally?

In Elm, when state is wrong, you look at your update function. That’s it. That’s the only place state changes. If the state is wrong, the logic in update is wrong. No hidden mutations. No stale closures. No wondering if some other component changed something.

At our production app (a 120k+ lines Elm codebase), we’ve had entire months with zero runtime exceptions in our Elm code. Not because we’re better developers than when we wrote TypeScript. But because the compiler catches those errors before the code runs.

\n\n\n\n

$\"An$

Elm Hook

You know that moment when you refactor a type but forget to update one place that uses it? In Elm, you literally cannot compile until you fix every single usage. The compiler won’t let you ship the incomplete refactor. It’s impossible to “forget one spot.”

Refactoring with Confidence

This reliability becomes especially valuable when making large-scale changes.

Let’s say you need to add a new state to your application—maybe a Paused state for a game, or a Refreshing state for data loading. In React, you’d:

\nAdd 'paused' to your TypeScript union type\n
\nSearch the codebase for places that check the state\n
\nUpdate each one, hoping you found them all\n
\nTest manually, hoping you caught the edge cases\n
\nShip and monitor for bugs\n

In Elm, you:

\nAdd Paused to your union type\n
\nTry to compile\n
\nThe compiler lists every place that needs updating\n
\nFix each one\n
\nWhen it compiles, you’re done\n

I refactored a complex state machine recently—47 places needed updates. The compiler found all 47. I fixed them one by one. When the code compiled, I deployed it. No bugs. No forgotten edge cases. The compiler had verified completeness.

That’s not a guarantee of correctness—I can still have logic bugs. But it’s a guarantee that every code path handles every state. No gaps.

The Architectural Discipline

If you’ve read about Clean Architecture or SOLID principles, you know they’re good ideas. Single Responsibility, Dependency Inversion, separation of concerns—these patterns lead to maintainable code.

But they’re also discipline. You have to remember to follow them. Code review has to catch violations. It’s easy to cut corners when you’re rushing.

The Elm Architecture enforces these patterns by default. Again: not as guidelines—as requirements:

\nSingle Responsibility: The compiler forces you to separate View, Update, and Model\n
\nPure Functions: Mutation is impossible, so all your functions are automatically pure\n
\nExplicit Effects: Side effects must go through Commands; you can’t just call an API in your update logic\n
\nExhaustive Handling: Pattern matching forces you to handle every case\n

Where other languages offer SOLID as “best practices” you should follow if disciplined, these patterns are mandatory in Elm. The compiler is your relentless architecture mentor.

What This Costs You

Let’s be direct: Elm’s strictness has real costs.

The ecosystem is smaller. React has thousands of libraries. Elm has hundreds. You’ll find yourself writing more from scratch.

The learning curve is steeper. Functional programming is different if you’re coming from JavaScript. Pattern matching, union types, immutability—these take time to internalize.

Your team needs to learn. Hiring is harder. Onboarding takes longer. Not every developer wants to learn a niche language.

You lose flexibility. Sometimes you just want to mutate a value and move on. Elm won’t let you. You have to do it the “right” way, even when the shortcut would probably work.

For some projects, these costs aren’t worth it. If you’re prototyping, exploring, or building something simple, React’s flexibility is valuable. You want to move fast, not satisfy a strict compiler. Doubly so if React has become second nature: when going fast, using familiar tools is a win in and of itself! And honestly, for most projects today, React is still the pragmatic choice—and that’s perfectly fine.

But for other projects—production applications where bugs are expensive, complex state machines, financial tools, healthcare systems—Elm’s guarantees are worth the upfront cost.

And, to be completely honest: At this point I personally prefer Elm even for the occasional whimsical side-project that won’t hurt a fly no matter how hard it crashes. As you’ll hopefully discover for yourself before too long: Elm is kind of addictive, and fun to work with!

What Elm Teaches You

Here’s what I’ve realized: Elm’s value isn’t just in using it. It’s in what it teaches you.

Learning Elm changes how you think about code. Mutable state starts looking suspicious. You design types that actually prevent bugs instead of just documenting intent. You write better React because these patterns become second nature.

The React community is moving toward Elm’s ideas—hooks, immutability, type safety, isolated effects. These aren’t Elm-specific. They’re functional programming principles that apply everywhere. And Elm is uniquely effective at teaching them because you’re building real UIs, not studying academic theory.

Here’s what I’ve come to realize: Elm is the fastest way to truly learn functional programming. Not because it teaches you monads and functors (Elm never even mentions them), but because it makes functional programming impossible to avoid. Try to mutate a variable? Compiler says no. Try to ignore a case? Compiler says no. Try to hide side effects? Nope. You can’t cheat your way around it, so you learn to think functionally.

Compare this to learning FP through Haskell or OCaml. Those languages are powerful, but they’re also large and complex. Haskell has lazy evaluation, type classes, monad transformers, dozens of language extensions. By the time you understand enough to build something useful, months have passed.

Elm’s entire language fits in your head in a weekend. No classes. No inheritance. No async/await, no promises, no null, no undefined. Just functions, types, and one architecture pattern. The smallness isn’t a limitation—it’s what makes learning fast.

And crucially, you’re building in a domain you already know. If you’re coming from React, you understand components, events, state updates. Elm uses different mechanics, but the same concepts. You’re not learning abstract category theory—you’re building the same UIs you built yesterday, just with different guarantees.

As I’ll argue again and again throughout this book: This matters even if you never use Elm professionally. The functional thinking you develop transfers directly to any language. Modeling with types, making illegal states unrepresentable, treating data immutably—these patterns make you write better TypeScript, better Python, better anything. And if you eventually need to learn Haskell, F#, or OCaml, you’ll have a solid head start since you already understand the core concepts.

In the next chapter, we’ll stop talking philosophy and look at code. We’ll build the same application in both React and Elm, side by side. You’ll see exactly what these guarantees look like in practice—the syntax, the patterns, the developer experience.

Are you ready?

Chapter 2: The Elm Architecture – A Recipe for Reliable Apps