The workflow is you write in Hypatia, compile, make the compiled Lua require statements to the Roblox version, and Rojo, a Rust built development tool, will sync your Lua directly into Roblox. You can then call the exposed functions directly from other Lua (i.e. Buttons, events, etc). I’m thinking of automating that require change with Python… or maybe Lua.

Compiling Hypatia required a couple of smart Haskell devs at work to help me compile. Cabal didn’t work but Stack worked no problem on my Mac M1. Hypatia might compile JavaScript too, not sure.

Anyway, still need to figure out side effects (still learning what the heck a f -> Unit is), and how to deal with coroutines and various other side effects since Hypatia doesn’t handle them like Elm does, but super excited to continue exploring this.

If you code Batch in Go for example, the main method has it right there in the return value: void. Meaning… there is no return value.

How, then, do you use something like a noop in your mostly Functional Programming style Step Function that assumes you’re composing infrastructure like you’d compose functions? Basically tap. If you’re not familiar, tap is a quick way to debug pure function chains.

If you’ve ever heard of the identity function, it basically gives you back what you give it, like this in Python:

def identity(oh_yeah):
  return oh_yeah

Or this in JavaScript:

const identity = ohYeah =>
  ohYeah

That seems like a ridiculous function, no doubt. But watch what happens when you combine it with composed functions, say, parsing some JSON.

def parse(str):
  return json_parse(str) \
  >> parse_people \
  >> filter_humans \
  >> format_names

Parse composes 4 functions together. If they’re pure, how do you “see” inside that pipeline? You “tap” into it. We can take our identity function, and convert to a tap function like this:

def tap(oh_yeah):
  print("oh_yeah:", oh_yeah)
  return oh_yeah

Then we can “tap into” the pipeline.

def parse(str):
  return json_parse(str) \
  >> tap \
  >> parse_people \
  >> tap \
  >> filter_humans \
  >> tap \
  >> format_names

Sick, ya? Now the normal way to do that in Step Functions is via a Pass state:

"Tap": {
  "Type": "Pass",
  "Next": "NextStep"
}

You can then see the output in the Step Function console, or tweak the inputs/outputs if you wish.

… but that’s for Lambdas, Step Functions, SQS, and SNS steps that not only return a result like a pure function, but do so using your JSON. In JavaScript, that’s pretty easy to merge properties:

const addYoSelf = json =>
  ({ …json, name: "Jesse was here" })

Batch, and even Step Functions, don’t always work like this. You typically have to define Parameters manually depending upon the input… meaning you lose your JSON tree.

… UNLESS it’s just 1 branch. You can create siblings that are collected in a single spot using the Parallel task.

If you think Promise.all like in JavaScript or gather in Python, multiple results, but a single, Array filled result. This allows you to keep context at least in 1 spot using a Pass, and you don’t care about the rest.

a = stuff
identity = stuff => stuff
addSelf = stuff => ({… stuff, name: 'Jesse'})
destroy = stuff => undefined
end = a => Promise.all([identity(a), addSelf(a), destroy(a)])

Notice how end will result in an Array like:
[stuff, stuff + name Jesse, undefined]

Undefined is often what we get with noops that return no value. BUT, we need the first part to continue our Step Function with “context”. Using a Parallel + Pass, you can keep that context.

Until Batch gets the .waitForTaskToken feature (I mean… ECS has it…), you can wrap her in a Parallel to keep context. Just watch those catches….

tl;dr; JSON use Parallel and in next state go:

"OutputPath": "$[0]"

BTW, I know you can use ResultPath and just attach to your existing JSON, but AWS Batch is HUGE, and we’re already getting super close to our JSON size limit with our immense Array size I refuse to read from S3. You could just export and then rip off from a Pass state, but you’ll get a size exception before that happens sadly. Twice now I’ve got an exception when it completes the Batch because the JSON is too large, and using this technique has worked every time.

And Step Function JSON for above (supply your own Lambda):

{
  "Comment": "A Hello World example of the Amazon States Language using Pass states",
  "StartAt": "Both",
  "States": {
    "Both": {
      "Type": "Parallel",
      "Next": "Keep JSON",
      "Branches": [
        {
          "StartAt": "Good Function Returns Value",
          "States": {
            "Good Function Returns Value": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:us-east-1:0000000:function:jesse-identity",
              "Parameters": {
                "uno": "yup"
              },
              "ResultPath": "$.datLambdaResult",
              "End": true
            }
          }
        },
        {
          "StartAt": "Bad Noop",
          "States": {
            "Bad Noop": {
              "Type": "Pass",
              "Result": "World",
              "End": true
            }
          }
        }
      ]
    },
    "Keep JSON": {
      "Type": "Pass",
      "OutputPath": "$[0]",
      "End": true
    }
  }
}

• ensure functions always work by learning Pure Functions
• avoid runtime errors by return Maybes
• avoid runtime errors in deeply nested data using Lenses
• avoid runtime errors by return Results
• creating pure programs from pure functions by Pipeline Programming

Why Care?

Writing code that doesn’t break is much like ensuring your teeth remain healthy. Both have proven ways to prevent problems, yet people still act irresponsibly, either by eating bad foods and not brushing, or in programming being lured by “getting things working quickly with what they know”.

For example, to prevent cavities in your teeth, you should avoid food high in sugar, drink public water supplies with fluoride, and brush your teeth twice a day. At least in the USA, many still have teeth problems. The access problem for dental hygiene can be an economic one. For others, they just aren’t responsible and don’t keep up on teeth health.

For programming, I can help with the access problem. This article will provide proven ways to equip you with the knowledge to help yourself.

For the responsibility, however, I empathize it’s harder. I’ll teach you the techniques, but you have to practice them. Brushing your teeth everyday, you can master it quite quickly. Utilizing functional programming techniques in a non-functional programming language takes a lot more practice and hard work.

Your teeth thank you for brushing often. Your code will thank you by consistently working.

What Does “Never Break” Mean Exactly?

The “Never Break” means the function will always work, will always return a value, won’t ever raise an Exception, nor will it ever exit the Python process unless you want it to. It doesn’t matter what order you call these functions or program in, how many times you call it, they are always predictable, and can be depended on.

What Does “Mostly Work” Mean Exactly?

Just because your functions work all the time doesn’t mean your software works. Pass the wrong environment variable for a Docker container, a downstream API is down, or perhaps you just did the math wrong. You still need unit, fuzz, feature tests, formal methods if you’re able, and good ole manual testing to verify your software works. Not having to worry about your software exploding randomly allows you to focus 100% on those.

