Elm Europe 2018 - attending Richard Feldman’s workshop

When I booked for Elm Europe I gave myself a day to recover from the early morning flights - Cyprus to Belgrade, Belgrade to Paris. Then a day for sightseeing before the conference began...

Then, dammit, Richard Feldman offered a workshop on my sightseeing day! It wasn’t exactly cheap and it got me thinking about the value of workshops vs conference presentations. It must differ for different people. For a start, it would depend on how best you learn, as well as how much the cost eats into your income for the year.

It’s important as a web developer to hone in on how you learn. We are faced with continuous change. You may for example learn on the job, through tutorials, books, from colleagues, workshops or combinations.

Some may be able to sit through two days of presentations and learn a lot from them. Personally, I am easily put to sleep. I need to engage and workshops provide exactly that, as do tutorials.

It’s also about how important learning is for you at a conference. Is meeting people more important? Is hearing a diversity of ideas more valuable? I love to meet people and am also very aware that both friendships and work opportunities may come from such contacts.

However, as a remote worker I find learning is top priority. Without colleagues to learn off face-to-face in the office, you have to take the opportunity to pick up whatever you can. Workshops may provide the friendships and learning.

Half a dozen people attended this workshop, which was good for me, not so good I suspect for the presenter and organizers. I recommend fine tuning the price to increase numbers. The sweat spot was probably at a lower price with more people and up to a dozen would still be very manageable.

The content was targeted beyond beginner level. This is where a lot of people would now be looking and was perfect for me. The direction was informal and fluid according to attendees needs. In the morning it was more of a review of things I already new. Even that is valuable, as it reinforces.

The afternoon was full of things I didn’t know about and hence I came out of the workshop suspecting I had received long term value and may well have got my money’s worth. I’d like to see more workshops, altering the balance of what is regarded as the main event.

The rest of the Elm Europe was also good though. There were a number of presentations that educated and/or entertained. I’d rate Feldman’s presentation on the second day as the best as yet again it was practical applicable material.

So what did I learn about at the workshop?

Some notes:
Better to decode initial data coming through flags rather than let it be automatically turned into records - I guess this is about type safety.

Use intermediate representations rather than change your model to match incoming JSON records - you don’t want your code determined by something in JS or other land not designed necessarily for your situation.

Nested model updates are a sign that something is wrong - split it out and work with something smaller. Although it’s not nested vs flat, it’s situational for when there is something you can work with.

Move functions to the top level rather than in a let-in block - this is about being explicit about the dependencies. In a let-in block you have access to all the parameters of the enclosing function. The exception is when you are actually going to use most of those parameters.

Phantom types - adding a type definition you don’t use - can be useful for catching certain compile time errors - I’d need to review this again to recall what that looks like in practice.

Trick for unwrapping - avoid case statements for single option union types by using pattern match:
e.g.

display : Value a -> Style
display (Value str) = 
    makeStyle (“display: “ ++ str)

There was something about how when making a union of types the more open type results. This was a little above my understanding so I’ll just file it away until I come across it next. Lol.

When parameters appear at the end of both sides of a function definition you can remove them, but don’t, as it affects readability.

Ports - use one set of ports for everything;
e.g.

port sendToD3 : Value -> Cmd msg
port receiveFromD3 : (Value -> msg) -> Sub msg 

This is a concept that has gained traction but not with everyone. I had some side conversations about it and there is concern that it is less type safe for example.

Ports - who should own the state of a library? JS should. Elm doesn’t change it. If you want to change it, send a msg out to JS to change it, and it can send a message back to Elm to change it’s model. If choosing where to draw the line between JS and Elm, default to a minimum interface between them.

Then we got onto some meaty stuff around JS interop - getting beyond using ports:

One way is Custom Elements, which is very useful when wanting to manipulate stuff in the DOM - think View as the interface rather than Update. Basically a custom element can be produced by putting a ‘-’ in a node name: Html.node “rtfeldman-div” [] []
generates
Custom Elements need polyfills for non-Chrome browsers.
Another way is to use custom events on their own. Register the event in JS and pick up from Elm using ‘on’ under Html.Events.

Then there was a review of Html.Keyed and Html.Lazy. I hadn’t used these before so it was all good stuff. Keyed is uniquely identifying rows for for when you want to make adjustments without Elm redrawing significant portions of the DOM. React has something similiar. Lazy should apparently only be used when you experience a runtime performance issue. It prevents reevaluating view functions where the parameters and result have already been calculated.

Finally we had a look at parsing. This a pretty powerful tool for validation or other applications and worth knowing about.

Note that Feldman is preparing a new course for Front End Masters that will go beyond beginner level and incorporate some of the stuff we talked about at the workshop. I’ve no doubt I’ll take that as well.