• dillonkearns/elm-graphql
• Elm Radio episode 4 - JSON decoders
• Dillon's Elm Conf talk about the principles behind elm-graphql: Types Without Borders
• Phantom Types
• elm-graphql's FAQ document

• SelectionSet.nonNullOrFail
• SelectionSet.mapOrFail
• Custom Scalars don't include type information, though there are some proposals for supporting optional type information

• Juniper for Rust

• Hasura (database-schema based API)

• Postgraphile (database-schema based API)

• Discourse thread on differences between all the Elm graphql libraries

• harmboschloo/graphql-to-elm - library for generating Elm functions to make queries from GraphQL strings

• Dillon's Elm Europe talk Incremental Type Driven Development
• Test driven development
• Fake it till you make it
• elm-markdown GitHub-Flavored Markdown table live stream
• Succeed is the key to success
• Practical refactoring with Llewllyn Falco and Woody Zuill
• Llewllyn Falco doing Gilded Rose kata with TCR and snapshot testing
• Dillon's article on Relentless, Tiny Habits

• Evan Czaplicki's talk The Life of a File.

• Richard Feldman's Frontend Masters Elm courses

• Explore many different data modeling options

• Make Impossible States Impossible Elm Radio episode

• 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.

• Create modules around domain concepts
• Use ubiquitous language

• You can think of the update function as a delegator - get things to the right place rather than doing the work itself

• elm-review

• TCC (test && commit || revert)

• 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.

• Make Impossible States Impossible from Elm Conf 2016
• Make Data Structures from Elm Europe 2018
• Elm Radio Episode 2: Intro to Opaque Types

• Building up a "truth table" of possible states (see Evan's guide Types as Sets)
• Which rows are invalid?
• Create a new type with only the valid ones possible

• elm-css

• Tereza's line-charts package

• Tereza's elm Europe talk

• elm-graphql

• Gilded rose live stream

• Snapshot testing (also called Approval Tests)

• Jeremy Fairbank's Boolean Blindness talk

• elm-spa
• Richard Feldman's elm-spa-example GitHub repo
• Elm's Browser.application
• Url.Parser - URL parsing in Elm for routing single-page apps
• elm-shared-state pattern (formerly called elm-taco)
• Next.js and NuxtJS
• Routing and dynamic routing in elm-spa
• Scaling Elm Apps talk - Elm Europe keynote by Richard Feldman

• Offical elm-spa Guide

• #elm-spa-users channel on the official Elm slack

• elm-spa-realworld (Ryan's version of elm-spa-example using his elm-spa framework)

• Exploring elm-spa example - Richard's conference talk walking through codebase

• Richard's Frontend Masters courses focus heavily on his elm-spa-example repo

• Elm Radio Episode 7: Extending Elm

• Alexis King's article Parse, Don't Validate

the difference between validation and parsing lies almost entirely in how information is preserved

• Shotgun parsing (original academic paper)
• Mixing processing and validating data

Shotgun parsing is a programming antipattern whereby parsing and input-validating code is mixed with and spread across processing code—throwing a cloud of checks at the input, and hoping, without any systematic justification, that one or another would catch all the “bad” cases.

a parser is just a function that consumes less-structured input and produces more-structured output

• Conditionally return types
• Don't have to repeatedly check condition
• Look out for "lowest common denominator" built-in values being passed around (like empty String)
• Maybe.withDefault might indicate an opportunity to parse

Two ways to use this technique:

• Weaken return type

• Strengthen input type

• Design by contract

• Elm Radio JSON decoders episode

• elm-test NPM package
• elm-explorations/test Elm package
• elm-test init command
• Running elm-test finds exposed values of type Test

• Testing in Elm is easier because it's just expectations of input to output (deterministic)
• TDD is a design practice too
• Programming by Intention
• Writing test first makes code testable & decoupled
• Red, green, refactor
• YAGNI
• "Make the change easy, then make the easy change"
• Kent Beck's TDD by Example
• Here's a staring template of a code kata in Elm that you can use to practice
• Emily Bache has many more code katas you can practice on her GitHub

• Also known as Property-Based Testing

• Martin Janiczek's elm-minithesis project

• elm-test's view testing API includes Test.Html.Query, Test.Html.Selector, and Test.Html.Event

• Jeroen's Safe Unsafe Operations blog post
• Richard Feldman's talk on Types and Tests
• Make Impossible States

• Discourse thread discussing testing internals
• Think in terms of a modules responsibility

elm-program-test

• Richard test-update package

• elm-ui package
• Fewer overlapping ways to express views
• Element.padding (no concept of margin)

• There used to be a notion of a single type defining all possible styles

• Latest elm-ui simplifies that by using only inline styles. You build your own abstractions with vanilla Elm functions/modules etc.

• Element type is the equivalent of the Html type from elm/html

• elm-css package

• Mobster app

• Element.html works at leaf nodes, but elm-ui in general doesn’t mix with plain html

• Element.htmlAttribute

• Refactoring is a huge asset for a team, so much easier than css refactoring

• Doesn’t expose all the css tricks directly, sometimes you need escape hatches to access those

• Pass in window size from your Elm model
• Doesn’t use media queries, so that approach doesn't play well with with pre-rendered html like in elm-pages
• classifyDevice is an optional helper for responsiveness

• Express layout with Element.row, column, el
• Semantic HTML is independent from layout. Set with attributes using the Element.Region module.

• Element.paragraph uses text wrapping

• elm-ui doesn't expose access to rem and em units to simplify the mental model and reduce overlapping ways to express something

Lucas Payr's elm-ui-widgets

• Element.explain gives you highlights around nested elements
• Inspecting developer tools doesn't help much with elm-ui, but elm-ui is much more traceable because it doesn't have layout cascading like CSS

• Matt's elm-ui announcement talk at Elm Europe (was about elm-style-elements, but still worth a watch)
• Matt's more recent elm-ui conference talk
• Richard Feldman's talk CSS as Bytecode (uses style-elements, but it's a great intro tutorial on elm-ui concepts)
• #elm-ui channel in the Elm slack

• Init a builder data structure with a set of reasonable defaults
• Customize those defaults through a series of chained function calls
• Builders have the same type for the return type and final argument, so that they work nicely in a pipeline

• Luke Westby's http-builder package
• Brian Hicks' Robot Buttons from Mars talk
• elm-review package docs
• elm-pages/phantom builder live coding
• Richard Feldman's Oslo Elm Days keynote

• Platform.worker

• Html
• Http
• Ports
• Web Components

• elm-pages StaticHttp API

• Elm radio episode 1 on elm pages

• elm-graphql

• Codegen

• Macros

• Elixir exunit

• Wrapper elm apps

• Can emulate effect managers

• Platform.worker

• Introspection

• elm-typescript-interop

• Ports and flags

• Web Components

• Code transformation

• Elm asset loader webpack

• Hacking JS to get FFI

• Depending on internal details could end up with broken code

elm-hot and elm-hot-webpack-loader

Codegen

• Have a single clear source of truth for codegen
• Prevent bad states with airtight abstractions, rather than having lots of caveats
• Make sure public APIs for generated code look nice
• Use doc comments

Macros

• Elm code that doesn’t look like elm code
• Tooling doesn’t work then - see Babel ecosystem
• Violates Open close principle - you’re modifying the language, not extending it

Provide a platform with extensions in mind when you build tools so you don’t require users to hack

When you build a tool, think about the mental model for uses, let that guide you. Avoid leaky abstractions

Be opinionated about the core things, and unopionated about what’s not essential to the tool

• [elm-spa](https://github.com/ryannhg/elm-spa)