Real Life™ + UI programming = FRP (or why Elm is awesome)
A piece of software that requires and reacts to user interaction is akin to a car. I’m no car guy - but when I press on the accelerator, my car’s velocity increases. When I hit the brakes, the brakepad hit my tires and the car begins to slow down.
I imagine slamming the brakes in a car is direct, short trip for the electrical system. When brakes are in ‘slammed’ state, the brakepad are hitting the tires. This makes sense & there’s no mental hurdle to jump to understand it.
In simple terms of input: I as the user am inputting ‘brake’. I get a car that is slowing down. In other words - whenever the brakes are down, the car is slowing down. Whenever the steering wheel is turned to the left, the wheels are turned to the left. It’s tempting to say that my input determines the state of the car, but I don’t think that’s ambitious enough.
The input is the state of the car. They aren’t just related, they are equal.
What an elegant way of thinking about input - whether input be time elapsed, clicking a button, the dimensions of a window. The state of [whatever] can be described simply by its input.
Programmers hate real life user input.
Think back to your first ‘Hello world!’ that took user input from the cmdline… remember your
gets? Remember thinking, “what if they don’t input a number?”…“what if they have to redo it?”…“what if they want to undo it?”… such a headache.
So many things can go wrong - especially when there are multiple methods of giving input to a program (at the same time!?!?).
The browser basically handles this in the following way:
Is there an event? -> alert any listeners
This would be fine, but web applications, ultimately, deal with the DOM. They deal with the nice buttons and windows you see. The DOM is the state of your application. These windows and buttons need to change based on the things you click and the window you resize, for example.
Let’s examine these two examples.
The browser loops: a click occurred.
myClickListener() wakes up - it understands you clicked on a button and updates the DOM accordingly - a window disappears as a result.
The browser loops again: a window resizing occurred.
myWindowListener() understands the new dimensions of the window and changes elements’ sizes accordingly.
event and changes the DOM as the developer sees fit.
Describe the state
If you want to step backward to see some state in a time previous to now, you have to undo code execution on the DOM.
Not only does this single-minded event execution strategy make it difficult to handle multiple events, it makes examining and reasoning about the code/state pure torture.
What if we could create a system like the original car I talked about? A system in which the unique and important input systems are directly connected to the pieces of the state (car) that they manipulate.
A system where the code doesn’t handle input, it describes the state. In this perfect world, resizing a window doesn’t trigger an event that can change elements’ dimensions… the window’s dimensions are dynamically implanted in the code that describes the state of the application. When the window dimensions change, the state of the application is changed along with it.
Our shiny new model will simply describe that text field as corresponding to the number of mouse clicks sent into the system, and the two will always be in sync.
In this perfect world, our input truly and directly describes the state of our application. There is no middle ground - the streams of input have a direct line to the car. A turned steering wheel means turned wheels.
I don’t know what a perfect world is - but something like this does exist.
It’s called Elm.
What kinds of benefits does this give you?
- The code is easier to read and reason about
- Multiple streams of input can be handled simultaneously and elegantly
- Go back in time, because remember, input describes state - if you can revert to previous input, you revert back to previous state
Notes & Disclaimers
- If you’re wondering how this input is handled, I did not talk about streams here - this is a fantastic article by Andre Saltz.
- I don’t know shit about cars.
The next post will probably about streams ‘n stuff.