Blog

We took a look, in Part 9, at how to fetch our initial seat data via an HTTP request. However, one of the most compelling reasons to use Phoenix is because of it's first class support for Channels.

Upgrading to Elm 0.16.0. OK, so I know that I promised that I'd be looking at Phoenix Channels in this post, and don't worry, that post is coming soon. However a shiny new version of Elm was just released, and so we should upgrade for all of the goodness that it brings.

This part of the tutorial is actually going to be a bit of a detour. We're going to fetch the initial data for our Elm application over HTTP from a data API that we'll create in our Phoenix application.

Currently our application only allows us to model a given state and perform actions that result in changes to that state. We create an initial state for our application with the init function and thereafter are only able to change that state via the update function.

Let's take a moment to talk about what is happening behind the scenes in our Elm application.

We mentioned in part 3 that Elm has a Model - Update - View architecture. We've looked at the View and the Model, so let's turn our attention now to the Update. The best way to get a handle on what the update function will need to do is by taking a look at its type annotation.

So far Elm has been happily inferring the types that we are using in our application, and it will continue to do so. However let's take a moment to look at how we can make it more obvious to others who might read our code what types we are expecting.

Adding a Model and enhancing the View.

Adding a simple View to the Elm application.

Getting Phoenix and Elm to play together.