Skip to content

7ML7W Elm Day 2 The Elm Architecture

Joel Chippindale edited this page May 15, 2018 · 8 revisions

Introductions are shared and Paul takes us through the preamble with Leo offering guidance on the location of fire exits.

What do we want to talk about?

Reminders are made of how distracting (in a bad way) the book had been in the previous meeting and that we had decided to follow the Elm Architecture section of the official guide to Elm which was roughly equivalent day 2.

We narrowly escape a new significant distraction as Paul shares his vim configuration (and accompanying computer) with Leo for the purposes of live coding and in doing so reveals minpac as the latest vim plugin manager for the discerning vimist (as recommended by Drew Neil).

Those who have worked through this section suggest that most of the key ideas around inputs are introduced in the first case and so we may skip some of these but broadly we want to work through the section.

Getting started

Leo: What's the difference between program and beginnerProgram

We looked at the docs and could see program has more parameters but were not left much more the wiser.


We covered the concept of a model which is the persistent state that is stored through the lifetime of an Elm app. Mark highlighted that the close of relation to Redux (where this would be a store). This is typically data rather than behaviour (in contrast to Rails' ActiveRecord).


We started with an aside about type signatures reminded ourselves that functions were all curried in Elm and so the type definition update : Msg -> Model -> Model, says that update takes a Msg parameter and returns a function which takes a Model parameter which then returns a Model.

Nicky: Is the type definition required?

Leo: It is implied but not required [we tried taking it out and everything worked fine]

Ali wondered why it was included at all if it wasn't required. Joel reflected that it was helpful for documenting your intent and enabled better error messages when you didn't match that intent.

The update function takes something which has happened (Msg), and the current state (Model) and returns the new state (Model).


The view function uses a DSL for generating HTML.

Ali: This is quite similar to react with it's nested lists of elements.

Paul: The author's talk about this giving you the full power of elm in templates.

Mark: I buy this, it was weird to start with but actually it’s nice to be able to just write code. The cost is that it takes you away from paradigm you are already familiar with.

This lead to another aside about type signatures because the view function has the signature Model -> Html Msg and Mark asked what this meant.

Leo: This says mean all the onClick calls in the view code return Msg.

We tried out replacing messages with strings and it changed the type signature. We tried replacing some with strings and it failed to compile (because they all have to return the same type).

Button exercise


We added a reset button to the counter example and found it a relatively satisfying loop of adding the button, and then seeing the errors that this generated and fixing these up by adding a Msg type, and adding a case to update.

Paul: The rest of the inputs are more of the same.

Text input exercise


We noted that the Model record gives you a constructor i.e. Model "foo" is the same as { content = "foo" }

Leo: Noted that when thew only one case (for update for example) you can match in the function signature.


update : Msg -> Model -> Model
update msg model =
  case msg of Change
    newContent -> { model | content = newContent }

Is the same as

update : Msg -> Model -> Model
update (Change newContent) model =
  { model | content = newContent }

Paul: They are probably using the case version in the example because this is a template to follow for more complex updates.

We also noted that unlike Haskell you could only have one definition of a function (and so you if you wanted to use multiple pattern matches then you needed the case syntax.

Discussion of why reverse in view or in model. We updated the code to showe it works both ways and so it just depends on use case.

Form example


The wew thing in this example was using the let in syntax to define local variables.

Paul side note Elm truly fast, for some benchmarks


Paul: Now we produce Cmds ‘do stuff’ and subscriptions allow you to listen.

Model is the same. Update changes to product Model and Cmd. Now init produces Model and a Cmd.

Elm has a time travel debugger, can replay all the state.

Random numbers


Leo: Random is hard in functional programming because ‘pure’ functions always return the same value for the same arguments.

Why can’t you just generate a random number?

We showed that 1 6 does not return an integer but a generator. We were not entirely clear what a generator was.

This seemed a more complex set up BUT it means that the function stays pure (referential transparency), and the ‘impure’ bit can happen within Elm (somewhere in the internals of Elm).

Nicky: Can you chain commands? Yes, we tried it out and it worked.

HTTP - Cats


We moved onto random gifs of cats and clicked on cats and more cats, ‘aawww’, ‘aaaaaaw', ‘cats yay!!!’, ‘damn right’, ‘awwwww’ to fade...

We walked through it and saw that it was very similar to the die face and changed it so that it would show computers.


"Much better than last time". "The book didn’t hold us up". "Useful to have code open and work as we go".

Then there was some talk of elm vs. javascript in terms of ergonomics. Ali compared with redux, and where it goes beyond these it has referential transparency and type system that you don’t get with redux/javascript. Leo, said that if you think about equivalent of actions creators, in redux you still have to use pure JS.

Nicky expressed concerns about how styles were included. Mark speculated about libraries for importing CSS file, not certain but think this is possible. Leo wondered whether it is better that it’s code, perhaps this makes CSS less necessary? Ali CSS in JS about preventing cascading aspect of CSS.

What next? Definitely want to cover subscriptions and interview from chapter 2.

Tuzz kindly offered to organise the next meeting

Postscript (whilst milling around about to leave)

In which innovation at Geckoboard is explored, with many 'ooh's and 'ah's and paper is heated to form rudimentary words.

Clone this wiki locally
You can’t perform that action at this time.