Introduction
This is a story of a guy who left it all to chase Elm full time, the technical trials and tribulations he faced, the euphoric and … not so euphoric bits of writing a SPA in Elm. My scope is ambitious, use these italic summary headers to decide on the sections you want to read.
Total word count: around 13,000
Reading time: 65 minutes. + Code snippets
Published: 8th April 2018
I write Elm at Pacific Health Dynamics, a small health insurance software vendor with big dreams. Since July 2017, I’ve been leading the frontend rewrite of their flagship product.
The rewrite of the legacy application was already at 16k LoC when I joined 10 months ago. Since then, I’ve rewritten the various subsystems at least once (I'm looking at you generic form component) and introduced core structures necessary for SPAs. The codebase is now at 45k LoC (a third of the way to completion). This is a typical massive, legacy, regulated system.
The driving motivation for this article is to share my experiences, discuss the various challenges we faced and provide practical solutions that we took to overcome them. I feel that there is not enough long form analysis from teams using Elm and that is something I'd craved when deciding whether to take on Elm in a professional setting rather than just as a hobby.1 Therefore, this article is aimed at those similar to where I was, not sure whether to take the step or for teams who are using Elm and struggle with the various topics I cover here. To that effect, the code samples here are not for beginners of the language and my focus is not in explaining basic concepts.
Aside: Constructive feedback/discussions are very welcome. As I'm just learning this myself, please share any ideas or how your team may be doing somethings differently by hovering over a paragraph and commenting on it. Thanks.
Overview
So, at its heart, this a story. And a story, always has a beginning (Prologue).
The next chapter (Brave new w..holy cow) details my analysis of the existing codebase when I started.
From there, we go straight into strategies for Refactoring large codebases. Around that time, we started hitting brick walls re Compile times which (prodded by Noah) produced a talk at a Elm remote meetup2 with slides3.
With a much more structured foundation, I started developing patterns for Child to parent communication, our various types of Components matured, and I tackled generic Forms over and over, which I'm still unhappy with.
A core piece of our frontend is how it interacts with the backend through our Endpoints which consist solely of auto-generated decoders. Extensible types are powerful but also fun!
I talk about our File Structure, which grew organically. The major consideration here is compile time. And I throw together a bunch of random Tools which may be useful if you're making a SPA (useless if you're making a game).
Finally, I rant and rave about how much I love Elm and try my best to word it like it's an objective observation of the strengths and weaknesses of the language.
Thanks
To Julian Leviston who was my mentor in Elm and gave his time freely to review and critique this article.
He's also a mad keen Haskeller. Check out his wonderful Haskell book: http://www.happylearnhaskelltutorial.com/
Footnotes
1. Castle of the Winds remake in Elm - https://github.com/mordrax/cotwelm ↩
2. Elm Remote Meetup talk - https://youtu.be/ulrukPRYsws?t=50m4s ↩
3. Elm Remote Meetup slides - https://docs.google.com/presentation/d/10vN7eLr3qsd4nK2zcxUHgbu68fO_yzAA-b7Hf7kEcik/edit?usp=sharing ↩