7ML7W Elm Day 2 The Elm Architecture
Introductions are shared and Paul takes us through the preamble with Leo offering guidance on the location of fire exits.
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.
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).
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.
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.
i.e.
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.
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.
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 Random.int 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.
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
In which innovation at Geckoboard is explored, with many 'ooh's and 'ah's and paper is heated to form rudimentary words.
