- Wait until you feel the pain vs create abstractions before you need them
- Does the code quality metric of line count apply in Elm since there's no spooky action at a distance
- Aim for loose coupling, high cohesion
- Localized reasoning
Core mechanics of Elm modules
- (Organize) Grouping functions values types
- (Hide) You can hide some of those things. Allows encapsulation, shielding from breaking changes, avoiding coupling.
Giant update functions
- You can think of the update function as a delegator - get things to the right place rather than doing the work itself
What are you gaining from extracting a module?
- Protecting invariants
- Hiding internals
- TDD helps drive module design.
- Experiment, but review your experiments before they become deeply ingrained.
- Pain in code is for sending a message.
- Technical debt isn't about "clean code". It's abstractions that serve what the code is doing. Abstractions are inherently expensive and a type of tech debt if they don't serve a purpose for your specific needs.
- Be proactive - immediately as soon as there is a clear way to make code better (not perfect, small improvement) - do it
- Relentless, Tiny Habits
- elm-test Elm Radio episode
- Testing is helpful for identifying modules - see keystone testing habit blog post
- Property based testing is a sign that something is a module - it has a clear property, which means you want to protect the internals
- It's okay to get it wrong, just don't get it all wrong up front with premature abstractions.