Phoenix with Elm - part 11
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.
Phoenix with Elm - part 10
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.
Phoenix with Elm - part 9
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.
Phoenix with Elm - part 8
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.
Phoenix with Elm - part 7
Let's take a moment to talk about what is happening behind the scenes in our Elm application.
Phoenix with Elm - part 6
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.
Phoenix with Elm - part 5
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.
Phoenix with Elm - part 4
Adding a Model and enhancing the View.
Phoenix with Elm - part 3
Adding a simple View to the Elm application.
Phoenix with Elm - part 2
Getting Phoenix and Elm to play together.