Code for a "hands-on" Elm talk

Request Feedback
1

I’m new to Elm and really enjoying it. Naturally this has led to me evangelising about it to anyone that will listen, and ultimately it’s ended up with me being roped into giving a talk on Elm at my local meetup! :sweat_smile:

I’ve come up with a plan which involves slowly building an app, introducing concepts as I go. I’ll give the audience non-compiling samples in Ellie, which they’ll need to complete to show that they’ve understood each concept.

I wanted to post the app so far in case anyone with more experience in Elm could spot areas where the code isn’t ideal:

https://ellie-app.com/pQdnG6SWNa1/0

In particular I don’t feel totally happy about the update function, as I’m having to cover off a case that in reality should be impossible. I’m not sure there’s any way around this though as there’s no way for the compiler to know that certain model types are restricted to certain message types.

update msg model =
    case msg of
        Select card ->
            case model of
                CardList cards _ ->
                    ( CardList cards (Just card), Cmd.none )

                -- this case should be impossible, because only the CardList view has Select buttons
                _ ->
                    ( model, Cmd.none )

        Loaded (Result.Ok cards) ->
            ( CardList cards Nothing, Cmd.none )

        Loaded (Result.Err err) ->
            case err of
                BadStatus { body } ->
                    ( Error body, Cmd.none )

                _ ->
                    ( Error "Unknown error", Cmd.none )

Thanks in advance for any help on this :blush:

2 Likes
2

This is awesome!

What if you put the “case model of” around the “case msg of”?

Then you wouldn’t need to handle that case for each message!

3

Ah it’s only really the Select case that needs to worry about different model cases, and that’s only because I need to keep the cards data after the update.

I did try tupling them and doing case (model, msg) of but it didn’t feel much better, and I thought it might be harder for them to understand.

1 Like
4

That’s a good point.

Maybe slightly tweaking the model will make it easier to explain to at the local meetup!

https://ellie-app.com/9qwqyJfgSa1/0

I forked your Ellie, and showed an example with a slightly different model.

Let me know if that helps!

1 Like
5

Thanks Ryan, that definitely makes the the update function read better! I’d need to tweak my slides in order to introduce the { record | field = val } syntax before this point but that’s maybe not a bad thing!

I guess I was obsessing too much about “make illegal states unrepresentable”, i.e. making it impossible to construct a model where the cards are still loading and there’s a card selected. I could make that part of the discussion though.

My audience will be mostly experienced OOP devs (C# devs who reluctantly write JS). My main goal for the talk is to show them that with Elm/FP it’s possible to build apps without null, this, exceptions or hidden side-effects - i.e. almost completely avoid runtime errors. I think that will be the thing that will sell it to them :blush:

2 Likes
6

I think you can still do that (and also avoid showing the record update syntax).

See here: https://ellie-app.com/qqqybYLBma1/1

2 Likes
7

Ah, beaut!

I was just watching Richard Feldman’s “Make impossible states impossible” video and thinking there must be a way, then came back and here it is!

I think I might make this a challenge on the day.

Thanks :blush:

1 Like
8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.