Say we wanted to create an Accordion component that lets us expand and collapse sections within the Accordion, such that only one section can be expanded at a time. This is a good candidate for a Compound Component. Let’s first create an Accordion with three sections, without trying to abstract out any logic.
Spoilers below. For those who haven’t read or watched the series by now, it’s your own fault.
Recently I’ve been working on a feature in my open-source pride and joy, Lazygit, that allows viewing your modified files as a tree rather than a flat list. This allows you to get a better feel for which areas of the codebase have been changed, and has some perks like easy navigation with folder collapsing, and the ability to stage/unstage whole directories.
What you are about to hear is a tale full of danger, excitement, and personal growth. You will come across the evil Dragon Of New Requirements, and the Serpent Of Typescript’s Lacking Type Inference. Polymorphism spells will be cast, Abstractions will rise and fall, and chests of various colours will explode. Although this tale requires no advanced knowledge, it will require courage and persistence, because it is a terrifying tale of twists and turns that, in real life, spanned weeks.
Over the last couple of days I’ve been working on LazyMigrate, a gem which provides a little UI for handling migrations in rails. Because it’s a gem that depends on your Rails app’s code, it can’t really be tested in isolation (unless I went and mocked out a heap of stuff which would erode my confidence that things were working correctly). I was vaguely aware that I could have made a Rails plugin, which sets you up with a mock rails app for testing, but I wanted to be able to run the gem from outside rails as well.
The second half of this blog post now lives in video form here
In The Pragmatic Programmer, Andrew Hunt and David Thomas introduced the DRY (Don’t Repeat Yourself) principle. The rationale being that if you see the same code copy+pasted 10 times you should probably factor that code into its own method/class.
As a software developer I like to think of myself as intelligent and discerning, but if I’m being completely honest with myself most of the decisions I make around code structure are governed by fairly low-resolution heuristics like ‘Don’t Repeat Yourself’ and ‘Keep It Simple, Stupid’. My stylistic intuitions all too often get priority over intuitions about long term maintenance and extensibility, in part because there are always arguments available that sound very serious and programmery but really just cover for the stylistic bias.