• 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

  1. (Organize) Grouping functions values types
  2. (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
  • Decoupling
  • 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.