The Elm (0.18) Architecture: A Breif Overview

The elm architecture is explained in the Elm guide, but I’m going to try and break it down in a way in which I understand it so that hopefully anyone reading here can benefit from another perspective.

The guide tells us that an Elm application has the architectural pattern of Model-Update-View but, what does this mean? I see it like this:

Model

-> The data being manipulated in your (front end) application. I’ll expand on this as soon as I introduce “Update” and “View”.

Update

-> Your application will react to events (user clicks, timers, http request responses, etc.) and those events will trigger functions which are to be applied to the current Model, producing an updated Model. The function applied depends on the type of event triggered.

View

-> The view is a function which is applied onto the current Model data which will generate the HTML. When the Model is updated, the generated HTML will reflect the new Model data.

Now, back to the Model - Consider the following:

• The model is an explicitly declared type, consisting of other explicitly declared types of data.

• In the simplest program, the inital Model Data/State is hard-coded into an init function. This data is encapsulated into the application, and only modified by update events.

• Another important fact: (Pure) Elm functions are 100% aware of which types of data can be fed into them, as well as which type of data is outputted from the function.

These three points mean that the Elm compiler can determine exhaustively if there is ANY chance of having a runtime failure. Compilation fails if there is any chance that a function can receive an unexpected input, like javascript’s pesky null.

null values in Elm? NOPE, (Although Possible) It DOESN’T HAPPEN!!

null values don’t occur in an Elm program because of the special Maybe Type which I’ll discuss in greater detail in another post. We use a Maybe type if there is a chance of having “Nothing”. This way, we know it isn’t just an accident.

Takeaway/Reiterated Thoughts

• Our program logic comes in the form of functions which are triggered by outside events and applied to the current State/Model.

• When the State/Model updates, the new Application Markup (HTML) is generated from the View function being applied to the new State/Model.

• The compiler doesn’t allow run-time failures because it is able to confirm during compilation that only valid/typed Data can be inputted into functions, and that functions can only product the specified type.

In the simplest application, the State/Model/Data and Events being triggered don’t involve side-effects and thus manipulating the data and view is quite simple to do with user triggered updates.

In following posts, we’ll see how Side-effects can be achieved when interfacing with other javascript libraries via an elm port/subscription or when functions have a ’non-guaranteed’ task to perform (Like a Http Rest Call). Those tasks usually return a Result Type, which can be processed by the appropriate update functions.

For now, I’ll leave you with the above Introduction to the Elm Architecture. Next, we’ll look at the initial boilerplate code of a standard Elm Application.

EDIT: The above is valid for Elm 0.18, but I will soon create a post which will account for the breaking changes in 0.19

---

#Elm