Also, no amount of FP will save you from badly formatted code. You’ll still need things like PyLint to ensure you wrote print("Sup") instead of print("Sup)

If this is so obvious, when do I _not_ do this?

In order of priority:

1. When you’re exploring ideas.
2. When you’re committing code amongst those who aren’t trained in FP.
3. When you’re on a deadline.
4. When you’re modifying legacy code with no unit tests.

The allure and draw of Python is it is a dynamic language. While not as forgiving as JavaScript, Lua, or Ruby, it still allows a lot of freedom to play with ideas, various data types, and provide a variety of ways to run your code efficiently on various infrastructure architectures. With types only enforced (mostly) at runtime, you can try various ideas, quickly run them, correct mistakes you find after running them, and repeat this until you’ve locked down an implementation. While you _can_ use FP concepts for this, if you’re still learning, they can slow you down. Other times, this is a fun time to learn.

Commiting FP code to a Github repo where others aren’t familiar with FP, or have no clue why you’re coding things that don’t seem PEP Compliant can really cause problems. Typically a team adopts their own rules, patterns, and styles… and they don’t always have reasonable reasons. It’s best to learn why they code the way they do things, and adopt those standards. If you’re in a position to teach the team, great, but FP is quite alien, already has a reputation for being obtuse with horrible evangelists. Tread slowly here. Breaking trust in the team is one way to ensure your software never works correctly. Bad working relationships result in horrible software.

If you’re on a deadline, learning anything new can slow you down and risk not hitting it. Alternatively, it’s also the guaranteed way to ensure you learn something quickly, heh.

FP or not, you shouldn’t add or modify code in a large codebase you’re responsible for if it doesn’t have unit tests. Otherwise, you have no good idea if you’ve broken something, sometimes for days or weeks. Add tests first, THEN refactor things.

Functions That Always Work: Writing Pure Functions

Pure functions always work. They reason they always work is that they always return values. They don’t raise Exceptions. They’re technically not supposed to have side effects. They’re desired because they always return the same value, so are close to math in that you can depend on their result, or “answer”. Unit testing them also doesn’t require mocks, only stubs.

The 2 official rules go like this:

1. same input, same output
2. no side effects

Returning None is ok. The first function most Python devs are introduced too, print doesn’t appear to return value, much like console.log in JavaScript. However, it does: None:

result = print("Sup")
print(result == None) # True

Typically a function that returns no value, or None in Python’s case, is considered a “no operation” function, or “noop” for short (pronounced no-op). Noop’s are usually a sign the function has side effects. Noops are not pure functions. We know that print does produce side effects; the whole point of calling it is to produce the side effect of writing to standard out so we can see what the heck our code is doing.

For classes, however, it’s more subtle and now that you know the rules, you’ll see what’s wrong. Here’s how you stop verifying SSL certs for rest calls using a class to wrap urllib:

import request.rest
import ssl

req = request.rest()
req.disable_ssl()
res = req.get("https://some.server.com")

Note the disable_ssl() class method. It takes no parameters, and returns no value. Why? Probably because like most classes, it’s changing a setting internally in the class instance to turn off SSL stuff so the next person who does a REST call won’t have to have certs validated.

You do the complete opposite in functional programming. Although, in this case, it’s probably ok to call disable_ssl() multiple times without any harm. Things like get are more tricky.

So, impure function:

ssl = enabled

def get(url):
  return requests.get(url, ssl_enabled=ssl)

And a pure function:

def get(ssl, url):
  return requests.get(url, ssl_enabled=ssl)

And one that’s even more pure, and unit testable:

def get(requests, ssl, url):
  return requests.get(url, ssl_enabled=ssl)

And the most pure function you can possibly write in Python in a reasonable way:

def get(requests, ssl, url):
  try:
    result = requests.get(url, ssl_enabled=ssl)
    return result
  except Exception as e:
    return e

Write functions like that, and you’re well on your way to understanding how Golang is written.

Avoiding None by using Maybes

Python doesn’t offer a lot of guarantee’s, that’s why risk takers like it. If you’re writing software, you might not want risk. There are 3 main places this comes from when calling functions:

1. getting data from Dictionaries (cause you’re using them now, not Classes, right?)
2. getting data from Lists
3. getting data from outside of Python

Safer Dictionaries: Maybe Tuple

Let’s talk about dictionaries.

Dictionaries can work:

person = { firstName: "Jesse" }
print(person["firstName"]) # Jesse

Dictionaries can also fail:

print(person["lastName"])
# KeyError: 'lastName'

Wat do!?

You need to change how you think Python in 2 ways. First, how you access objects safely, such as using key in dictionary or lenses. Second, how you return values from functions, such as using the Golang syntax by returning multiple values which lets you know if the function worked or not, or a Maybe/Result type.

You can safely access dictionaries by creating a getter function:

def get_last_name(object):
  if "lastName" in object:
    return (True, object["lastName"], None)
  return (False, None, f"lastName does not exist in {object}")

This function is pure, and safe and will work with any data without blowing up. It also uses a nice trick Python has when you return a Tuple (read only List) from a function; you can destructure it to get 3 variables out in a terse syntax, making it feel like it is returning multiple values. We’ve chosen something similar to the Golang syntax where they return value, error, we’re returning didItWork, value, error. You can use the Golang syntax if you wish, I just don’t like writing if error != None.

ok, lastName, error = get_last_name(person)
if ok == False:
  return (False, None, f"Failed to get lastName from {person}")

So this is your first Maybe at a raw level. It’s a Tuple that contains if the function had your data or not, the data if it did, and if not why. Note if ok is False, your program is probably done at this point.

Developers are encouraged to create Exceptions for everything that isn’t necessarily exceptional, and raise them so others can catch them or different types of them and react accordingly, usually higher up the function chain. The problem with this is you can’t easily read your code and see errors as they could be coming from completely different files. Using maybes in this way, it’s very clear what function failed, and your don’t have to wrap things in try/catch “just in case”.

Safer Dictionaries: Maybe Type

Tuples are ok, but are verbose. A shorter option is the Maybe type. We’ll use PyMonad’s version because they did a lot of hard work for us. First import it:

from pymonad.Maybe import *

Then, we’ll create our getLastName function to return a Maybe type instead of a Tuple like we did before:

def get_last_name(object):
  if "lastName" in object:
    return Just(object["lastName"])
  return Nothing

I say the word “type”, but in Python, it feels like a function. Replace (True, data, None) with Just(data) and (False, None, Exception('reason')) with Nothing. You can then use it:

lastNameMaybe = get_last_name(person)

You first instinct will be “cool, if it’s a Just, how do I get my data out?”. Well, you don’t.

“Wat!?”

Trust me, we’ll cover this in Pipeline Programming below, for now, just know this function will never fail, and you’ll always get a Maybe back, ensuring your code doesn’t throw errors, and is more predictable and testable.

Speaking of which, here’s Pytest:

def test_get_last_name_happy():
  result = get_last_name({'lastName': 'cow'})
  assert result == Just('cow')

“Wat…”

Ok, till you get more comfortable, try this:

def test_get_last_name_happy():
  result = get_last_name({'lastName': 'cow'})
  assert result.value == 'cow'

Safer Lists: Maybe Type

The same thing can be said for Listsin Python.

people = [{'firstName': 'Jesse'}]
first = people[0]

Cool.

people = []
first = people[0]
# IndexError: list index out of range

Uncool. There are many ways to do this; here’s the quickfix you’ll end up repeating a lot:

def get_first_person(list):
  try:
    result = list[0]
    return Ok(result)
  except Exception:
    return Nothing

You’ll see this implemented in a more re-usable way as nth, except instead of returning None, it’ll return a Maybe:

def nth(list, index);
  try:
    result = list[index]
    return OK(result)
  except Exception:
    return Nothing

Pure Deeply Nested Data Using Lenses

You know how to make unbreakable functions by making them pure. You know how to access Dictionaries and Lists safely using Maybes.

In real-world applications, you usually get larger data structures that are nested. How does that work? Here’s some example data, 2 people with address info:

people = [
  { 'firstName': 'Jesse', 'address': { skreet: '007 Cow Lane' } },
  { 'firstName': 'Bruce', 'address': { skreet: 'Klaatu Barada Dr' } }
]

Let’s get the 2nd person’s address safely using a Maybe:

def get_second_street(list):
  second_person_maybe = nth(list, 1)
  if isinstance(second_person_maybe, Just):
    address_maybe = get_address( second_person_maybe.value)
    if isinstance(address_maybe, Just):
      street_maybe = get_street(address_maybe.value)
      return street_maybe
  return Nothing

Yeahh…… no. Gross. Many have taken the time to do this with a better, easier to use API. PyDash has a get method:

from pydash import get

def get_second_street(list):
  return get(list, '[1].address.skreet')

Cool, eh? Works for Dictionaries, Lists, and both merged together.

Except… one small issue. If it doesn’t find anything, it returns a None. None will cause runtime Exceptions. You can provide a default as the 3rd parameter. We’ll wrap it with a Maybe; less good looking, but MOAR STRONG AND PURE.

def get_second_street(list):
  result = get(list, '[1].address.skreet')
  if result is None:
    return Nothing
  return Just(result)

Returning Errors Instead of Raising Exceptions

Dictionaries and Arrays not having data is ok, but sometimes things really do break or don’t work… what do we do without Exceptions? We return a Result. You have 2 options on how you do this. You can use the Tuplewe showed you above, doing it Golang style:

def ping():
  try:
    result = requests.get('https://google.com')
    if result.status_code == 200:
      return (True, "pong", None)
    return (False, None, Exception(f"Ping failed, status code: {result.status_code}")
  except Exception as e:
    return (False, None, e)

However, there are advantages to use a true type which we’ll show later in Pipeline Programming. PyMonad has a common one called an Either, but Left and Right make no sense, so I made my own called Result based on JavaScript Folktale’s Result because “Ok” and “Error” are words people understand, and associate with functions working or breaking. Left and Right are like… driving… or your arms… or dabbing… or gaming… or anything other than programming.

def ping():
  try:
    result = requests.get('https://google.com')
    if result.status_code == 200:
      return Ok("pong")
    return Error(Exception(f"Ping failed, status code: {result.status_code}"))
  except Exception as e:
    return Error(e)

You don’t have to put Exceptions in Error; you can just put a String. I like Exception’s because they have helpful methods, info, stack trace info, etc.

Pipeline Programming: Building Unbreakable Programs

You know how to build Pure Functions that don’t break. You can safely get data that has no guarantee it’ll be there using Maybes and Lenses. You can call functions that do side effects like HTTP requests, reading files, or parsing user input strings safely by returning Results. You have all the core tools of Functional Programming.. how do you build Functional Software?

By composing functions together. There are a variety of ways to do this purely. Pure functions don’t break. You build larger functions that are pure that use those pure functions. You keep doing this until your software emerges.

Wait… What do you mean by “Composing”?

If you’re from an Object Oriented Background, you may think of Composing as the opposite of Inheritance; uses class instances inside of another class. That’s not what we mean here.

Let’s parse some JSON! The goal is to format the names of humans from a big ole List of Dictionaries. In doing this you’ll learn how to compose functions. Although these aren’t pure, the concept is the same.

Behold, our JSON string:

peopleString = """[
	{
		"firstName": "jesse",
		"lastName": "warden",
		"type": "Human"
	},
	{
		"firstName": "albus",
		"lastName": "dumbledog",
		"type": "Dog"
	},
	{
		"firstName": "brandy",
		"lastName": "fortune",
		"type": "Human"
	}
]"""

First we must parse the JSON:

def parse_people(json_string):
  return json.loads(json_string)

Next up, we need to filter only the Humans in the List, no Dogs.

def filter_human(animal):
  return animal['type'] == 'Human'

And since we have a List, we’ll use that predicate in the filter function from PyDash:

def filter_humans(animals):
  return filter_(animals, filter_human)

Next up, we have to extract the names:

def format_name(person):
  return f'{person['firstName']} {person['lastName']}'

And then do that on all items in the List; we’ll use map from PyDash for that:

def format_names(people):
  return map_(people, format_name)

Lastly, we need to upper case all the names, so we’ll map yet again and start_case from PyDash:

def uppercase_names(people):
  return map_(people, start_case)

Great, a bunch of functions, how do you use ’em together?

Nesting

Nesting is the most common.

def parse_people_names(str):
  return uppercase_names(
    format_names(
      filter_humans(
        parse_people(str)
      )
    )
  )

Oy… that’s why you often hear “birds nest” being the negative connotation to describe code.

Flow

While PyDash and Lodash call it flow, this is the more common way to build larger functions out of smaller ones via composing them, and gives you your first insight into “pipeline” style programming.

parse_people = flow(parse_people, filter_humans, format_names, uppercase_names)

Pipeline: PyMonad Version

Now Flow is quite nice, but hopefully you saw some problems. Specifically, none of those functions are super pure. Yes, same input, same output and no side effects… but what happens when one of them returns a Nothing? When happens if you’re doing dangerous stuff and one returns a Result that contains an Error instead of an Ok?

Well, each of those types are tailor made to pipe together. You saw how the functions I made for flow worked together; they just needed 3 rules:

1. be a mostly pure function
2. have a single input
3. return an output

The Maybe and Result can wired together too, but they have a few extra special features. The only 4 we care about for this article are:

1. if a Maybe gets a Just, it’s smart enough to get the Just(thing).value and pass it to the next function. The Result is the same unwrapping the value in the Ok and and passing it to the next function.
2. Each expects you to return the same type back. If you chain Maybe‘s together like you do in flow, then it’s expected you return your Just(thing) or Nothing.
3. Both handle bad things. If a chain of Maybe‘s suddenly gets a Nothing, the entire thing will give you a Nothing. If any of the functions you’ve wired together get a Result and suddenly one gets an Error in the chain, the entire chain gets an Error.
4. They have flow built in; but instead of calling it, you use weird, new, non-Python symbols to confuse you, look impressive, and make the code feel less verbose despite increased brain activity.

That’s a lot, ignore it. Just look at the example:

def parse_people_names(str):
  return parse_people(str) \
  >> filter_humans \
  >> format_names \
  >> uppercase_names

Goodbye!

If that’s a bit alien and strange, that’s because:

• you’re doing Functional Programming in a Object Oriented + Imperative language; you rock!
• >> isn’t Pythonic nor PEP Compliant®
• Most Python devs see a \ and think “Aw man, this code is too long…”
• “… wait, you’re putting functions there, but not calling them, nor giving them parameters, what in the…”

This is why many Functional Programmers are nice even if they are not-so-great evangelists. Many non-FP destined people see that kind of code, freakout and leave. This makes many FP’ers lonely, thus they are more than happy to be cordial and polite when people talk to them in the programming community.

Manual Pipeline

Remember that nasty example of getting deeply nested properties before you learned Lenses? Let’s replace that with a pipeline using a Maybe; it’ll give you a better sense of how these things are wired together, like flow is above.

def get_second_street(list):
  second_person_maybe = nth(list, 1)
  if isinstance(second_person_maybe, Just):
    address_maybe = get_address( second_person_maybe.value)
    if isinstance(address_maybe, Just):
      street_maybe = get_street(address_maybe.value)
      return street_maybe
  return Nothing

Gross. Ok, let’s start from the top, first we need lastName (btw, I’m glad you ignored the ‘Goodbye’ and are still here, YOU GOT WHAT IT TAKES, OH YEAH):

def get_second_person(object):
  return nth(object, 1)

Cool, next up, get the address:

def get_address(object):
  if 'address' in object:
    return Just(object['address'])
  return Nothing

Finally, get dat skreet skreet!

def get_street(object):
  if 'skreet' in object:
    return Just(object['skreet']
  return Nothing

Now let’s compose ’em together.

def get_second_street(object):
  second_person_maybe = get_second_person(object)
  if isinstance(second_person_maybe, Nothing):
    return Nothing

  address_maybe = get_address(second_person_maybe.value)
  if isinstance(address_maybe, Nothing):
    return Nothing

  street_maybe = get_street(address_maybe)
  if isinstance(street_maybe, Nothing)
    return Nothing

  return street_maybe

Essh… ok, let’s test her out:

second_street_maybe = get_second_street(people)

Note a couple things. Each time you call a function, you then inspect if the return value is a Nothing. If it is, you immediately just return that and stop running everything else. Otherwise, you call the next one in the chain and unwrap the value. Here we’re doing that manually via maybe.value. Also, the return street_maybe at the end is a bit redundant; no need to check for Nothing there, just return it, but I wanted you to see the repeating pattern 3 times.

That pattern is what the >> does for you: checks for Nothing and aborts early, else unwraps the value and gives to the function in the chain. Rewriting it using that bind operator:

def get_second_street(object):
  return get_second_person(object) \
  >> second_person_maybe \
  >> get_address \
  >> get_street

It’s easy to forget the \. This is because Python is super strict on whitespace and only occasionally lets you do line breaks with code.

If you don’t want to use that, just put her all on 1 line:

def get_second_street(object):
  return get_second_person(object) >> second_person_maybe >> get_address >> get_street

Manual Result Pipeline

Let’s do some dangerous shit. We’re going to load our encryption key from AWS, then fetch our OAuth token, then load in a list of Loan products from an API that requires that token to work, and finally snag off just the ID’s.

Dangerous stuff? Potential Exceptions? A job for Result.

Get dat key:

def get_kms_secret():
  try:
    result = client.generate_data_key(
      KeyId='dev/cow/example'
    )
    key = base64.b64decode(result['Plaintext']).decode('ascii')
    return Ok(key)
  except Exception as e:
    return Error(e)

Don’t worry if you don’t know what the heck KMS is, it’s just Amazon’s encryption stuff, and gives you keys that you’re only allowed to get. If you’re not, that function will fail. It just gives us a temporary private encryption key as text. We’ll use that to get our OAuth token.

Next up, get our OAuth token via the requests library:

def get_oauth_token(key):
  try:
    response = requests.post(oauth_url, json={'key': key})
    if response['status_code'] == 200:
      try:
        token_data = response.json()
        return Ok(token_data['oauth_token'])
      except Exception as parse_error:
        return Error(parse_error)
    return Error(Exception(response.text))
  except Exception as e:
    return Error(e)

You have a style choice here. If you look above, there are 4 potential failures: status code not being a 200, failing to parse the JSON, failing to find the oauth token in the JSON you parsed, or a networking error. You can just “handle it all in the same function” like I did above. The point of mashing it together is “Did I get a token or not?”. However, if you don’t like the nested ifs and trys then you can split that into 4 functions, each taking a Result as well to wire them together in order.

Now that we have our token, let’s call the last API to get a list of Loan products. We’ll get a list potentially, but all we want is the id’s, so we’ll map to pluck those off:

def get_loan_ids(token):
  try:
    auth_header = {'authentication': f'Bearer {token}'}
    response = requests.get(loan_url, headers=auth_header)
    if response.status_code == 200:
      try:
        loans = response.json()
        ids = map_(loans, lambda loan: get(loan, 'id', '???'))
        return Ok(ids)
      except Exception as e:
        return Error(e)
    return Error(Exception(response.text))
  exception Exception as overall_error:
    return Error(overall_error)

If everything goes well, you’ll get a list of strings. Otherwise, and Error. Let’s wire all 3 up:

def get_loan_ids():
  return get_kms_secret() \
  >> get_oauth_token \
  >> get_loan_ids

When you go:

loan_ids_result = get_load_ids()

Either it works, and that loan_ids_result is an Ok, or it failed somewhere in there and it’s an Error containing the Exception or error text.

… now, one cheat I did, and you’re welcome to mix and match Maybes and Results together. You see when we attempt to get the loan id?

get(loan, 'id', '???')

That 3rd parameter is a default value if the property isn’t there or is None. The _right_ thing to do is use a Maybe instead. You can be pragmatic like this if you wish, just be aware, these are the types of things you’ll see where “the code has no errors but doesn’t work” . Also, I tend to like Errors more than Nothing in these scenarios because they give you an opportunity to provide an Exception or text with a lot of context as to WHY. Why is huge for a programmer, especially when you’re close to the error and know why it probably failed in a large set of functions that could all possibly break.

Conclusions

Functions are fine, but Exceptions can cause a lot of indirection. Meaning, you think you know the 3 ways a function, or even a program can fail, but then another unexpected Exception comes from some other deeply nested function. Completely removing these, and locking down the ones you know, or don’t know, will blow up using try/catch via pure functions removes that problem for you. You now know for a fact what paths your functions take. This is the power of pure functions.

However, that doesn’t protect you from using null (i.e. None) data. You’ll get all kinds of runtime Exceptions in functions that were expecting good data. If you force all of your functions to handle that eventuality via Maybes, then you never get null pointers. This includes using Lenses to access deeply nested data.

Once you go outside of your program via side effects such as making REST calls, reading files, or parsing data, things can go wrong. Errors are fine, and good, and educational. Having a function return a Result instead of raising an Exception is how you ensure the function is pure. You can also abort early if there is a problem vs having cascading effects with other functions not having their data in a state they need. You also, much like Golang and Rust, have the opportunity to document what the error is where it happens with helpful context vs. guessing at a long stack trace.

Finally, once you’ve written pure functions, you can build larger pure functions that compose those together. This is how you build pure software via pipeline programming (also called railroad programming, a style of streaming, etc).

Python provides the PyDash library to give you the basics of pure functions with working with data and lists. PyMonad provides the basics in creating Maybe and Either (what I call Result). If you’re interested, there is the Coconut programming language that integrates and compiles to Python, allowing you to write in a more Functional Programming style. Here’s a taste re-writing our example above:

def get_loan_ids():
  return get_kms_secret()
  |> get_oauth_token
  |> get_loans
  |> map( .id )

Don’t fret if all of this seems overwhelming. Functional Programming is a completely different way of thinking, Python is not a functional language, and these are all super advanced concepts I just covered the basics of. Just practice the pure functions and writing tests for them. Once you get the basics of that, you’ll start to get a feel, like a Spidey Sense, of when something is impure and has side effects. With Maybes, you’ll love them at first, then realize once you start using them responsibly, how much extra work you have to do to avoid null pointers. Eithers/Results can be challenging to debug at first as you won’t be wading through stacktraces, and you learn what error messages are best to write, and how to capture various failures. Stick with it, it’s ok if you use only a little; the little you use will still help your code be more solid.

It’s a bit easier to learn Elm if you compare it to things you know. If you know React and Redux, then comparing them can help a lot to understand Elm concepts. I’ve built the same application in React Redux Thunk and Elm so we can compare them together. The end result is a table of things you can paginate through. Comparing these 2 applications is apples to apples. They’re identical to the end user. Yet the technologies behind them are apples to oranges. Seeing those deviations using familiar tech in the same application can help your understanding.

Below, I’ve linked to both applications code bases which you can download and run locally if you wish.

Company Dashboard Code – React Redux Thunk

Company Dashboard Code – Elm

What is React, Redux, Thunk, and Elm?

React is a JavaScript library that allows you to ensure your HTML and CSS are in sync with your data. You use this to build single page web applications.

Redux is a library that allows you have a single variable for your data model. This ensures your applications are predictable and testable. It is the core of the Elm architecture and is often used in React.

Thunk is a library that allows your Redux actions to be asynchronous.

Elm is a functional programming language, compiler, repl, package manager, and a set of libraries to build single page applications. You write in Elm and it compiles to JavaScript.

Building and Compiling React

You build React applications using Node.js. Using a package manager like Yarn or npm to install libraries, and run commands to test and build your application for production. Yarn and Node utilize npm, the Node Package Manager, to install libraries and interface with Node. Yarn is used mainly because it has advanced features that npm doesn’t have, and it can yield more deterministic installs and builds compared to npm. Front-end applications tend to have more libraries than back-end Node API ones. Yarn is used more often in React given it’s front-end. The source of truth is usually a package.json, a JSON file that contains all the libraries to be installed and commands needed to test and build the application. This holds true whether the application is regular JavaScript, using advanced ES6 features, using advanced compilation tools like Babel and Webpack, and/or utilizing typed languages like as Flow and TypeScript.

The easiest way to build them at the time of this writing is using create-react-app, which abstracts most of the compilation and build toolchain away into simple commands with updates being usually as simple as updating the react-scripts library.

Like Elm, React can compile to simple components embedded in other web applications. It can also compile too large, single page applications.

Building and Compiling Elm

For simple applications, Elm the language is compiled to JavaScript and HTML through the Elm compiler via elm make. For more advanced applications, the compiler will output just JavaScript that you embed in your HTML. Libraries are installed through elm install and written in elm.json. While there is a local web server called elm reactor, it lacks many basic features such as auto-refresh that many other JavaScript tools have. Use elm-live instead.

Like React, you’ll use Node, npm, and/or yarn to various degrees of complexity. Like React, Elm can compile to simple components embedded into other web applications. Elm can also be used to build large, single page applications. The common ways to build at the time of this writing is create-elm-app which isn’t very friendly behind corporate proxies, and the simpler elm-live. If you’re not on a corporate network, create-elm-app is also an option.

Although Elm is fully featured, it’s still missing features native to JavaScript. As such you’ll sometimes interface with JavaScript. At the time of this writing for Elm version 0.19.0, this includes binary file upload, and application storage to name just two. This ensures you can benefit from Elm’s features, but not have to wait on them or the open source community to build Elm versions of those features.

HTML in React

HTML in React is rendered by React via JSX. They handle all the efficient ways of updating it, the cross-browser challenges, etc. All you do is provide a function or class with a render function that returns this JSX.

const Message = () => (<div>Sup</div>)

Then you can use this “component” like a normal HTML tag in your other React JSX:

<Message />

React became popular with functional programmers because it was basically a pure function for the DOM. A pure function is a function that always outputs the same thing if you give it the same arguments with no side effects. You give the Message component above an Object, and React will render the same DOM each time. This input in React is called “props” or properties.

const Message = props => (<div>Sup {props.name}</div>

Whenever that props.name value changes, so too will the HTML React renders. You can embed JavaScript or just values like the above using the squiggle braces ({}). There are a variety of rules that make JSX not exactly like HTML. There are a host of them, but examples include event objects are a custom copy to prevent certain bugs, and using onClick instead of onclick for events. That said, React has done a great job to make it feel and work like you’d expect HTML to work.

HTML in Elm

Everything in Elm is a function. HTML is no different. Each HTML element has a corresponding function name. All HTML elements typically have attributes and contents. Below, the div tag has a style attribute and text contents:

<div style="color: red;">Sup</div>

In Elm, you’d import and use the div, style, and text functions to accomplish the same thing:

div [ style "color" "red"] [ text "Sup" ]

Elm functions do not use commas, and parenthesis are optional in most cases. Above the div function takes 2 list arguments, the style function 2 string arguments, and text 1 string. Rewritten in JavaScript that’d be:

div([style('color', 'red')], [text('Sup')])

Working With CSS in React

Cascading Style Sheets have a lot of different ways of working in React depending on what you’re building, and the team’s style. Component based styles have risen in popularity in React. The first reason for this is it’s easier for modern tools to “only compile what you use”; if you don’t use the component, it won’t compile the CSS in. Larger websites that have accrued many shared styles from many teams over years have this issue. Since the tools aren’t very good to ensure modifying styles doesn’t break something else unintentionally, teams end up adding new styles of their own to prevent breakage which just adds to the file size and speed slow down despite not being inline. The second reason for this is co-location. The styles that handle the component are right next to it; you don’t have to hunt around various css, sass, or externalized html template files to “piece together” how a component is supposed to look.

React supports normal className attributes to emulate how the class attribute works. You can also use style create CSS through JavaScript Objects. This is popularized by the “CSS-in-JS” movement, and keeps your styles co-located to the components they are affecting. There are libraries that take this concept to the nth degree such as Emotion. Teams will either standardize on one approach depending on team make up, and/or use a multitude depending upon what they’re building and interfacing with. Beyond the className and style attributes for JSX, React’s version of HTML, React doesn’t prescribe how you handle CSS.

Styling with className:
<div className="textColor">Sup</div>

Styling with style:

const myStyles = {
color: 'red'
}
<div style={myStyles}>Sup</div>

Working with CSS in Elm

Elm, like React, doesn’t prescribe a way how you handle CSS. Elm’s version of HTML is functions. There is a function for each html element. If you’re adding styles to a div [] [], then you’d go div [ style "color" "red"] []. If you want to use a css class, you’d go div [ class "textColor" ] [].

The only modification is if you wish to have stronger compiler help with your CSS, you can use the elm-css library. The normal Elm style function doesn’t give you much help from the compiler given both arguments are strings. The elm-css library on the other hand ensures both types and argument order which really makes the most of the Elm compiler.

Coding in React

In React, you typically write in JavaScript. It’s a dynamic, interpreted language that is native in all browsers. Dynamic means you can change a variable that is a number to string or any type you want. Interpreted means you can write some code, put in the browser, and it’ll run. You do not need to compile yourself. The browser handles converting that to machine code that it can run quickly. You can debug the code, in the browser, using both logs and breakpoints which stop the code from running and allow you to step through each part line by line.

This also means that most styles of programming are supported. This includes Imperative, Object Oriented, and Functional. Imperative being many lines of code in a file that run from top to bottom in a procedural way. Object Oriented mean classes that encapsulate state, message passing, and a variety of design patterns. Functional meaning pure functions.

React allows both CSS and HTML to be written in JavaScript. This means that everything that makes up the visual elements on the screen can be put right next to each other, giving you a clearer picture of how each visual thing works. Sometimes.

The pros of a dynamic language are speed of development. You can quickly play with new ideas using only a little code. You don’t need any tools to make it work beyond a web browser. If you need a server, you can write the same language, JavaScript, to make Node do this for you.

Prop Types

The cons of a dynamic language is you have to run it to know if it works. While running can be fast, sometimes you have to click through the UI to trigger some part of the code, and that process isn’t that fast, or is tediously manual. Many tools can automate these kind of checks. For UI development in the browser, this is often verifying the components attributes (their inputs) and their events (change handlers).

<CrayButton label={datText} onGo={clickHandler} />

However, you won’t know if datText is actually a String, nor if clickHandler is a Function with proper scoping and no negative down stream effects till you actually test it. To help a bit with these problems, React has propTypes which has a bit of runtime type checking. You still have to run the code, and it only works in development mode, BUT it quickly aborts the code with correct errors vs. errors which may not be clear what went wrong.

CrayButton.propTypes = {
  label: PropTypes.string,
  onGo: PropTypes.func
}

Flow or TypeScript

Computers are much better than humans at finding, storing, and quickly accessing large amounts of numbers. For code, there are many different paths that could happen, and compilers are good at quickly verifying if your code is going to work or not in milliseconds to microseconds. One of the ways they do this is through types. You write in a different language entirely, then the compiler will convert it to JavaScript. Like the propTypes above, except the code won’t actually compile if it finds errors. Once you fix all the errors, it’ll then compile. The theory is in the little time it takes you to add types to the code, the compiler can find errors in microseconds to minutes. These milliseconds/minutes are supposed to be much shorter than the time it takes you to track down bugs.

Flow and TypeScript both offer really nice types with the ability to integrate with existing JavaScript and libraries. If a library was coding in JavaScript, many will offer TypeScript definitions which give the public API functions it exposes types. This allows TypeScript to offer type checking on it even though the library is JavaScript and has no types. For large codebases that already exist, including libraries, it’s much easier to create a definition file.

The create-react-app generator offers a TypeScript option, again abstracting away all the work to setup and maintain the compiler. The TypeScript/Flow flexibility, however, means that you have less guarantees that when your code actually compiles, it’ll work. Flow and TypeScript both compile to JavaScript, and have no runtime type checking.

Coding in Elm

In Elm, you write in the Elm language. It is functional and strongly typed. Functional means pure functions with no side effects. In fact, you cannot create side effects at all in Elm. The Elm framework handles all side effects for you. Everything from creating HTML to REST calls are simply pure functions. The types use Haskell style Hindly-Milner types. You put the function’s input(s) and output up top, and that’s all the compiler needs. This as opposed to TypeScript and ReasonML for example, where you put next to the variables at the end of the function. The function below is a simple add function, taking in 2 numbers, and returning whatever they are added together.

add : Int -> Int -> Int
add first second = first + second

That said, the compiler is pretty smart, so you can omit them and it’ll “know what you meant”.

add first second = first + second

In JavaScript, that’d be:

add = (first, second) => first + second

… sort of. Since all Elm functions are curried by default, a more accurate JavaScript representation would be:

add = first => second => first + second

Unlike Flow or TypeScript, Elm ensures when it compiles, you will not get any null pointer exceptions. There are only 2 ways to break this guarantee. The first is integrating with JavaScript through ports and you aren’t careful, or you are, but the JavaScript is just obnoxious. The second way is in development mode sending large amounts of text into the Debug.log function, using all of the browser’s memory.

As a functional language, there are no exceptions. This means all Error‘s are return values. More on error handling below.

In React, it’s not uncommon to see functions, classes, strings, numbers, modules, and images all in the same code base. In Elm, everything is a function or a type.

Side Effects in JavaScript

In JavaScript, you have control over some side effects. You can even create them yourself. This includes logging to the console, creating HTTP requests, reading from various storage locations such as files, listening for push requests on web sockets, various events from user interactions such as mouse clicks, and when the browser URL changes.

The ways these work varies from return values, callbacks, event handlers, to Promises. Some of these have built-in error handling and some do not.

To parse JSON from an outside source, it does a return value. If it fails, it’ll throw an exception you catch via try/catch.
result = JSON.parse('{"sup": "yo" }')

To listen to mouse events in React, it’s common to use inline callbacks:

<button onClick={() => console.log("Clicked, sucka!")}>Sup</button>

However, you can do it the event based way as well. We use a class method below so it can be cleaned up later.

theButton.addEventListener("click", this.clickHandler)

Many newer API’s offer Promises, and Promises have built-in try/catch. Here’s how to make an HTTP GET request using fetch which returns a Promise:

fetch(someURL)
.then(result => result.json())
.then(json => console.log("json is:", json))
.catch(console.log)

When unit testing, you’ll typically either mock the concretes using something like Sinon or Test Double to make the code more predictable. If you’re using functional style, you’ll pass in the module/class as one of the function parameters, and then a stub in your unit tests.

Side Effects in Elm

All side effects in Elm, with the exception of Debug.log in development, and JavaScript ports, are handled by Elm itself. You cannot create side effects in Elm. You merely create functions that return data. The Elm Architecture handles the actual side effects, allowing all of your code to be pure. We’ll talk more about how you get actual things done in the Elm Architecture section below. For now, just know that you can make the Elm Architecture create and handle side effects via one of the 3:

1. Messages (think onClick + Redux Action Creator)
2. Commands (think Redux Action Creator)
3. Subscriptions (think Thunks or Sagas triggered from window.onlocationchange or web sockets)

Closures in React

Closures are a way for functions inside of functions retain scope and values. It’s mainly used for OOP developers to have hack around this changing.

function someMethod(input) {
  const me = this;
  $('.thing').click(() => me.otherMethod())
}

It also allows JavaScript developers to have more predictable state, especially with asynchronous code:

let state = 'ready'
const loadData = url => {
  state = 'loading'
  fetch(url)
  .then(() => {
    state = 'done'
  })
  .catch(() => {
    state = 'error'
  })

They also can play an important role of reducing how many parameters your functions need as the inner functions can just access the outer/wrapping function values. They play pivotal role in how curried functions work in JavaScript. For asynchronous code such as nested callbacks and Promises, they can significantly help in reducing the code size, and keeping track of asynchronous processes in 1 place.

For React, they’re the primary way you utilize Hooks.

Closures in Elm

Closures in Elm work differently. While you can nest functions, and have inner functions access outer function parameters:

-- note we're referencing model.label inside the button function
view model =
  div [] [
    button model.label
  ]

…they do not propagate “later”. Since there is no async in Elm, you cannot “keep things around” long after a function has finished executing like you’d normally do in JavaScript with the exception of partial applications.

For example, if you’re doing many of the same HTTP calls on the client, they could come back in different orders. Often you’ll give each a different id so you can tell which call was which, and in what order it was sent. This allows you to do different versions of queues and concurrency. If you’re refreshing a table over and over, you may make 5 calls one after the other, but you really only care about the last one. In a chat for example, you actually care about FIFO, first in first out. You want to ensure you’ve handled all the calls in order to the best of your ability, and want to ensure the chat messages show in order assuming you’re lacking a timestamp to order them.

That control of state in JavaScript allows you to add a unique identifier using closures. Here is how you create a correlation ID in some JavaScript fetch code:

const load = () => {
  const correlationID = uuidv4()
  return fetch(url, {headers: {'x-correlation-id': correlationID })
  .then(result => result.json())
  .then(json => ([ json, correlationID ]) )
}

In Elm, you could reference the correlationID above in the request, but NOT in the response like you can in JavaScript. Since the actual side effect is handled by the framework, you’d have to user their built in trackers. The Elm API > v0.19.0 at the time of this writing is still figuring out how to handling concurrency for a variety of things.

Errors in React

Like Dart and Angular before it, React really has done some interesting things with Error handling. The first was error boundaries. Anyone who’s built UI’s knows that handling errors when drawing things is rough. Doing it in an async way is even harder since it’s hard to track where and when it may have occurred. Building errors into the components was a great first step in ensuring a single error didn’t bring down a whole application. Using throw in Fiber, their architecture that builds their own call stack, they can create Algebraic Effects. This means errors can be resumed safely from anywhere.

That said, errors in React are basically errors in JavaScript. They have tons of problems.

First, they aren’t pure. Pure functions have no side effects. Errors, even in the browser, cause side effects. They can put code currently, or later, into an unknown state. This could be from synchronous UI code, asynchronous WebWorkers, or some 3rd party library you’re not even sure is involved. If your web application has monitoring such as Catchpoint, you can get a text message at 3am because of an uncaught null pointer. Thus, they’re hard to predict and make your code flaky.

Second, JavaScript doesn’t really have good error handling facilities. They make it really easy to hurt yourself, the code, and the browser (or Node.js). Some languages languages such as Java have throwable. If a function has that, the compiler forces you to catch it. JavaScript has no such facilities, and is interpreted so you don’t know about errors until you run the code, see them, and get screwed over by them. Adding try/catch everywhere is not fun to write, nor read, and slows your code down. The asynchronous ones are a bit better in that catch on Promises only has to be written once, but with the popularity of async await syntax, people forego even writing those. They let explosions happen there uncaught as well. The window.onerror is a strange method with various browser support intricacies that can sometimes affect how bad the crash is based on what you return. This is still great to have it, but it has the same thing in common with try catch and the catch on a Promise: you can screw those up, and cause another error with no language/compiler support.

Third, the stack traces aren’t always accurate to what’s going on. They’ve greatly improved over the years since I abandoned Flash Player for JavaScript. Still, errors don’t always originate from the exact line of code that caused the error, or do but say something inaccurate to what’s actually causing the problem.

Errors in Elm

Elm doesn’t throw errors, that’s one of the draws of using it. Instead, if a function can fail, you return a Result. The compiler will ensure you’re handling it correctly. There are a few types that you can chain together like Promises such as Maybe and Result. If they fail, you handle the error in 1 place. These errors are return values and do not negatively affect the rest of your program.

If you’re in debug mode and send too much text, you can use all of the browser’s available memory and crash the program that way. Elm will not compile for production builds unless logs are removed.

If you’re using 3rd party JavaScript libraries on the page, or using ports with volatile JavaScript, they will also crash your program.

Redux in React

Redux is a framework inspired by Elm to help bring predictability to larger React applications. At some point when you outgrow Context, or just want the predictability that Functional Programming can bring, you reach for Redux. It ensures only 1 variable is in your entire application, and that 1 variable is all the data your application needs. You can use the Redux Dev tools to see your data change over time and clearly see the state changes, the order, and how they affect your UI. Since React components are pure functions that take in props and render DOM, Redux scales this concept for for the data.

Below is a crash course in Redux. You are welcome to skip it. I include it here for those who do not know Redux very well, nor why you even use it. Knowing how Redux works helps you understand how Elm works since they’re based on the same ideas.

Reducers

In Redux you have store; this is the main variable that stores your data. You get it via store.getState() and change it via store.dispatch({action}). The dispatch will call you reducers, or a function that takes in the state and the action. If you know the Array.reduce function, it’s the same thing. It’s assumed that your reducers do not mutate data, and simply return a copy of the store with whatever changes you need. Updating a person’s name for example would go like this:

const firstNameReducer = (person, action) => ({ ...person, firstName: action.firstName })

If I pass in firstNameReducer( { firstName: 'cow' }, { type: 'updateFirstName', firstName: 'Albus' } ), then it’ll return a brand new Object { firstName: 'Albus' }. This is important because it means the code returns immutable data, doesn’t mutate anything, and is easily testable. Thus, predictable. When you start building an application full of those reducer functions, your application becomes more predictable.

If you’re from an OOP background, you’re probably wondering why in the heck you can’t just go UserModel.getInstance().firstName = 'Albus' or even UserController.getInstance().setFirstName('Albus'). Or even just modifying on the variable in general. Remember, Redux uses pure functions. Pure functions do not mutate or “change” data. If you use immutable data, this ensures you’re following pure function rules. If you mutate things, then it’s not predictable who changes things, and where. If you use pure functions in Redux, the only mutation occurs in the store. You can predict which actions, in order, change your data and can visualize it using browser tools or simple logs. Yes, you can set a breakpoint in Java or JavaScript, and follow all the getter/setters for one code path, but not all. This is where you get “who’s changing my data, where, and when”. Redux has the same challenges, but it’s super clear “who” is doing it, and “how”. Since each change is immutable, there is no weird references going on.

Store

If data is immutable, then how do you change it? VERY carefully. Redux does this via reducer functions.

We know how to write pure functions that return immutable data, but nothing in the real world is immutable. Someone, somewhere has to hold the data we get back from the server, the changes the user makes on the UI, etc. That 1 var is the Store.

const store = createStore(firstNameReducer, { firstName: '???', lastName: 'Warden' })

This store holds your data. Notice we’ve put our reducer function for it as the 1st parameter.

You get it out via getState:

const person = store.getState() // { firstName: '???', lastName: 'Warden' }

To change the data, we call the dispatch method and pass in an Object:

store.dispatch({ type: 'updateFirstName', firstName: 'Jesse' })

Now when we get our data out, it’ll be changed:

const updated = store.getState() // { firstName: 'Jesse', lastName: 'Warden' }

Action Creator

The Object you pass as the 1st and only parameter to dispatch is called the “Action”. However, purist Functional people get mad creating random Objects, so they create a pure function. Those are suddenly called “Action Creators”:

firstNameAction = firstName => ({ type: 'updateFirstName', firstName })

An Action Creator is a function that return an Object. It’s assumed that Object, at a minimum, has a type property. You’ll use that type in your reducer function to know what data you want to change.

Many Types

As your application grows, you’ll probably need to change many aspects of your data model. For our person, we want to change the last name as well. So we create another reducer for changing the last name, but using a pure function. This means a copy of the data is returned vs. mutating it:

const lastNameReducer = (person, action) => ({ ...person, lastName: action.lastName })

To trigger it, we need another action creator for updating lastName:

lastNameAction = lastName => ({ type: 'updateLastName', lastName })

When we created our store above, we put the firstNameReducer with our store to handle all dispatches. Now we need both reducers, and each needs to run based on the type of Action Creator. Let’s create a new one that uses a switch statement.

const personReducer = (person, action) => {
  switch(action.type) {
    case 'updateFirstName':
      return firstNameReducer(person, action)
    case 'updateLastName':
      return lastNameReducer(person, action)
  }
}

In a unit test, if we call personReducer with {}, { type: 'updateFirstName', firstName: 'Joe' } then we’ll get back { firstName: 'Joe' }. If we call it with {}, { type: 'updateLastName', lastName: 'Hall' }, then we’ll get back { lastName: 'Hall' }.

To call it in your application, or even in a unit test, you’d go store.dispatch(lastNameAction('Warden')) to update the lastName to “Warden”.

As that switch statement grows, there are other ways to scale it, and improve it overall. That’s the gist of Redux.

Why Are We Using This?

When building applications in React, you need some sort of state and need it placed somewhere. For some applications, most of it can reside in the URL in the form of GET variables. For others, it’s simply a global variable. For others, if you load a list from the server, you’ll store that in a components props or even state for class components, or a closure for Hooks. Some keep it in sessions.

Eventually, though, some applications need 2 things that the above doesn’t provide: the ability to share the same data between multiple components, and the ability to update that data from any place you need. Sometimes an OOP Mediator design pattern, higher order components, or even just component composition works. You do this to avoid passing props down many component levels, or the components themselves via higher order components. You have a parent component who’s sole job is to handle communication between a bunch of children components.

As things grow, rather than utilize a Model View Controller style architecture, React provided Context. They describe it as a “tree”, from the idea that a component made of many components forms a tree, much like html within html forms a tree of nodes. When many in the tree, or even sibling components need to share the same data, and communicate up and down, performance aside, Context is the go to.

If, however, you want something deterministic without any state that can be mutated or “changed”, you use Redux. While people will often use Redux for the same reasons they use Context, the whole point is to ensure predictable code. If you only have 1 variable, you can ensure that the rest of your code is pure functions. If the rest of your code is pure functions, they’re predictable and easier to test. That means the bugs are typically type related, race conditions, CSS, or null pointers in your component code or 3rd party libraries. If your component code is intentionally dumb, small, and using Hooks in function components over classes, then you’re significantly reducing the places bugs can hide.

In short, all your code uses const and pure functions as much as possible, and all the hard work is in Redux reducers with as little code as possible in your React components and Hooks. Redux hides from you the only var (or let, heh) in the entire application. Now your application has only 1 variable which is your Model. All data is there, easy to find, and as your application grows, your Model just gets more branches on the Object. Given how JavaScript works, creating immutable versions of just pieces of tree means components see only the part they care about, and in turn the reducers only change the part they care about.

Redux Thunk

The above code is all synchronous. JavaScript applications are often asynchronous. The web browser is asynchronous because the code that renders the screen is also the code that loads image.

Redux’ default store doesn’t have the ability to deal with Promises or any type of callback async style. The redux-thunk library was created to make that as simple as possible.

An example would be modelling ajax calls. For example, the UI below shows the 3 possible states: loading, error, success:

Putting that in a Redux Store would look something like:

{
  loadingState: {
    loading: true,
    isError: false,
    error: undefined,
    data: undefined
  }
}

Or using Algebraic Data Types:

{
  loadingState: LoadingFoods()
}

You dispatch an Action Creator before the AJAX call to put it in a loading state, when it fails you dispatch an error Action Creator, or when it succeeds, you dispatch a success Action Creator. Using a Promise, it looks like this:

dispatch(loadingFoods())
fetch('/foods')
.then(result => result.json())
.then(foods => dispatch(foodsLoaded(foods))
.catch(error => dispatch(foodsFailed(error))

Connecting Redux to React

Now that you have Redux and Thunks for async calls, you now wire up to React, usually using the connect library. A pattern emerges where you’ll have “dumb” components who take data, render it, or are just simple UI elements like <buttons>, etc. You then have “connected” components that know about Redux. Their sole job is to provide an interface for a React component to get its data from the current state, and when the component has events, those trigger Action Creators. This requires 2 functions called mapStateToProps and mapDispatchToProps and put you those 2 in the connect call with your Component, and it smooshes them together into a “ConnectedComponent”. If you have a Cow component, and connect it to Redux, it’ll be a ConnectedCow.

An example React component that would show 3 screens needs 1 piece of data to know what screen to show, and 1 click handler when the user clicks “reload”.

<Screen loading={true} reloadClicked={reloadClicked} />

To get data, you create a function called mapStateToProps. The longer version is “Yo, I’ll give you the current Redux state in the store; you can either use it as is, even if it’s a gigantic Object, or you can snag off the pieces you want. Whatever you return to me, I’ll set as the props to your component for you. Also, don’t worry, I’ll get called every time the data you care about changes.” Since the whole point of using React is to keep your DOM in sync with your data, this is a perfect match.

Given our example Object above of modelling the loading state, it’d be:

const mapStateToProps = state => state.loadingState

Second, we need a mapDispatchToProps. This function takes any events that come out of our React component, and makes it fire the dispatch action creator we want. If we want to click a <button> in the component and have it go dispatch(reloadActionCreator()), then we need to give our component a function to do that. The mapDispatchToProps wants you to return an Object that it’ll put on the component’s props for you, and it gives you the Redux dispatch function so you can use it in a sync or async way. We’ve got just 1 event in our React component that looks like this:

const Screen = props => (
  <div>
    <div>Loading: {props.loading}</div>
    <button onClick={props.reloadClicked}>Reload</div>
  </div>
)

So we’ll create that reload function for it like so:

const mapDispatchToProps = dispatch =>
    ({
        reloadClicked: () => dispatch(reloadActionCreator())
    })

Last part is to smoosh them together via connect:

const ConnectedScreen = connect(
  mapStateToProps,
  mapDispatchToProps
)(Screen)

Elm Architecture

Below is a crash course in the Elm Architecture. It can be a LOT to take in, even if you’ve had extensive Redux experience. Don’t fret, and read the Elm Guide multiple times, it’ll click.

Elm comes built-in with the Elm Architecture. There is no way to NOT use the Elm architecture, unless you’re playing around with Elm code in the elm repl. If you’re familiar with Redux, then you’ll understand the Elm architecture.

Similar to Redux, you have a model that is your data. In Redux, it’s some Object that grows over time. In Elm, it’s a Record that grows over time. The difference is Elm has types to ensure the Model’s values are changed correctly.

type alias Model =
  { firstName : String
  , lastName : String }

initialModel =
  { firstName = "???"
  , lastName = "Warden" }

Think of type alias as a JavaScript class. You can instantiate new type alias things. To change the Model, you send Messages. They’re just types too. They’re like Redux Actions. Instead of { type: 'UpdateFirstName' }, it’s UpdateFirstName. You don’t need Action Creators like you do in JavaScript since the compiler will ensure you create them correctly.

type Msg
  = UpdateFirstName String
  | UpdateLastName String

You handle those Messages in the update function just like you handle Actions in Redux reducer functions. Elm will not compile unless you handle all of them. In JavaScript you can intentionally ignore Actions you don’t understand by using default at the bottom of the switch statement. You can also forget as your application grows and you miss one and have no compiler to yell at you. The code below ignores an action with the type “updateLastName”.

const personReducer = (person, action) => {
  switch(action.type) {
    case 'updateFirstName':
      return firstNameReducer(person, action)
    default:
      return person
  }
}

Not so in Elm. This only handles UpdateFirstName. Elm won’t compile until you implement it correctly.

update message model =
  case message of
    UpdateFirstName firstName ->
      { model | firstName = firstName }

Check out this beastly compiler error:

Missing Patterns
Line 26, Column 5
This `case` does not have branches for all possibilities:

26|>    case msg of
27|>        UpdateFirstName firstName ->
28|>          { model | firstName = firstName }

Missing possibilities include:

    UpdateLastName _

I would have to crash if I saw one of those. Add branches for them!

Hint: If you want to write the code for each branch later, use `Debug.todo` as a
placeholder. Read <https://elm-lang.org/0.19.0/missing-patterns> for more
guidance on this workflow.

Fixing our code to handle both Messages by now including the UpdateLastName:

update message model =
  case message of
    UpdateFirstName firstName ->
      { model | firstName = firstName }
    UpdateLastName lastname ->
      { model | lastName = lastName }

The view function gets the Model as the first parameter. There’s no need to setup components to be aware of it like in React via the connect function for Redux. They are just functions and can take the Model as a parameter, or parts of it. It’s up to you. In Redux, you’d use mapStateToProps. The connect library will then spread all the data you need on your React component props. In Elm, you just get the whole model. You’re welcome to snip off the pieces you want, though.

view model =
  div [] [ text "First Name: " ++ model.firstName ]

When you’re ready to make HTTP calls, your update function is returned to send back 2 values instead of just the model. In Redux, you get the model and action, but only have to return the model. Below is the Redux reducer for the loading state:

const loadingState = (state, action) => {
  switch(action.type) {
    case 'loading':
      return {...state, loading: true}
    case 'error':
    case 'success':
      return {...state, loading: false}
  }
}

You’ll then have code elsewhere that dispatches the Action, then makes the fetch call, then dispatches either an Error or Success Action.

In Elm, you can’t make HTTP calls on your own since those are side effects. Instead, you use a Command. You don’t typically create Commands on your own. Rather, things that cause side effects like HTTP calls create them for you, you just return them in your update function so Elm knows what to do.

update model =
  LoadData ->
    ( { model | state = "loading" }
      , Http.get
      { url = "/companies"
      , expect = Http.expectString CompaniesHTTPResult
      }
    )
  ...

That Http.get returns a Command. Elm internally will make the call for you. Whenever the HTTP result is successful or fails, your update will be called again some time later with your CompaniesHTTPResult message. Think of the error and success in the JavaScript Redux reducer above as one CompaniesHTTPResult below. The result parameter lets you know if it worked or not.

update model =
  CompaniesHTTPResult result ->
    -- it's either Ok or Err

This concept of just having functions either return data or Commands seems weird at first. In JavaScript you’re used to “making it do”. Things like “make this GET request and wait for it”, or “Read this data from Application Cache”. In Elm, you can do those things, but it’s all through returning Commands in the update function. Elm will handle the nitty gritty of making the actual XHR call, or reading from the browser’s storage. You’ll typically have a Message to “kick it off”. This means there is no need for a Thunk. No need for a mapping function of events to dispatches. Your UI will trigger messages, and inside the update function, you can then return Commands to do side effect things.

Bugs in React

Bugs in React are usually because of JavaScript. The language is fast to develop in and run with no compile step. This speed comes at the cost of having little to no correctness guarantees when you run. Maybe it’ll work, maybe it won’t. That is a adrenaline rush for some people, myself included.

However, some errors aren’t even reported. They’re “swallowed”. Meaning, your application doesn’t work like you expect, but you don’t get an exception. No stack trace, no error, no red in the console, no error breakpoint triggered… just “what… the….”. These are the worst because at least Exceptions give you a possible hint and path to follow. At least returned Errors from more functional code can also give a hint and a path.

Below, I’ve listed some common ones not always caught by ESLint plugins via misspellings, lack of types, null pointers, missing case statements, and logic errors.

Swallowed Errors via Misspellings

In JavaScript, you can name Object properties just about anything you want. The problem is when it’s accidental and onClick becomes onClck. JavaScript doesn’t know you meant onClick, and if you pass React event handlers undefined, they’ll assume you want nothing to happen. One mispelling, 2 miscommunications. Worse? It’s silent; you won’t get any runtime exception. You click a button and nothing happens.

ESLint plugins can only help so much. Some code can only be known to work together if it’s run, and some variables aren’t known to each other unless you had types and a compiler.

In Elm, every single variable’s spelling must match a known type, or it won’t compile. With the exception of magic strings, this completely solves swallowed errors via misspellings.

Null Pointers Because of the Lack of Types

You can use Algebraic Data Types in JavaScript. This allows you to return a Result from an operation that could fail, either success or failure. It’s called an Either in some Functional languages, but in JavaScript, the default one is a Promise. However, Promises don’t come with the popular matching syntax where as something like Result from Folktale or true-myth do.

Downside? You have to memorize the variable names, specifically how you destructure. Without types, you can get subtle bugs that can inadvertently get swallowed. In Redux, since all of the code is synchronous, it’s easier and more fun to use Result as opposed to Promise because the code is synchronous, can be chained like Promise, and has matching syntax. In our reducer below, if the ajax call to load the accounts works, great, we parse it and return a success. If not, we return a failure. The UI can match on this to know what to draw.

export const accounts = (state=AccountsNotLoaded(), action) => {
      ...
      case 'fetchAccountsResult':
          return action.fetchResult.matchWith({
            Ok: ({ value }) => {
                ...
                AccountsLoadSuccess(...)
            },
            Error: ({ error }) =>
              AccountsLoadFailed(error)
          })

The bug is both Ok and Error have a value to destructure. That means AccountsLoadFailed(error) is actually AccountsLoadFailed(undefined). This ends up on the React UI and causes a null pointer:

That’s because the error is actually undefined and when you go undefined.anything it blows up. Types in Elm won’t compile if you misspell things or spell the wrong thing because you haven’t learned the API yet.

In Elm, you have types and a compiler to help ensure that never happens.

FetchAccountsResult result ->
        case result of
          Ok accountJSONs ->
            ...
            { model | accountState = AccountsLoadSuccess accounts }
          Err datError ->
            { model | accountState = AccountsLoadFailed (httpErrorToString datError) }

In the Elm code above, the AccountsLoadFailed is defined as AccountsLoadFailed String. If you were to pass the error itself like AccountsLoadFailed datError, the compiler wouldn’t compile your code, saying you’re passing an Error when you should be passing a String. Using types and a compiler, Elm ensures you’ll never get null pointers at runtime. You still have to do the work to build an error UI and format the errors for viewing.

Missing Case Statements

Missing case statements can bite you in 2 places in React. The first is in your reducers. If you miss a case statement, you get no indication you did beyond your application doesn’t work correctly. Below is a reducer that handles all 4 things you can do in the example app; loading the data, parsing the response, and pressing the next/back buttons.

accounts = (state=AccountsNotLoaded(), action) => {
  switch(action.type) {
    case 'fetchAccounts':
      ...
    case 'fetchAccountsResult':
      ...
    case 'previousAccountPage':
      ...
    case 'nextAccountPage':
      ...
    default:
      ...
  }
}

What happens when you forget one? We’ll comment out the 'fetchAccountsResult' one.

You’ll now see the loading UI forever. You won’t know if this is because the server is slow or your code is broken. If you’re using TypeScript in strict-mode, and you convert your case strings to actual type‘s, TypeScript won’t compile because you haven’t handled every potential case.

The 2nd place is forgetting the default. Again, TypeScript can help here.

The 3rd place, and is more dealing with Algebraic Data Types, is the matching syntax. For example, if our server is down, but we forget to render that part of the UI in the React component:

const AccountStates = ({ accountsState }) =>
  accountsState.matchWith({
    AccountsNotLoaded: () => (<div>Accounts not fetched yet.</div>),
    AccountsLoading: () => (<div>Loading accounts...</div>),
    AccountsLoadNothing: () => (<div>No accounts.</div>),
    // AccountsLoadFailed: ({ value }) => (<div>{value.message}</div>),
    AccountsLoadSuccess: ({ accountView }) => (...)
  })

Notice the above code has AccountsLoadFailed commented out. That means, if the server fails, you get the following null pointer error:

In Elm, every case statement is basically the matching syntax. With the compiler, this ensures you will never miss a case. Below, I have a Result when the Account REST call returns. It either worked or it didn’t:

FetchAccountsResult result ->
      case result of
        Ok json ->
          ...
        Err error ->
          ...

However, if I forget the Err, then I’ll get a compiler error:

Elm ensures you never forget a case statement, including default.

Logic Error: Off By 1

Even if all your code doesn’t have null pointer exceptions, and you handle all possible case statements, you can still have logic errors. It’s where your code doesn’t explode, but doesn’t work like you want it to. Both the React app and Elm app can have this same bug.

When you click the next and back buttons in the application, they increment what page you are in. If we can’t increment anymore, we do nothing and stay on the same page. There is a bug in this function, specifically the accountView.currentPage < accountView.pageSize. We’ll come back to this below. We’ve implemented this in the Redux reducer:

const nextPage = accountView => {
    if(accountView.currentPage < accountView.pageSize) {
      return {...accountView, currentPage: accountView.currentPage + 1}
    }
    return accountView
  }

Using that number as the index to the Array, you can determine which page you should show. We use this awesome chunk function from Lodash that takes your Array and automatically creates pages from it. So if you’re array is [1, 2, 3, 4, 5, 6, 7] and you want 3 pages, you go chunk(3, yourArray) and it’ll give you an Array that looks like [ [1, 2, 3], [4, 5, 6], [7] ]. If your current page is 0, then you’ll draw a list of [1, 2, 3]. If you’re current page is 2, then you’ll draw a list of [7].

const getCurrentPage = pageSize => currentPage => accounts => {
  const chunked = chunk(pageSize)(accounts)
  if(isNil(chunked[currentPage])) {
    return []
  }
  return chunked[currentPage]
}

When you run the application, it allow works, and you can click the next button to cycle through the pages. However, a logic error arises at the end. Once there, the screen goes blank, the numbers show 11 of 10, and you can no longer click the back button. There are no null pointers caught by React, and the console doesn’t show any issues. Wat.

The first bug as explained above is how you increment the pages:

if(accountView.currentPage < accountView.pageSize) {

That means you can increment the current page, which starts at 0, to 10 since there are 10 pages and pageSize is 10. The problem is, Array’s are 0 based, and 0 counts as a number. So now you have the ability to next to 11 pages. That logically should not be allowed, but your code allows it. The function the way it is written, being typed with TypeScript, or even Elm would still result in the same logic error of being off by 1 number.

We fix it by adding a 1 to our page size:

if(accountView.currentPage < accountView.pageSize + 1) {

Now the current page will never exceed 9 which is the last item in the Array of 10 items.

Errors in Elm

There are no null pointers in Elm; that’s one of the main draws to using it. When you compile, you will NOT get runtime errors.

Sort of. The marketing isn’t as clear as it could be on this. Let’s break down the 3 types of errors you can and cannot get in Elm. You won’t get null pointers like you do in JavaScript. There are 2 exceptions to this. The first is when you are in development mode and log out enough JSON that you cause the browser to run out of memory eventually causing the page to crash. The second is when you are integrating with JavaScript through ports and the JavaScript crashes the application by either throwing an error or disobeying the port’s rules.

The third errors are built into Elm as an Algebraic Data Type: Error. They’re just like Folktale/true-myth’s Error type and are encouraged to be used, returning them from functions that can fail. The lack of data such as undefined which typically causes errors in JavaScript is called a Maybe in Elm. It’s actually embraced in Elm as a type, just like Error to prevent null pointers from ever occurring.

We’ll focus on the Maybe, Error, and logic errors below since ports and safely working with JavaScript is beyond this article’s scope. You can read more about ports in the official guide.

Null Pointers

Most null pointers you get in JavaScript result from trying to dot on an undefined like this.someMethod() in a class or:

const value = getSomething()
const result = value.something

If the value returned is undefined, then instead of value.something, what actually happens is undefined.something and that causes a null pointer.

Null pointers also happen because you misspell things. Either the code fails immediately, or later with some subtle bug because the name you placed was on an Object property name instead of a variable or instance, and you don’t find out till later.

None of those bugs can’t happen in Elm. You’ll never have scope problems because Elm doesn’t have any. Classes hide state, and Elm is a functional language that doesn’t allow you to create any state. No classes, no this. You can store things in the Model and it feels like a variable (let or var), but any changes you make are immutable. There are no classes to hide mutations.

The second reason the dots never fail in Elm is because of the type system. If you can guarantee that all Objects (called Records in Elm) match the types exactly, then you know exactly if you can dot or something or not. Here is a Person type alias; think of it like a class you can instantiate:

type alias Person =
  { firstName : String
  , age : Int }

Now you can create a Person by simply going:

myPerson = Person "Jesse" 40

The compiler will check this for you and allow it. If you did this:

myPerson = Person 'Jesse' 40

It wouldn’t compile because single quotes are used for characters. If you did this:

myPerson = Person "Jesse" 40.2

It wouldn’t work because 40.2 is a Float, not an Int. If you did this:

myPerson = Person "Jesse"
msg = log "firstName: " myPerson.firstName

It wouldn’t work because myPerson is a partial application; it’s a function waiting for you to give it an Int so it can make a person. Since it’s a function, it has no firstName property so the program won’t compile. Technically it’s type is Int -> Person.

If you log out the name, it works fine:

myPerson = Person "Jesse" 40
msg = log "firstName: " myPerson.firstName

But if you misspell firstName to have a missing “i”:

myPerson = Person "Jesse" 40
msg = log "firstName: " myPerson.frstName

Elm won’t compile and will suggest maybe you meant firstName.

The third place you can get null pointers in JavaScript is when your code is good, and the data it creates is good and predictable, but then you get JSON from some other place like a web service. When the JSON changes, or they send you HTML instead of JSON, suddenly your functions are acting weird because they don’t know what HTML is, or the Objects they thought they were getting in JSON have slightly different names or a slightly different structure.

In Elm, all JSON into Elm is parsed using strict decoders. This ensures that no untyped values that could cause a null pointer get into Elm from HTTP calls and JavaScript. If JavaScript passes you a Person like the above, it’ll either work, or fail to parse. There is no middle ground here.

Maybe

Since there is no way to create an undefined or null in Elm, then how do you deal with things that don’t return anything? In cases where you might not get a value back, Elm provides a Maybe type. It allows you get a value wrapped in something called a Just or when you don’t have a value, it’s a Nothing. This forces your functions to suddenly handle the case when they get nothing back. Our JavaScript function above for getting the current page, you saw that it handled if it got undefined back, then it defaulted to an empty Array. This is a great practice and acts like a Maybe. However, not all functions in JavaScript handle this case and all you have to do is miss one, and POW, null pointer.

Since Elm has types, it knows what a Maybe is. This means if you mess up, misspell it, or only handle the Just, it won’t compile until you fix it. For example, if you get an item from an Array but the Array is empty, you’ll get a Nothing back. If the Array is full of things, and you ask for the first item, you’ll get a Just back. There is no way to know until runtime, though, so Elm ensures you handle both:

getFirstPersonsName = 
  case Array.get 0 peopleList of
    Just item ->
      item.firstName
    Nothing ->
      "Nobody is in the list."

If you leave out the Nothing, Elm won’t compile your code, letting you know you need to handle the Nothing case. This is true for all functions, and ensures your entire program cannot be broken by 1 missing value.

Error Type

There are functions that can work or fail. These are different than Maybe‘s. In the case of loading data from a back-end web service, it’ll either work or it won’t. Sure, you could get back an empty Array which could count as a Nothing, but there are a litany of things that could go wrong instead. All you want to know is “Did it work? Let me know and give me the value, otherwise give the error so I can show it.”

Unlike exceptions in JavaScript, however, there is no throw in Elm, nor any try/catch. There are also no error boundaries like in React. If a function can fail, you return an Ok or an Err. If you need to handle that in your UI, you do a case statement to draw a different UI for each piece:

case httpResult of
  Ok data ->
    div [] [ text ("Yay, data: " ++ data) ]
  Err reason ->
    div [] [ text ("Bummer, an error: " ++ (httpErrorToString reason))]

Logic Errors

Null pointers are fixed by types and Maybe‘s. Errors are handled by the Error type. Encoding/decoding is handled by the JSON Decoder/Encoder modules to ensure only typed data gets in. If you’re going to use Port’s, you already accepted you’re in dangerous territory. So no more bugs right?

Sadly, Elm too can still have logic errors. Types CAN help here, but they’re not a panacea. Either you don’t know the data type your need, or haven’t written the appropriate unit test, or didn’t know you needed to.

Our Elm code can have the same bug as the React app where it increments the next page too high:

nextPage accountView =
  if accountView.currentPage < accountView.pageSize then
    { accountView | currentPage = accountView.currentPage + 1}
  else
    accountView

Again, you need to remember Array’s are 0 based, so have to ensure currentPage can only be 0 through 9. You fix that by accountView.currentPage < accountView.pageSize + 1.

Before you start writing unit and functional tests, though, remember you have a pretty good type system in Elm. Can you create a type that prevents this bug from happening? Making an impossible state, impossible to happen? Richard Feldman talks about these types of data types in his talk. There are a lot of these types of data types that, once learned, ensure you’ll never get into an impossible state, and don’t even need unit tests for it.

Conclusions

React, JavaScript, Redux, and Thunks

React uses JavaScript, Redux, and Thunks. JavaScript is a dynamic language that, even with various tooling, you still have to run it to see if it works. The speed of development is great for fleshing out ideas and quickly iterating. The cost of that speed is null pointer exceptions, swallowed errors, many are just because of misspellings. This is compounded by the most libraries installed via npm being also written in JavaScript.

React helps with a few of these challenges by optionally providing PropTypes which allow better error messages at runtime. It also allows global error handling via error boundaries with fallback UI’s in the case of problems. By encouraging pure functions via propTypes in function components, and Algebraic Effects via Hooks, they’ve abstracted many of the side effects away from you which is often the causes of many bugs. It still runs on JavaScript so can only help so much. The create-react-app project generator and build system now offers TypeScript to help here.

Redux helps ensure your application only has 1 variable as your data model. You only change it via pure functions which means all data is immutable. This means the data that runs your application is predictable and removes a ton of possibilities for bugs that arise from side effects, race conditions, and mutable state.

Redux is just for synchronous changes, though. Redux Thunks handle all the asynchronous changes you need to make in reasonable to learn Promise style.

Elm

Elm is a typed, functional language that compiles to JavaScript, a framework, has a compiler, and a repl. The elevator pitch for Elm is once your application compiles, you won’t get null pointer errors. Although I still recommend Test Driven Development / Red Green Refactor, using the type system, you can refactor with confidence. Simply changing your Model makes the compiler find errors everywhere. Once you fix those and it compiles again… it works with confidence. It’s amazing. At first you feel you code Elm 5% of your time, and battle with the compiler 95%. In actuality, that 95% is the best part because once you’re done, you KNOW YOUR’RE DONE. As opposed to JS where you go “Let’s run it and see…”.

The types also help you model your application to ensure it can avoid some logic errors. You can model states that prevent the application from getting in a bad state or an impossible one.

Given that the language is functional, you never have scope problems or other mutable state changing things on you. There are no classes, nor variables, and every function is pure. All changes are immutable and this makes writing unit tests for the hairier parts of your application easier.

Elm does not allow you to create side effects. This further purifies your code making all functions taking inputs and producing outputs. While you can write pure functions in JavaScript, at some point, some function has to do the actual side-effect. The Elm framework handles that.

Like Redux, the Elm framework ensures you only have 1 model, and all changes to it are immutable, and thus predictable. Unlike Redux Thunks, the Elm framework handles both sync and asynchronous changes as normal.

Like React, Elm views are pure functions, taking in data, and returning DOM. Like React, Elm also doesn’t care how your do your CSS, although using the elm-css library can help leverage the type system for it. Like React, Elm doesn’t care how your organize your code and files.

Like JavaScript, Elm also can have logic errors. Unit tests are still valuable. Property/fuzz tests are still valuable. End to end tests are still valuable. Like JavaScript, Elm can also have race conditions. Elm solves a host of problems JavaScript does not, but you’ll still have to do work. While you may enjoy your job coding Elm more, it’s still a job requiring work.

Finally, Elm is an ongoing project. JavaScript has had explosive growth in terms of API’s implemented in the browser the past decade. Elm purifies them. This means not all API’s are yet implemented in Elm. As new ones come out, someone has to build those Elm equivalents. Thus, if you’re doing any Elm app, you’ll probably still be writing JavaScript. JavaScript doesn’t go away. How you write that JavaScript, however, is probably much more functional and predictable. Much to the chagrin of many Elm purists, npm/yarn doesn’t go away. But a ton of problems do!

You’ve learned that using Maybe‘s allows you to get rid of null pointer exceptions (i.e. “undefined is not a function”). However, now your application fails and gives no indication as to why. At least errors would leave a stack trace that may provide a hint as to where the problem originated. How does this happen and what should you be doing instead?

Null Pointers in Python vs Ruby, Lua, and JavaScript

Let’s define what we mean by null pointers first, and how you usually encounter them. Most null pointers you’ll run into as a developer are from either accessing a property of an Object to show on the screen or calling a method on an Object or class instance.

Python’s Strict

Accessing Objects (Dictionaries in Python) is very strict. If the dictionary exists but the name doesn’t or you spell it wrong, you’ll get an exception:

# Python
cow = { "firstName" : "Jesse" }
print(cow["fistName"])
KeyError: 'firstNam'

Ruby, Lua, and JavaScript are Not Strict

Ruby, Lua, and JavaScript, however, will return a nil or undefined if you access a property that doesn’t exist on the Hash/Table/Object:

// JavaScript
cow = { firstName: "Jesse" }
console.log(cow["fistName"]) // undefined

Benefits of Getting Null/Nil vs. Exceptions

All 3 languages will return their version of “nothing”. For some applications, this works out quite well:

• UI applications when displaying data
• API’s that are for orchestrating many API’s or solely exist to get around CORS
• any code dealing with NoSQL type of data

For UI’s, you typically do not control your data; you’re often loading it form some API. Even if you write this yourself, the names can get out of sync with the UI if you change things.

For API’s, you’ll often write orchestration API’s for UI’s to access 1 or many API’s to provide a simpler API for your UI. Using yours, you’ll make 1 request with efficient, formatted data how your UI needs it vs. 3 where you have to do all the error handling and data formatting on the client. Other times you want to use an API, but it has no support for CORS. The only way your website can access it is if you build your own API to call since API’s are not prevented from accessing data out of their domains like UI applications are.

For NoSQL type data, you’ll often have many Objects with the same or similar type fields, but either it’s low quality, inconsistent, or both. Often this is user entered and thus there is no guarantee that a record has “firstName” as a property.

Careful For What You Wish For

However, this has downstream effects. Sometimes code will be expecting a String or a Number and instead get undefined and blow up. Worse, the exceptions it throws are indicating the wrong place; the error occurred upstream but the stacktrace might not show that. The reverse can happen without a type system where it returns a String but the downstream is expecting an Array and queries length getting weird results…

While the benefits to being flexible are good, using a Maybe to force a developer to handle the case where undefined is returned instead is better.

Maybe’s To the Rescue

The way to solve this to use the Algebraic Data Type, Maybe. This gives you 2 ways to deal with null data. You can either get a default value:

// Lodash/fp's getOr
getOr('unknown name', 'fistName', cow) // unknown name

Or you can match, whether using a match syntax provided by a library, or a switch statement using TypeScript in strict-mode which ensures you’ve handled all possible values:

// Folktale's Maybe
cowsFirstNameMaybe.matchWith({
  Just: ({ value }) => console.log("First name is:", value),
  Nothing: () => console.log("unknown name")
})

This, in theory, is one of the keys to ensuring you don’t get null pointer exceptions because you ensure in any case you normally would, you now get a type, and force your code to handle what happens if it gets a null value, even if that so happens to be throwing a custom error.

Downstream Still Suffers

However, Maybe‘s can still causing suffering downstream just like undefined can. They do this via default values. In the getOr example above, we just provided “unknown name”. If we get nothing back, we just default to “unknown name” and handle the problem later, or don’t if it’s a database data quality issue we can’t fix. For a UI developer, that’s often perfect as they can usually blame the back-end developers for the problem, and their code is working perfectly, and thus fire-drill averted, blame diverted.

However, other times, it ends up hiding bugs. For non-FP codebases, a downstream function/class method will get null data and break.

For FP codebases, they’ll get default data which often the developer never intended, and something goes awry. This is what we’ll focus on below.

Examples of Default Value Causing UI Drama

Let’s define what we mean by default value as there is the imperative version where function arguments have default values for arguments if the user doesn’t supply a value, or a Maybe which will often come with a default value through getOr in Lodash, getOrElse in Folktale, or withDefault in Elm.

Default Values For Function Parameters

Default values are used by developers when methods have a common value they use internally. They’ll expose the parameter in the function, but give it a default value if the user doesn’t supply anything.

The date library moment does this. If you supply a date, it’ll format it:

moment('2019-02-14').format('MMM Do YY')
// Feb 14th 19

However, if you supply no date, they’ll default to “now”, aka new Date():

moment().format('MMM Do YY')
// Jul 14th 19

Think of the function definition something like this. If they don’t supply a maybeDate parameter, JavaScript will just default that parameter to now.

function moment(maybeDate=new Date()) {

Default Values for Maybes

While useful, things can get dangerous when you don’t know what the default values are, or if there are more than one, or what their relationship to each other is. In Moment’s case, it’s very clear what no input means: now. Other times, however, it’s not clear at all. Let’s revisit our default value above:

getOr('unknown name', 'fistName', cow) // unknown name

What could possibly be the reason we put default value “unknown name”? Is it a passive aggressive way for the developer to let Product know the back-end data is bad? Is it a brown M&M for the developer to figure out later? The nice thing about string is you have a lot of freedom to be very verbose in why that string is there.

getOr('Bad Data - our data is user input without validation plus some of it is quite old being pulled from another database nightly so we cannot guarantee we will ever have first name', 'fistName', cow)

Oh… ok. Much more clear why. However, that clarity suddenly spurs ideas and problem solving. If you don’t get a name, the Designer can come up with a way to display that vs “unknown name” which could actually be the wrong thing to show a user. We do know, for a fact, the downstream database never received a first name inputted by the user. It’s not our fault there is no first name, it’s the user’s. Perhaps a read-only UI element that lets the user know this? It doesn’t matter if that’s correct, the point here is you are investing your team’s resources to solve these default values. You all are proactively attacking what would usually be a reaction to a null pointer.

Downstream Functions Not Properly Handling the Default Value

Strings for UI elements won’t often cause things to break per say, but other data types where additional code later expects to work with them will.

const phone = getOr('no default phone number', 'address.phoneNumber[0]', person)
const formatted = formatPhoneNumber(phone)
// TypeError

The code above fails because formatPhoneNumber is not equipped to handle strings that aren’t phone numbers. Types in TypeScript or Elm or perhaps property tests using JSVerify could have found this earlier.

Default Values for Maybes Causing Bugs

Let’s take a larger example where even super strong types and property tests won’t save us. We have an application for viewing many accounts. Notice the pagination buttons at the bottom.

We have 100 accounts, and can view 10 at a time. We’ve written 2 functions to handle the pagination, both have bugs. We can trigger the bug by going to page 11.

I thought you just said we have 10 pages, not 11? Why is the screen blank? How does it say 11 of 10? I thought strong types and functional programming meant no bugs?

The first bug, allowing you to page beyond the total pages, is an easy fix. Below is the Elm code and equivalent JavaScript code:

-- Elm
nextPage currentPage totalPages =
  if currentPage < totalPages then
    currentPage + 1
  else
    currentPage

// JavaScript
const nextPage = (currentPage, totalPages) => {
  if(currentPage < totalPages) {
    return currentPage + 1
  } else {
    return currentPage
  }
}

We have 100 accounts chunked into an Array containing 9 child Arrays, or our “pages”. We’re using that currentPage as an Array index. Since Array’s in JavaScript are 0 based, we get into a situation where currentPage gets set to 10. Our Array only has 9 items. In JavaScript, that’s undefined:

accountPages[9] // [account91, account92, ...]
accountPages[10] // undefined

If you’re using Maybe‘s, then it’s Nothing:

accountPages[9] // Just [account91, account92, ...]
accountPages[10] // Nothing

Ok, that’s preventable, just ensure currentPage can never be higher than the total pages? Instead, just subtract one from totalPages:

-- Elm
if currentPage < totalPages - 1 then

// JavScript
if(currentPage < totalPages - 1) {

Great, that fixes the bug; you can’t click next beyond page 10, which is the last page.

… but what about that 2nd bug? How did you get a blank page? Our UI code, if it gets an empty Array, won’t render anything. Cool, so empty Array == blank screen, but why did we get an empty Array? Here’s the offending, abbreviated Elm or JavaScript code:

-- Elm
getCurrentPage totalPages currentPage accounts =
  chunk totalPages accounts
  |> Array.get currentPage
  |> Maybe.withDefault []

// JavaScript
const getCurrentPage = (totalPages, currentPage, accounts) => {
  const pages = chunk(totalPages, accounts)
  const currentPageMaybe = pages[currentPage]
  if(currentPageMaybe) {
      return currentPageMaybe
  }
  return []
}

Both provide an empty Array as a default value if you get undefined. It could be either bad data the index currentPage but in our case, we were out of bounds; accessing index 10 in an Array that only has 9 items.

This is where lazy thought, as to how a Nothing could happen results in downstream pain. This is also where types, even in JavaScript which doesn’t have them but can be enhanced with libraries, really can help prevent these situations. I encourage you to watch Making Impossible States Impossible by Richard Feldman to get an idea of how to do this.

Conclusions

Really think about 4 things when you’re using Maybes and you’re returning a Nothing.

If it truly is something you cannot possibly control, it truly requires someone upstream to handle it, then that is the perfect use case, and why Object property access, and Array index access are the 2 places you see it used most.

Second, have you thought enough about how the Nothing can occur? The below is obvious:

const list = []
console.log(list[2]) // undefined

But what about this one?

const listFromServerWith100Items = await getData()
console.log(list[34]) // undefined

If accessing data is truly integral to how your application works, then you are probably better served being more thorough in your data parsing, and surfacing errors when the data comes in incorrectly. Having a parse error clearly indicate where data is missing is much more preferable than having an unexpected Nothing later but “hey, everything says it parsed ok….”

Third, be cognizant about your default values. If you’re not going to use a Result, which can provide a lot more information about why something failed, then you should probably use a better data type instead that comes embedded with information. Watch “Solving the Boolean Identity Crisis” by Jeremy Fairbank to get a sense at how primitive data types don’t really help us understand what methods are doing and how creating custom types can help. Specifically, instead of [] for our getCurrentPage functions above, use types to describe how you could even have empty pages. Perhaps instead you should return a Result Error that describes accessing a page that doesn’t exist, or an EmptyPage type vs. an empty Array leaving us to wonder if our parsing is broke, we have a default value somewhere like above, or some other problem.

Fourth, this default values will have downstream effects. Even if you aren’t practicing Functional Programming, using default values means your function will assume something. This function will then be used in many other functions/class methods. She’ll provide some default value others further down the function call stack won’t expect. Your function is part of a whole machine, and it’s better to be explicit about what the default value is you’re returning. Whether that’s a verbose String explaining the problem, or a Number that won’t negatively affect math (such as 0 instead of the common -1), or a custom type like DataDidntLoadFromServer.

Making assumptions to help yourself or other developers is powerful, but be sure to take responsibility with that power and think through the downstream affects of those default values.