Applications as Fractals

The Elm Architecture

I'm Luke

@luke_dot_js

@lukewestby

@luke

builtwithelm.co

lukewestby.com

elm-http-extra

elm-template

elm-verbal-expressions

Elm

@elmlang

@elm-lang

elmlang.herokuapp.com

elm-lang.org

Let's talk about application structures

├── app
│   ├── assets/
│   ├── models/
│   ├── controllers/
│   └── views/
└── config/

└── MyMvcApp
    ├── Controllers/
    ├── Models/
    ├── Views/

    ├── Scripts/
    └── Content/

└── backbone-app
    ├── models/
    ├── collections/
    ├── views/

    └── templates/

100s of models?

1000s of views/presenters?

Async updates?

Cascading updates?

app/
    app.module.js
    app.config.js
    components/
        user-profile.directive.js
        user-profile.directive.html
    layout/
        shell.html
        shell.controller.js
    people/
        people.routes.js
        speakers.html
        speakers.controller.js
        speaker-detail.html
        speaker-detail.controller.js
    services/
        data.service.js
        spinner.service.js

Here's the problem:

STATE. IS. EVERYWHERE.

The Elm Architecture

One top-level description of data-flow, composed from many features

App.Model

People.Model

Sidebar.Model

App.update

People.update

Sidebar.update

App.view

People.view

Sidebar.view

App.Actions

People.Actions

Sidebar.Actions

This allows us to

• Componentize our UI
• Identify functionality by role
• Identify functionality by feature

without

• Spreading state over many objects
• Compromising predictability
• Introducing complex abstractions over the language

Every module of an Elm UI is runnable as its own application

(example)