programming – Software, Fitness, and Gaming – Jesse Warden

React Redux Thunk vs Elm

JesterXL — Sat, 05 Oct 2019 19:20:44 +0000

Introduction

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 = () => (

Sup

)

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

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 => (

Sup {props.name}

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:

Sup

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:

Sup

Styling with style:
const myStyles = { color: 'red' }

Sup

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).

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!")}>Supbutton>

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:

Messages (think onClick + Redux Action Creator)
Commands (think Redux Action Creator)
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 , 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

Advent of Code 2018 in Elm Review

JesterXL — Mon, 28 Jan 2019 02:38:29 +0000

Introduction

I participated briefly in the Advent of Code 2018. Every year, they post 31 coding puzzles, 2 per day. You have to solve them before you can proceed to next one. I wanted to post about what I learned. I’ve never participated before, and wanted to use it an excuse to force myself to use a Functional Programming language. I use Functional Programming concepts in my day job, but never had the opportunity to immerse myself, and force myself, to accomplish harder challenges in a pure FP language. It was doubly hard because the exercises are NOT what I do at my day job at all and are challenging. They were very hard in a fun way, though. Below I’ll cover the 6 exercises I did (I threw in the towel on Day 7), and explain some of the interesting nuances I found either with the exercise and thinking in FP… and thinking in Elm.

Why Elm?

Elm is a Functional Programming language for building web applications. It’s like Haskell, but has little to no Category Theory nonsense, and is sort of tailored for traditional UI/web developers. Given I’d been away from front-end development for awhile dealing with Python, Node, and Go for the past 2 years, I figured Elm was a great choice to get back into front-end. I had struggles in the past with Elm, especially around random numbers, and the figuring out what the compilation type errors meant.

Overall Challenges With Elm

I had a few challenges with the Elm language I’d like to highlight that I found interesting. I’ve played with Elm a couple of times in the past, and while time away learning more FP did help a lot, I still had struggles.

Out of Practice with Types

When I thought TypeScript was cool, the rest of the JavaScript industry did not, so I learned to live without types for a long time. I came from ActionScript 2 and 3 which are like Java, so I had spent years getting comfortable and happy with types. Getting into JavaScript, the industry wasn’t ready for them, so I learned to go without.

Going back is super rough after spending years in JavaScript, Lua, Python, and even a brief stint in Go. Trying to do currying in Go was an exercise in pure masochism whereas it is built in in Elm and falls in the background, almost unnoticed. I think in 6 exercises I used 1 partial application without composing (which in Elm doesn’t really count).

My main challenge though with the types is playing with ideas now has another, huge cost. I only care if the code mostly works; I’m just trying to validate some ideas and approaches. Elm, and the Hindley-Milner type system specifically, help ensure no runtime errors which means they pull no punches with letting you know how your code is “incorrect”. There is no any like there is in TypeScript. While this is great for production code, it’s awful for when you “have a day to vet a solution(s) and come up with a mostly working prototype”.

Time and time again I would break out JavaScript and Node either locally or in Code Sandbox IO to play with ideas and test algorithms, THEN I’d rewrite in Elm. Starting in Elm was harder for some algorithms I couldn’t wrap my head around just yet.

No Loops, Only Recursion

Elm being purely functional means there are no loops for programming. You can only use recursion to ensure no side effects. Given a lot of the Advent of Code 2018 exercises were around parsing large arrays/lists multiple times, it was very common to see JavaScript and Python solutions use while(true) with a break when some condition was met and nested for loops often.

Elm has no loops. Instead, you either use manual recursion where a function calls itself, or a case statement (which is not a JavaScript switch statement and more like an Elixir pattern matching case). I’ll cover a few examples below. I point this out because that way of thinking is SUPER HARD after 15+ years of my brain being wired to think in loops and nested loops. You do a lot of that in GUI programming for layout and it’s amazing how hard it was for even simple things to think recursively.

Syntax Whitespace

Elm is almost as strict about whitespace as Python. I say almost because it’s still unclear when a return statement will completely break compilation or it’s fine and suddenly things are much more readable. I failed to find a good guide on what you’re allowed do and suggestions beyond commas before items in lists.

I bring this up because…

Verbose Anonymous Functions

… anonymous functions are a bit verbose. You NEED them when you’re playing with ideas, especially when you’re porting from Python or JavaScript. I don’t just mean the ideas, I also mean the types specifically. You may like your chain of parsing code… but aren’t sure yet if you’re going to commit to a List or an Array, nor do you know what types will be in that list yet. Anon functions allow a lot of flexibility in Elm combined with let statements to log things out before you’re ready to commit to types and more normal, non-anonymous functions.

Now, the syntax itself is nice: (\arg -> arg + 1)

Compare that with JavaScript: arg => arg + 1

However, once you start whipping out the foldl (Elm’s version of Array.reduce) function, things can get pretty gnarly to read pretty quickly. I never figured out a good spacing solution/convention here beyond “refactor it to normal functions so you can actually read it”. I’ll show some examples below of smushed anons and you’ll go “Oh… gross, refactor that, man!”

Approaching Full Lisp with Tons of Parenthesis

Applying FP concepts in JavaScript has resulted in my JavaScript looking a lot like Lisp in the annoying way: tons of parenthesis because of curried functions everywhere.

.then( value => something(JSON)(request)(value) )

Even when I took out anonymous functions, I still had nested functions, and sometimes Elm doesn’t know what you mean so you have to use parenthesis to tell it exactly. Still, it’s MUUUUCH more preferable to have to add them later vs. being required like you are in JavaScript/Python FP programming.

Here, we have a large chained set of functions and the parenthesis aren’t bad at all:

Yet here, I’m just creating a simple type with parameters… but I have functions to ensure they are converted and… bleh:

Again, much better than JavaScript, I realize this is super nitpicking.

Tooling Coloring

I’ve always thrived on code coloring; it helps me quickly see the different parts of the code and help me comprehend what a function is doing. My current Elm plugin for VSCode however doesn’t seem to highlight methods correctly, only the modules. This becomes a problem when you import both Array and List and they have many of the same method names like map. To ensure you don’t get a compilation error, it’s just easier to prefix the method with the module, which you start doing with unrelated things like Maybe just to be consistent. You make your code more verbose, though.

Notice how none of the methods, both mine and the native ones, are colored; the same gray color. It stays that way if you omit List and Array resulting in this:

Terse, yes, readable… sure, but I want my colors like I have with all the good Python and JavaScript code coloring plugins. It’d also get confused about exactly where the error is in the code when clicking the errors in the compilation/errors area and scroll to the wrong part. Still, I liked the red underline of problem areas + on the right side indicating where in the code issues were.

Modern Web Compilation Toolchain

In JavaScript, you can actually devote your entire career to D3.js, making data visualizations. The same can be said for compiling JavaScript using Babel and Webpack together. For those of us who came from a world where companies build all that for you such as C, Visual Studio Code for C#, ActionScript in Flash/Flash Builder Eclipse and nowadays Create React App, Angular CLI, and Vue CLI… it’s ridiculous to think all of us are interested in, yet again, creating a custom compilation chain for Elm in the browser. For must of us, we have the same common need: convert this Elm to JS and put in an index.html.

Elm Reactor never seems to work for me, and while you can survive for a little while using just a Main.elm file, eventually you’ll need a basic index.html… like… you know, every other web app today. I prefer Facebook to create, upgrade, and maintain my compilation toolchain (create react app) while I focus on building things. Elm doesn’t have that yet (or I just suck at Elm Reactor) so I hacked the minimal Webpack required possible and just copy pasta’d between projects. I bring this up because the big 3 realized awhile ago you need a cli to do this stuff for developers and it’s a huge time sink + duplicated effort without. Playing the waiting game has some benefits such at ES6 ALMOST works in modern browsers, heh, but… for those of us who want to code and deploy today… we need better.

Type Hinting is “Ok”

Considering we’re using one of the best in class type systems, shouldn’t the type hints I receive when using a function or module also be best in class? Apparently not. Observe me trying to use a previously defined function and a type; both give me pathetic code hints. I’ve seen it sometimes work; maybe I should be using some other extension or something other than VSCode.

Concurrency

Many of the exercises are meant to get the performance nerds excited. As a FP programmer in dynamic languages, the last thing I care about is performance… because it’s not a problem I have. I’m building web applications to show 20 items in a table, or pulling 12kb of JSON from a Lambda web service. However, even some of the basic exercises would get you to tens of thousands to hundreds of thousands of iterations. I heard from my friends who were much farther along they were well into the millions and wondering how their Python would compare against the likes of Go and Rust for some of the exercises.

I noticed that the UI would get blocked for a lot of my code. Now, even the low hanging fruit of using a List over an Array, or a Set over an Array I could of made some big gains, but even the little things I ignored too. Perhaps it would help a lot, but above 10,000 iterations I highly doubt it. Since I was building UI’s for all my exercises and none of my loops needed I/O, this is a perfect use case for WebWorkers. Elm has a initial Process API, but the documentation makes it sound like it’s not ready yet. The only time the long running loops broke my browser were because I was logging so much JSON it made Chrome run out of memory. However, if I turned logs off, Days 1 – 6 ran in a reasonable amount of time. As a UI developer, I know blocking the UI is amateur hour given the API’s we have in the browser, so I’d like to figure out the correct way to do that in Elm.

Day 1 – 6 Review

Below I’ll cover the code for each exercise. While you can read the code to see how I solved the challenges on your own, I’m just covering the parts I thought were interesting about learning Elm and FP in general.

Elm uses extensive use of the pipeline operator; you can learn more about it if the use in the code below doesn’t make sense.

Day 1: Frequency Parser

Source Code | Link to Application

Day 1, Challenge 1 was pretty straightforward: parse a list of positive and negative integers. The solution is basically taking all those numbers and adding them up. This is the kind of stuff list comprehensions were built for:

frequency = List.sum list

That’s about the same as sum in Lodash:

const frequency = sum(list)

However, Challenge 2 you have to find when it reaches the same number twice. The easiest way in imperative coding is to simply use a while(true) and use a JavaScript Set to ensure no duplicates get added and just increment a counter. Yet, this is Elm, so it was my first taste of using recursion to solve a problem. It was also the first indication of a pattern: foldl is used for all the things. Seriously, since most of the challenges were looping through lots of items and changing them, you end up using foldl as your go to for everything.

This was also the first pattern of many where I gave up, whipped out JavaScript, then went back into Elm. The speed at which you can quickly prototype 1 line of code or 1 algorithm I cannot currently match in Elm, even in the elm repl. The Elm in browser editor Ellie App helps, no doubt, but it’s not as fast as Node or Python are on the command line.

It ended up being:

matchOrNot = reduceUntilMatch  { matched = False, frequency = 0, match = 0, set = Set.singleton 0 } list

Where reduceUntilMatch keeps calling itself until it finds a match. All reduce functions have an initial state, and that MatchOrNot type I create was basically a collection of the 4 variables I created in the JavaScript loop version, heh.

Day 2: Checksum Parser

Source Code | Link To Application

I don’t know much about checksums, but Day 2 was the only one I breezed through without having to think hard, debug for days, and/or whip out JavaScript or Python.

A few interesting things that started happening at this point in the exercises. First, I stopped caring about typing all my functions. The Elm compiler was good enough to infer what I needed and sometimes providing code hints in my code for me. Second, this then lead to more uses of anonymous functions.

filterOutSameLetters charList =
    List.map (partitionSameLetters charList) charList
        |> List.filter (\matchList -> List.length matchList > 1)

Notice no type definition above filterOutSameLetters and I didn’t take the time to define the filter function.

Third, Maybes started to get annoying. Most type systems can’t type things in RAM like “what is item 3 in a List of Strings?” Instead they give you a Maybe value. However, once you start composing things, you can have start dealing with default values which can be a pain. You really really really have to think about the ramifications, both at the point you give a default value, and later down the line: what does this do to the correctness of my algorithm? I briefly had these problems in JavaScript, but I’m doing UI or API development, not Machine Learning/Data Science so I don’t deal with this level of data correctness in my job. Here in Elm, with types, it amplified.

Fourth, that really drove home I could have massive bugs in “code that compiles and has no runtime errors”. That was massive pill to swallow. I had gone down the FP path to create code that I kept hearing was better, more resilient, and had no errors. I had apparently missed the nuance around “no errors” still meaning you code could be “wrong” and “broken”, hah!

Finally, fifth, the let keyword is a godsend. I need to create imperative style code to play with my functions and algorithms in Elm. You write a variable, and then log it out a line below:

filteredMatches =
    Array.filter (\item -> item.match == True) matches
filteredMatcheslog = log "filteredMatches" filteredMatches

In JavaScript, there is a trend hardcore FP’ers will ensure fat arrow functions don’t have squiggly braces {} because that implies the code is imperative and may hide side effects.

const doStuff = arg => someFunction(arg)

However, as SOON AS something is weird, they’ll (myself included) change it back so they can debug what’s going on:

const doStuff = arg => {
    console.log("arg:", arg)
    const result = someFunction(arg)
    console.log("result:", result)
    return result
}

I’m not sure why, but I felt a lot less guilty using let in Elm.

Day 3: Claims Parser

Source Code | Link To Application

I’ve seen it stated the main difference between a senior developer and a junior is that the senior, when they write a line of code, it will live longer than the junior’s. The junior will write it, modify it, then later delete it as part of a larger refactoring effort. Day 3 confirmed that I am indeed a junior in Elm. After spending 5 days, and finally figuring things out in Python and JavaScript, I rewrote my 4 days of work in Elm and started from scratch because the algorithms I had created were too hard to untangle. I haven’t felt that n00b in a long time which was kind of cool, yet humbling.

The exercise is to calculate where all rectangles are drawn, and then the overlap, and the largest overlap. I used Canvas to visualize since I feel at home there and liked to see my algorithms work or fail. That and most importantly, I’ve always dreamed what UI development would be without state, specifically drawing things. I don’t know how I’d do this in JavaScript, but in Elm it just feels super natural and not as alien as I thought.

Defining types in Elm is easy, but creating them has been challenging.

type alias Claim = 
    { id : Int
    , rectangle : Rectangle 
    , calculated : Bool
    , overlaps : Bool }

type alias Rectangle =
    { left : Int
    , top : Int
    , width : Int
    , height : Int
    , right : Int
    , bottom : Int
    , overlaps : Bool }

I started using helper functions to simply the creation and reduce how many parenthesis I had to use. Case in point, creating a Rectangle, and then creating a Claim which composes a Rectangle within it.

-- easier if I make a function so I can generate the right and bottom properties when you make the rectangle
getRectangle : Int -> Int -> Int -> Int -> Rectangle
getRectangle left top width height = 
    Rectangle left top width height (left + width) (top + height) False

-- easier to create a claim this way, less parameters
getClaim : Int -> Int -> Int -> Int -> Int -> Claim
getClaim id left top width height =
    Claim id (getRectangle left top width height) False False

Seems like boilerplate, but man, using it was as simple as:

getClaim id left top width height

Sadly, I still had type cast the integers to floats when I went to draw them in the Canvas (note the toFloat ):

renderFilledRectangle x y width height color cmds =
    cmds
        |> Canvas.fillStyle color
        |> Canvas.fillRect (toFloat x) (toFloat y) (toFloat width) (toFloat height)

Which is ok. I started learning that most of the code had no care about floats; the only thing which consistently cared about that was the View so I made that a View problem to handle which makes my data code a lot easier to deal with. That and I don’t need high precision in the UI; we’re just visualizing things, not making important decisions based on a pixel’s location.

Finally, Day 3 is where the types in Elm really drive home why you can’t get runtime errors. The sheer amount of typing it took to parse the String JSON to an Elm type compared to zero effort on JavaScript’s part is night and day… like 1 line of JavaScript to 88 lines of Elm. In JavaScript, you just read the file via fs.readFileSync and then JSON.parse .

In Elm, however, JSON.parse is full of side effects, so they make you use lower-level primitives and you have to parse your way up. You can either parse raw Strings which I did in Day 3, or use their parser engine which I’ll talk about in another exercise below. Here’s parsing a single claim.

parseClaimStrings : Array String -> Claim
parseClaimStrings stringArray =
    let
        id =
            Array.get 0 stringArray
            |> Maybe.withDefault "#0"
            |> String.replace "#" ""
            |> String.toInt
            |> Maybe.withDefault 0

        left =
            Array.get 2 stringArray
            |> Maybe.withDefault ","
            |> String.split ","
            |> Array.fromList
            |> Array.get 0
            |> Maybe.withDefault "0"
            |> String.toInt
            |> Maybe.withDefault 0
        top =
            Array.get 2 stringArray
            |> Maybe.withDefault ","
            |> String.split ","
            |> Array.fromList
            |> Array.get 1
            |> Maybe.withDefault "0"
            |> String.replace ":" ""
            |> String.toInt
            |> Maybe.withDefault 0

        width =
            Array.get 3 stringArray
            |> Maybe.withDefault "x"
            |> String.split "x"
            |> Array.fromList
            |> Array.get 0
            |> Maybe.withDefault "0"
            |> String.toInt
            |> Maybe.withDefault 0

        height =
            Array.get 3 stringArray
            |> Maybe.withDefault "x"
            |> String.split "x"
            |> Array.fromList
            |> Array.get 1
            |> Maybe.withDefault "0"
            |> String.toInt
            |> Maybe.withDefault 0

    in
        getClaim id left top width height

I know that’s a bit insane, so let’s just take the width portion and do a side by side with JavaScript to see what we’re dealing with. In both languages, you have a string that looks like #147 @ 570,688: 27x25. That is a claim; an id number with an x and a y position divided by a comma, and finally a width and height divided by an x. For the width, we need that 570 number. For both Elm and JavaScript, if you split that on the space, you can pick out what you need from an Array by index. i.e. 0 will be the id, 2 will be x and y together, and 3 will be the width. That looks like 27x25. Parsing that with pure functions that cannot throw errors, let’s break down the algorithm:

width =
    Array.get 3 stringArray
    |> Maybe.withDefault "x"
    |> String.split "x"
    |> Array.fromList
    |> Array.get 0
    |> Maybe.withDefault "0"
    |> String.toInt
    |> Maybe.withDefault 0

Array.get 3 stringArray gives you a Maybe; it’ll either be Just(27x25) or Nothing
Because of the Nothing, we say “ok, default with an ‘x’ then” so you can split and get nothing later down the line” using Maybe.withDefault "x"
String.split "x" will give us a List with 2 items. If it’s just “x”, well, it’ll be a List with 2 empty Strings… otherwise it’ll be ["27", "25"]
However, you can’t get individual items in an List (List has no get method) so we have to convert to an Array so we can get the first item, the width. (“Jesse, why didn’t you use List.head?” “Because I’m a n00b!”)
… however (again), Array.get 0 gives us a Maybe ; either Just("27") or Nothing so… we default to “0” knowing we’ll attempt to convert from a String to an integer later.
String.toInt will give you yet another bloody Maybe because there is no way to guarantee the String is parseable as an Integer using the types, so… we default to 0.

JavaScript? parseInt(str.split(' ')[3].split('x')[0]) although, a couple JavaScript and Python implementations I saw didn’t even parse it out; they just used those strings as lookups in an Object/Dictionary.

Now, the good news, that entire Elm pipeline is type safe. Meaning, I won’t get any exceptions at runtime no matter how bad the String is mangled. The bad news is you really need to think about the default values for the Maybes. What if 0 really is a valid value for example? I probably should have used Result instead to be more strict with the parsing. You can see, however, that assuming your data is static, how JavaScript is a lot more terse, and easier to play with ideas if you don’t care about types and generally know your data is ok.

One side note is that the Elm Canvas version 3 uses requestAnimationFrame for efficient rendering, but doesn’t work in Ellie App. Version 2 does work in Ellie App AND doesn’t require your Elm application to care about subscriptions (think WebSockets in Redux). So I stuck with v2. Despite the fact they both require a JavaScript pipe (the 2nd way I found to crash an Elm app by writing crappy JavaScript in a pipe), I never had any Canvas issues at all; wonderful library.

Day 4: Sleep Schedule

Source Code | Link To Application

Day 4 was about parsing sleep times. Like many a programmer, I dread anything dealing with Date math. Elm, unlike JavaScript, has only Posix time, and … well, the API sucks compared to JavaScript’s, especially with something like Moment or date-fns. There are a few Elm date libraries, but I found I could get by doing integer math myself.

I struggled to get the sorting right, so dropped into the Elm Slack where they had an Advent Of Code 2018 room to see how others were approaching it. I noticed one developer used a different type of String parsing I hand’t seen before part of the Parser library. It parses things string character by string character, but supports branching in case the strings don’t align up because of whitespace or some other reason. I used this as an opportunity to learn it vs. my traditional String to Array fu. The case-like statements it supports are… interesting. It felt a lot more flexible and “made for parsing” than good ole String.split.

I also liked some of the equality I was seeing to compare things. Since I had made up my own Date type, I had to figure out how to tell if it was greater than, equal, or less than something. Elm doesn’t have a valueOf for purity reasons, but they DO have an Order type you can use the compare function. My brain started melting (a common occurrence during these exercises) once I started having to further compare deeper parts of the date if something matched.

For example, comparing of 2017 equals 2018 is pretty straightforward:

compareDateTimeYear : DateTime -> DateTime -> Order
compareDateTimeYear a b =
    compare a.year b.year

If we call compareDateTimeYear with 2017 and 2018, it’ll return LT. But how do you compare the whole date? You make a bunch of those compare functions on the pieces, THEN put ’em in a big, nested case statement:

compareDateTimes : DateTime -> DateTime -> Order
compareDateTimes a b =
    case compareDateTimeMonth a b of
            EQ ->
                case compareDateTimeDate a b of
                    EQ ->
                        case compareDateTimeHour a b of
                            EQ ->
                                compareDateTimeMinute a b
                            _ ->
                                compareDateTimeHour a b
                    _ ->
                        compareDateTimeDate a b
            _ ->
                compareDateTimeMonth a b

She’s a big “meh” in terms of nesting, but I was proud I made her and she works.

Finally, this was my first taste of Tuples and at first I thought they were the weirdest, dumbest thing, but I was wrong… more on them later.

Day 5: Polymer Parser

Source Code | Link To Application

Day 5 was basically parsing letters. Like Day 2’s checksum parser, I don’t know why, but I found this one easy. For whatever reason, the recursion made more sense here since you’re basically “swimming over and over in a large string you keep shrinking”. I can always visualize recursion and String parsing.

The only thing I’ll point out for Day 5 is that Elm, currently, doesn’t tell you when you have dead code. For Day 5 that’s fine as even with the un-used imports, it’s still a small file. In JavaScript, the latest version of VSCode will darken the variable, showing it’s not used. However, you can sometimes have code you THINK is being used, but isn’t. I wish there was either a visual like there is with JavaScript, or some kind of compiler switch for it.

Day 6: Coordinates Finder

Source Code | Link To Application

Day 6 was one of the tougher ones. My math kept being slightly off, and I haven’t yet gotten good about extracting small parts of my algorithms… which incidentally is exactly what Functional Programming is all about; small, re-usable functions and yet here I am struggling, hah! I referred to a co-workers Python, and one simple trick he did was loading in 4 coordinates instead of all 50. This made my code a ton faster and easier to test. I also determined I was 99% there, I just had 1 bad line of code saying a coordinate didn’t belong.

In retrospect, had I known ahead of time they were looking for a Voronoi graph, I would have started there first. I did end up with some pretty looking mistakes, though.

Again, I found I made more progress prototyping algorithms in JavaScript than Elm, mainly because it was easier to debug, faster to play without types yelling at me, and I could quickly test and create new scenarios. Maybe that will change over time like it did with ActionScript 2 and 3 and types just became “second nature” when coding.

The one thing I liked about Day 6 beyond creating cool looking visualizations was getting familiar with Tuples. They’re like an Elm List, but you can get values from them and you don’t get Maybes back! This makes working with them super convenient and a lot less code. It seemed strange at first a special list type only having 2 things and I thought it was so dumb, but then I started seeing them everywhere, and made an effort to build them into my types just because they were so worth it, being easy to use. Think of {:ok, value} in Elixir or err, value in Go function return values, and you’ll get it.

Conclusions

Advent of Code 2018 was not easy, it’s quite advanced. The types of challenges are not something I’ve ever had to deal with in my 19 years of software development. Coupled with trying to learn a new language with a new way of thinking about programming, it was a recipe for pain. I’m glad I did it, though.

I’m convinced Elm for front-end is still the best. I like React + Redux, but the magic and lack of determinism and challenges of testing of JavaScript in general always have rubbed me the wrong way ONCE I LEARNED there was another way. For context, I was “done and happy” in my Model View Controller, Object Oriented Programming world of strong compiler and runtime types back in my Flash and Flex days. Taking what I’ve learned from FP, and even Elm, back to JavaScript I felt has brought a strong level of determinism in my code, made it easier to test, and made it a ton easier to blame the back-end or Ops for all of my problems. While writing UI’s in Elm without components can be painful (i.e. invest in Material Design, Bootstrap, or your own Company’s design system), it’s nice to know even without unit tests your application won’t explode in production. It’s nice to know I can write unit tests strictly on my business logic vs. “do all the things talk to each other correctly”. I haven’t done it yet (trying to at work), but I bet if I used Cypress for end to end tests, it’d be… boring… because they’d always work. Anyway, I love that level of confidence in my software.

At first I felt a little down on myself for not using PureScript at this year’s Advent of Code since it would of been a wonderful opportunity, but this has been proof that I don’t need to know Category Theory to be awesome at Functional Programming on the web.

I should point out some of the funny comments from friends online and off. Specifically about Elm’s verbosity, especially when compared to JavaScript and Python… and even Swift.

First, Elm is for the front-end. This means you’ll have GUI code mixed in with your algorithm code. A lot of people who participated in Advent of Code did not build UI’s.

Second, I have types to ensure no runtime errors; JavaScript/Python do not (yes, I know about Python 3’s opt in ones).

Third, the types are compile time only; I don’t have a runtime like Java/Swift to enforce while the code is running.

Fourth, I’m new to Elm, heh! Perhaps if I had better colors and more experience I could make her a lot more terse.

I look forward to participating this holiday season in 2019, although I have no clue what language/tech stack I’ll use.

Functional Programming Unit Testing in Node – Part 6

JesterXL — Fri, 22 Jun 2018 16:29:15 +0000

Next, Logging, and Conclusions

Welcome to Part 6, the final installment in this series. Below we cover unit testing the noop next, how to create pure functions that wrap noop so you can compose them, and finally using code coverage to strategically hit the last code that’s not covered.

This is a 6 part series on refactoring imperative code in Node to a functional programming style with unit tests. You are currently on Part 6.

Next is Next

The last part is deal with next. THIS is where I’d say it’s ok to use mocks since it’s a noop, but you do want to ensure it was called at least once, without an Error in the happy path, and with an Error in the bad path.

… but you’ve made it this far which means you are FAR from ok, you’re amazing. NO MOCKS!

Here’s the basic’s of testing noops. You sometimes KNOW if they did something, or how they can affect things based on their arguments. In next‘s case, he’ll signal everything is ok if passed no arguments, and something went wrong and to stop the current connect middleware chain if an Error is passed, much like a Promise chain. We also know that next always returns undefined.

Ors (Yes, Tales of Legendia was bad)

One simple way is to just inject it into the existing Promise chain we have:

.then( info => next() || Promise.resolve(info))
.catch( error => next(error) || Promise.reject(error)))

This’ll make the connect middleware happy as well as satisfying our unit tests expecting either an email info out, or a rejected promise with error.

Pass Through

Much like you log Promise or other Monad chains, simply make a pass through function.

const nextAndResolve = curry((next, info) => next() || Promise.resolve(info))
const nextAndError = curry((next, error) => next(error) || Promise.reject(error))

And since we already know what the next is, we can just attach ’em to the end of the Promise chain, similar to above:

.then(nextAndResolve(next))
.catch(nextAndError(next))

“Wat!?” you may be saying, “all you did was wrap that previous example in functions”. Yup, they’re pure, and you can test those in isolation vs. test that gigantic Promise chain with 20 billion stubs.

describe('nextAndResolve when called', ()=> {
    it('should fulfill', () => {
        return expect(nextAndResolve(noop, 'info')).to.be.fulfilled
    })
    it('should resolve', () => {
        return expect(nextAndResolve(noop, 'info')).to.become('info')
    })
})

Let’s do the same for error:

describe('nextAndError when called', ()=> {
    it('should fulfill', () => {
        return expect(nextAndError(noop, new Error('they know what is what'))).to.be.rejected
    })
    it('should resolve', () => {
        const datBoom = new Error('they just strut')
        return expect(nextAndError(noop, datBoom)).to.rejectedWith(datBoom)
    })
})

If you’re Spidey Sense left over from your Imperative/OOP days is tingling, and you really want to create a mock or spy, go for it.

I would rather you focus your time on creating pure Promise chains vs. investing in better testing side effects using the connect middleware.

Mopping Up

Only 2 functions to go, and we’re up in dem hunneds .

sendEmail … or not

The sendEmailOrNext is a textbook case of copy-pasta coding. We’ll duplicate our previous sendEmail unit tests since they have some yum yum stubs:

describe('sendEmailOrNext when called', ()=> {
    ...
    const reqStubNoFiles = { cookie: { sessionID: '1' } }
    ...
    it('should work with good stubs', ()=> {
        return expect(
            sendEmailOrNext(
                readFileStub,
                configStub,
                createTransportStub,
                getUserEmailStub,
                renderStub,
                reqStub,
                resStub,
                nextStub
            )
        ).to.be.fulfilled
    })
    it('should fail with bad stubs', ()=> {
        return expect(
            sendEmailOrNext(
                readFileStubBad,
                configStub,
                createTransportStub,
                getUserEmailStub,
                renderStub,
                reqStub,
                resStub,
                nextStub
            )
        ).to.be.rejected
    })
    it('should resolve with false if no files', ()=> {
        return expect(
            sendEmailOrNext(
                readFileStub,
                configStub,
                createTransportStub,
                getUserEmailStub,
                renderStub,
                reqStubNoFiles,
                resStub,
                nextStub
            )
        ).to.become(false)
    })
})

I’ve left out all the stubs, save the new one that shows, if we have no files, it just bypasses the entire thing, calls next with no value signaling to connect we’re good to go and finished, but still returning a useful value of false to say we didn’t do what we’re supposed to since we couldn’t find any files.

There And Back Again

Oh look, coverage found yet another noop, imagine that.

const logPort = port => console.log(`Example app listening on port ${port}!`) || true

And the 1 test:

describe('logPort when called', ()=> {
    it('should be true with a port of 222', ()=> {
        expect(logPort(222)).to.equal(true)
    })
})

Should You Unit Test Your Logger!?

If you really want to create a mock/spy for console.log, I admire your tenacity, Haskell awaits you with open arms in your future. Remember me when you’re at the top and you’ve bested Mr. Popo on the Lookout.

… however, if you’re not using console.log, and instead using a known Node logger like Pino, well, heh, you SHOULD!

I should point out some well known Clojure guys think I’m going overboard:

If you read the Twitter thread, an Elm guy schools me, and the Haskell cats show me how even there you can trick Haskell, but still acknowledge (kind of?) the purity pain.

Conclusions

Running coverage, we get:

Welcome to hunneds country. Congratulations on making this far, and not one import of sinon to be found. Don’t worry, deadlines and noops are all over the place in the JavaScript world, and sinon’s mock creation ability is not something to be shunned, but embraced as a helpful addition to your toolset. Like all technical debt, create it intentionally with notes about why, what to remove, context around creating it, etc in code comments around it.

Hopefully you’ve seen how creating small, pure functions, makes unit testing with small stubs a lot easier, faster, and leads to more predictable code. You’ve seen how you can use Functional Programming best practices, yet still co-exist with noops in imperative code, and classes and scope in OOP.

I should also point out that writing imperative or OOP code like this is a great way to learn how to write FP. Sometimes our brains are wired to flesh out ideas in those styles, and that’s great. Whatever works to get the ideas down. On the front-end, using vanilla React’s classes vs. recompose… or even just components functions only. Functional Programming will still hurt just as much as Imperative or OOP if you’ve got a not-so-figured out idea on how some problems should be solved and structured. Write it so it feels comfortable, the refactor & test to purity.

You’ve seen how to compose these functions together synchronously via operands like && and ||, using flow/compose. You’ve also seen how to compose them in Promise chains and Promise.all, curried or not.

You’ve also seen how 100% unit test coverage in a FP code base still has bugs that are only surfaced with concrete implementations using integration testing, such as with Mountebank.

Node is often used for API’s that have little to no state and are just orchestration layers for a variety of XML SOAP, JSON, and text. The no mutable state of Functional Programming works nicely with that concept in ensuring those no state to debug.

Conversely, if you’re dealing with a lot of state such as database connections and streaming text files, not only can you see how you can test such challenging areas using pure functions, but also how many of those things can be run at the same time to speed things up with stepping on each other through global variables.

Props to Cliff Meyers for teaching me what Mountebank is.

Code & Help

The Code is on Github. Got any questions, hit me up on YouTube, Twitter, Facebook (I’m Jesse Warden), or drop me an email.

Functional Programming Unit Testing in Node – Part 5

JesterXL — Fri, 22 Jun 2018 16:28:48 +0000

Noops, Stub Soup, and Mountebank

Welcome to Part 5 where we cover more about noops with a utility to test them, the “stub soup” that can happen if you don’t create small pure functions, and how we can utilize stubs instead of mocks to unit test larger functions. The most important part, though, is setting up Mountebank to show how integration tests can show problems in your unit tests despite 100% coverage. We use wrapping class instances as an example to show you the pitfalls Object Oriented Programming code can make for you.

This is a 6 part series on refactoring imperative code in Node to a functional programming style with unit tests. You are currently on Part 5.

The Final Battle?

At this point, we’ve shrunk our Express route as much as we’re going to without some serious refactoring. Let’s unit test it using (read copy pasta) all the stubs we’ve already made.

Noops

Before we proceed, let’s explain what a noop is. Pronounced “no awp”, it’s slang for “no operation”. It means a function that doesn’t return a value so it apparently has no effect because we have no proof it did any operation. That isn’t true; we all live and die by console.log which always returns undefined. If you run in ECS, all those console.log calls are putting text in standard out and you’re probably collecting all those logs for into ELK or CloudWatch or Splunk. That’s certainly an “operation with noticeable effect”. Functional Programmers call that a “side effect” of the function.

Often you’ll stub them in unit tests like () => undefined or the less clear, but shorter () => {}. Save yourself some typeing and use Lodash’ noop, Ramda always if you’re a Ramda purist or noop in Ramda Adjunct.

My God, It’s Full Of Stubs

Here’s the unit test with stubs needed above it for sendEmail t3h lelz:

describe('sendEmail when called', ()=> {
    const readFileStub = (path, encoding, callback) => callback(undefined, 'email')
    const configStub = { has: stubTrue, get: () => 'email service' }
    const createTransportStub = () => ({
        sendEmail: (options, callback) => callback(undefined, 'info')
    })
    const getUserEmailStub = () => 'email'
    const renderStub = stubTrue
    const reqStub = {
        cookie: { sessionID: '1' },
        files: [{scan: 'clean', originalname: 'so fresh', path: '/o/m/g'}]
    }
    const resStub = {}
    const nextStub = noop
    it('should work with good stubs', ()=> {
        return expect(
            sendEmail(
                readFileStub,
                configStub,
                createTransportStub,
                getUserEmailStub,
                renderStub,
                reqStub,
                resStub,
                nextStub
            )
        ).to.be.fulfilled
    })
})

A successful test, but the stubs, while succinct, almost outnumber the lines of code for the test. As you can see, Functional Programming, even when attempted with best effort, doesn’t necessarily “solve” your unit tests having to create a lot of “test code”. Mocks often get a bad rap for being verbose and hard to maintain. Stubs I believe are included in this, but at least with stubs they’re smaller, easier, and “mostly pure”. Still, as soon as you refactor your implementation, you’ll have to fix your tests, and sometimes your stubs will have to change too.

Trust me, this is much more preferable than to refactoring mocks.

The best thing to do is remember your training of the basics, like DRY: don’t repeat yourself, and keep your tests organized with commonly used good and bad stubs within reach (meaning you don’t have to scroll too far to read them). Like OOP, FP functions should be short and focused to be re-usable, and most importantly, composeable. It’s hard and gets easier with practice. A fully fleshed out idea of the problem you’re trying to solve helps a lot, don’t be afraid to prototype in imperative code.

sendEmail Unit Tests

Let’s add the failing which is easy because basically any stub could fail and the whole function fails:

it('should fail when reading files fails', ()=> {
    return expect(
        sendEmail(
            readFileStubBad,
            configStub,
            createTransportStub,
            getUserEmailStub,
            renderStub,
            reqStub,
            resStub,
            nextStub
        )
    ).to.be.rejected
})

And the most important, what sendEmail eventually resolves to. Yes, returning a Promise every time is important, but let’s ensure it resolves to something:

it('should resolve to an email sent', ()=> {
    return sendEmail(
        readFileStub,
        configStub,
        createTransportStub,
        getUserEmailStub,
        renderStub,
        reqStub,
        resStub,
        nextStub
    )
    .then(result => {
        expect(result).to.equal('info')
    })
})

And coverage is now:

The feels.

Class Composition is Hard, Get You Some Integration Tests

Sadly, this is where Functional Programming and Object Oriented Programming stop working together. Our code has a bug that you won’t find in unit tests, only integration tests. In languages like JavaScript, Python, and Lua, when you call functions on Classes without the class attached, they’ll often lose scope (this or self will be undefined/nil). Eric Elliot breaks down the details of a lot of these cases in his article Why Composition is Harder With Classes.

Integration tests using Supertest or Mountebank help with different levels of integration tests. We’ll use Mountebank in this article. Suffice to say your unit tests are only as good as the stubs you provide. The stubs you provide basically fake or emulate functionality of the dependencies and are as small and simple as possible. Stubs are different code than the concrete (real) implementations, and unless they capture it exactly, don’t always test the same. You’ll see an example of this below testing OOP code.

Pitfalls When Stubbing Class Methods

Notice none of our stubs use any classes or Object.prototype, and yet, this is exactly how nodemailer works. It all comes down to class instances losing their this scope. Let’s write a basic pure wrapper around nodemailer, unit test it, show it pass, then setup Mountebank so we can show it breaks at runtime when you use the real nodemailer vs. stubs. Given Mountebank is a large topic, I won’t cover too much how it works, but the code is included. Just know it’ll listen on the email port, act like an email server, and send real email responses so nodemailer believes it truly is sending an email.

Let’s create a sandbox.js file to play and a sandbox.test.js in the tests folder.

const nodemailer = require('nodemailer')

const sendEmailSafe = (createTransport, mailOptions, options) =>
    new Promise((success, failure) => {
        const { sendMail } = createTransport({mailOptions})
        sendMail(options, (err, info) =>
            err
            ? failure(err)
            : success(info))
    })

module.exports = sendEmailSafe

And the unit test:

...
describe.only('sendEmailSafe when called', ()=> {
    it('should work with good stubs', () => {
        const createTransportStub = () => ({
            sendMail: (options, callback) => callback(undefined, 'email sent')
        })
        return sendEmailSafe(createTransportStub, {}, {})
        .then(result => {
            expect(result).to.equal('email sent')
        })
    })
})
...

Integration Test

So it passes. Let’s try with the integration test that uses a real nodemailer instance vs. our unit test stubs. I’ve setup mountebank to listen on port 2626 at localhost for emails. If someone sends an email with the from address equaling “jesterxl@jessewarden.com”, it’ll respond with an “ok the email was sent, my man”. Before we automate this, let’s do it manually first.

Setting Up Mountebank

Run npm i mountebank --save-dev first, then once it is complete, open your package.json and add this script:

"scripts": {
    ...
    "mb": "npx mb"
  },
...

Now when you run npm run mb, it’ll run Mountebank. It’ll basically start a Node server on port 2525. As long as it’s running, you can send it JSON to add imposters (mocks for running services).

Setting Up Your Imposters

An imposter is basically a mock or stub for services. Typically mocks and stubs are used for unit tests and are created in code. In Mountebank, however, you create one by sending Mountebank REST calls. For example a POST call, typically on localhost:2525. You send it JSON describing what port it’s supposed to listen on, what other things to look for, and what JSON & headers to respond with. Mountebank will then spawn a service on that port listening for incoming connections. If the request has attributes it recognizes (you do a GET on port 9001 with a path of /api/health, you send an email on port 2626 from ‘cow@moo.com’, etc), it’ll respond with whatever stub you tell it too. For example, some hardcoded JSON with an HTTP 200 status code. While stubs typically respond immediately or with Promises, these respond as a REST response.

Check out the import top part of our setupMountebank.js that I’ve placed in the “test-integration” folder:

...
const addNodemailerImposter = () =>
    new Promise((success, failure)=>
        request({
            uri: 'http://localhost:2525/imposters',
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Accept': 'application/json'
            },
            body: JSON.stringify({
                protocol: 'smtp',
                port: 2626,
                stubs: [{
                    predicates: [
                        {
                            contains: {
                                from: 'jesterxl@jessewarden.com'
                            }
                        }
                    ]
                }]
            })
        },
    ...

As you can see, a simple POST request to tell Mountebank, “Yo, if any dude sends an email on port 2626 and it is from me, respond it worked”. Typically Mountebank wants to define that response in the stubs Array, but for emails, you can leave it blank and it’ll default to a success response. At the time of this writing, there is no way to make an email fail, only REST calls. As long as Mountebank is running, it’ll remember to do this unless you delete it, or close Mountebank.

Now, to play around, I’ve run it manually to register. Check the bottom code:

if (require.main === module) {
    Promise.all([
        addNodemailerImposter()
    ])
    .then(() => console.log('Mountebank Imposters initialized successfully.'))
    .catch(error => console.error('Mountebank Imposters failed:', error))
}

Open a new terminal, and run node test-integration/setupMountebank.js, and you should see the Mountebank terminal light up:

> npx mb

info: [mb:2525] mountebank v1.14.1 now taking orders - point your browser to http://localhost:2525 for help
info: [mb:2525] POST /imposters
info: [smtp:2626] Open for business...

That “Open for business…” line is key; that means Mountebank understood what you want and worked and you can now send emails to port 2626. Let’s do that.

Sending the Email

Open up sandbox.js and check the code that’ll run if we use Node to run it:

if (require.main === module) {
    sendEmailSafe(
        nodemailer.createTransport,
        {
            host: 'localhost',
            port: 2626,
            secure: false
        },
        {
            from: 'jesterxl@jessewarden.com',
            to: 'jesterxl@jessewarden.com',
            subject: 'what you hear, what you hear is not a test',
            body: 'Dat Body Rock'
        }
    )
    .then(result => {
        console.log("result:", result)
    })
    .catch(error => {
        console.log("error:", error)
    })
}

Swing and a Miss

Rad, now try to send an email via node src/sandbox.js:

error: TypeError: Cannot read property 'getSocket' of undefined
    at sendMail (/Users/jessewarden/Documents/_Projects/fp-node/node_modules/nodemailer/lib/mailer/index.js:143:25)
...

Whoa, wat? Let’s go into Nodemailer’s sourcecode and see what the heck is going on:

/* node_modules/nodemailer/lib/mailer/index.js line 134 */
sendMail(data, callback) {
    ...
        /* broken below this comment */
    if (typeof this.getSocket === 'function') {
        this.transporter.getSocket = this.getSocket;
        this.getSocket = false;
    }
...

It’s doing a type check to see if this.getSocket is a function vs. a Boolean. That’s fine, but they should of check for this being undefined first.

Or should they? Once you’re in class world, and you’ve been doing OOP for awhile, you shouldn’t have to check for this; it’s just a normal part of how classes work. If it doesn’t, something more fundamental is messed up, the most common being forgetting to setup bind in the constructor for callbacks for example.

We’re not going to fix Nodemailer to make it more friendly to FP developers. In fact, this is a common trend in that many libraries you use both in Node and in the Browser (i.e. from node_modules) will be written in all sorts of ways. You need to be accommodating.

Instead, we’ll assume that we’re not allowed to call sendEmail alone, and ensure it’s always something.sendEmail; whatever to the left is the instance, and will retain scope if you call it like that. This is why a lot of my examples you’ll see I’ll make fs the dependency and then call fs.readFile vs. just readFile.

FP-Fu

Let’s first fix our implementation to be OOP friendly, and ensure the tests still work, else fix ’em. The old code:

const { sendEmail } = createTransport({mailOptions})
        sendMail(options, (err, info) =>

The new code:

const transport = createTransport({mailOptions})
        transport.sendMail(options, (err, info) =>

Re-run the tests:

Cool, the original public interface still works and hides the OOPy stuff. Let’s test the integration test now with sending a real email with real, concrete implementation vs. stubs:

result: { accepted: [ 'jesterxl@jessewarden.com' ],
  rejected: [],
  envelopeTime: 3,
  messageTime: 3,
  messageSize: 590,
  response: '250 2.0.0 Ok: queued as f19f95e62da4afeade02',
  envelope:
   { from: 'jesterxl@jessewarden.com',
     to: [ 'jesterxl@jessewarden.com' ] },
  messageId: '' }

I was like Whee!!! Let’s fix our original implementation now that we’ve proven we know how to wrangle OOP with FP now. We’ll change:

...
sendEmailSafe(
  createTransport(
    createTransportObject(emailService.host, emailBody.port)
  ).sendEmail,
...

To:

...
sendEmailSafe(
  createTransport(
    createTransportObject(emailService.host, emailBody.port)
  ),
...

And switch sendEmailSafe:

const sendEmailSafe = curry((sendEmailFunction, mailOptions) =>
  new Promise((success, failure) =>
    sendEmailFunction(mailOptions, (err, info) =>
      err
      ? failure(err)
      : success(info)
    )
  )
)

To the new OOP-friendly version:

const sendEmailSafe = curry((transport, mailOptions) =>
  new Promise((success, failure) =>
    transport.sendEmail(mailOptions, (err, info) =>
      err
      ? failure(err)
      : success(info)
    )
  )
)

This breaks 1 of the tests because the stub used to be a function; now it needs to be an Object with a function. However… we should be a little more honest and use a true class in the unit tests to be 100% sure. We’ll take the old 2 tests:

describe('sendEmailSafe when called', ()=> {
    const sendEmailStub = (options, callback) => callback(undefined, 'info')
    const sendEmailBadStub = (options, callback) => callback(new Error('dat boom'))
    it('should work with good stubs', ()=> {
        return expect(sendEmailSafe(sendEmailStub, {})).to.be.fulfilled
    })
    it('should fail with bad stubs', ()=> {
        return expect(sendEmailSafe(sendEmailBadStub, {})).to.be.rejected
    })
})

And change ’em to:

describe('sendEmailSafe when called', ()=> {
    class TransportStub {
        constructor(mailOptions) {
            this.mailOptions = mailOptions
        }
        sendEmail(options, callback) {
            callback(undefined, 'info')
        }
    }
    class TransportStubBad {
        constructor(mailOptions) {
            this.mailOptions = mailOptions
        }
        sendEmail(options, callback) {
            callback(new Error('dat boom'))
        }
    }
    it('should work with good stubs', ()=> {
        return expect(sendEmailSafe(new TransportStub({}), {})).to.be.fulfilled
    })
    it('should fail with bad stubs', ()=> {
        return expect(sendEmailSafe(new TransportStubBad({}), {})).to.be.rejected
    })
})

Notice once you go OOP, things get more verbose. Bleh.

Functional Programming Unit Testing in Node – Part 4

JesterXL — Fri, 22 Jun 2018 16:28:18 +0000

Concurrency, Compose, and Coverage

Welcome to Part 4 where we show how to do concurrency which is a lot easier to get “for free” using pure functions, we compose both async and synchronous functions, we and utilize a test coverage report to where next to focus our refactoring and testing efforts.

This is a 6 part series on refactoring imperative code in Node to a functional programming style with unit tests. You are currently on Part 4.

Compose Again

Assuming getUserEmail succeeded, we’ll have the user’s information so we can send an email. We now need to read the text email template to inject that information into. We’ll compose that readFile function we wrote. The existing code is imperatively inside the getUserEmail‘s then:

...
userModule.getUserEmail(get('cookie.sessionID', req))
    .then(value => {
        fs.readFile('./templates/email.html', 'utf-8', (err, template) => {
            if (err) {
                console.log(err)
                    err.message = 'Cannot read email template'
                    err.httpStatusCode = 500
                    return next(err)
            }
...

Let’s fix that and compose them together #connectDemTrainTrax:

...
userModule.getUserEmail(get('cookie.sessionID', req))
.then(userInfo => readEmailTemplate(fs)))
.then(template => ...)
...

Great! We even removed all the error handling as that’s built into our pure readEmailTemplate function.

Parallelism, Not Concurrency (Who Cares)

However, that’s one new problem; we need userInfo later on once we’ve gotten all the email info setup and ready. Since it’s only in scope for this function it’s now gone. One of JavaScript’s most powerful and taken for granted features, closures, we just threw out the window to remain “pure” for purity’s sake.

We can fix it, though, with one of JavaScript’s other features: non-blocking I/O. We can return 3 Promises and wait for all 3 to complete, and use all 3 values in the same function. It doesn’t matter if one takes longer than the others; Promise.all will wait for all 3 to be done, then give us an Array with all 3 values in order. If even 1 has an error, it’ll just pop out the .catch. This has 2 bad problems, but we’ll tackle that in another article. This also has the benefit of being faster in that we don’t have to wait for each in line, they all happen “at the same time Node style” which is not the same as “happening at the same time Elixir/Erlang or Go style” but that’s ok, we can get into the same dance club.

For now, we’ll refactor to:

...
Promise.all([
      getUserEmail(get('cookie.sessionID', req)),
      readEmailTemplate(readFile),
      mapFilesToAttachments(filterCleanFiles(get('files', req)))
    ])
    .then( ([userEmailAddress, emailTemplate, fileAttachments]) => ...)
...

Now we’re talking. Loading from an external web service, reading from a local file, and a synchronous function call all can happen “at the same time”, and we don’t have to worry about how long each one takes. We use Array Destructuring to get our arguments out. Note they come in the same order we put the functions into the Promise.all.

We now have our user’s email address, the text template to inject information into, along with the file attachments used for both in the same function scope.

Synchronous Compose

One thing to nitpick. Sometimes you refactor FP code for readability purposes, not just for the mathematical purity reasons. In this case, check out the 3 levels of nesting:

mapFilesToAttachments(filterCleanFiles(get('files', req)))

In imperative code, if you see if/then statements nested more than 2 levels deep, that tends raise concern. Developers are sometimes fine with creating that code to ensure they truly understand the different cases in playing with ideas, but once complete, they don’t like LEAVING it that way. Nested if statements are hard to read and follow. If you DO follow them, you can sometimes get a rush or high in “figuring it out”. That’s not the goal, though; nested if’s are considered bad practice.

For FP, deeply nested functions like this have the same problem. It’s compounded by the fact we attempted to use verbose names for the functions to make what they do more clear vs. short names. This ends up making the problem worse.

For Promises, it’s not so bad; you just shove them in the .then. But what about synchronous code?

You have 2 options:

Simply wrap in them in a Promise; most promises except for a couple of edge cases are fine getting a return value of a Promise or a value as long as the value isn’t an Error.
Use Lodash’ flow function, or Ramda’s compose.
Use the pipeline operator.

Sadly, at the time of this writing, the pipeline operator is only at Stage 1 for JavaScript, meaning it’s not even considered a possibility for inclusion in the ECMA Standard yet. None of this code is asynchronous so we’ll use the Lodash flow (I like Ramda’s compose name better).

Let’s put the functions in order, just like we would with a Promise chain:

const filterCleanFilesAndMapToAttachments = flow([
  get('files'),
  filterCleanFiles,
  mapFilesToAttachments
])

Note the use of get('files'). The get function takes 2 arguments, but we only supply 1. We know it’s curried by default, meaning it’ll be a partial application if we just say get('files'); it’s waiting for the 2nd argument. Once it gets that, it’ll search for the ‘files’ property on it, else give undefined. If it DOES find undefined, filterCleanFiles will just spit out an empty Array, and mapFilesToAttachments will spit out an empty Array when you give it an empty Array. Otherwise, they’ll get the good Array full of files, and both of those functions will do their thang.

See how we use curried functions that create partial applications to help compose other functions? I know… for you guys, not a good pickup line, but you never know, she me might be a Data Scientist who digs Scala. Or she’s lit and you look good and anything you say doesn’t really matter at that point. Either way, it’s alllll good.

Now to use that composed function, we take what we had:

Promise.all([
  getUserEmail(get('cookie.sessionID', req)),
  readEmailTemplate(readFile),
  mapFilesToAttachments(filterCleanFiles(get('files', req)))
])

And replace it with our composed function:

Promise.all([
  getUserEmail(get('cookie.sessionID', req)),
  readEmailTemplate(readFile),
  filterCleanFilesAndMapToAttachments(req)
])

Much better eh? Speaking of lit, I’m feeling that hard root beer right now, but I STILL remember we need to unit test our composed function. Let’s do that… and with confidence because we already have 3 unit tested pure functions, and we composed them together with a Lodash pure function. DAT CONFIDENCE BUILDING! Also, you MAY have to install config and nodemailer: npm i config nodemailer and then require them up top. Also, depending on the order of functions, you may have to move some functions around giving while we’re creating pure functions, they’re defined IN an imperative way, and so order matters. i.e. you have to create the const app = express() first before you can app.post.

describe('filterCleanFilesAndMapToAttachments when called', ()=> {
    it('should give an attachment from a request with clean file', ()=>{
        const reqStub = {files: [{scan: 'clean', originalname: 'so fresh', path: '/o/m/g'}]}
        const result = filterCleanFilesAndMapToAttachments(reqStub)
        expect(result[0].filename).to.equal('so fresh')
    })
    it('should give an empty Array with no files', ()=>{
        const reqStub = {files: [{scan: 'dirty south', originalname: 'so fresh', path: '/o/m/g'}]}
        const result = filterCleanFilesAndMapToAttachments(reqStub)
        expect(result).to.be.empty
    })
    it('should give an empty Array with undefined', ()=>{
        const result = filterCleanFilesAndMapToAttachments(undefined)
        expect(result).to.be.empty
    })
})

:: chink chunk :: NIIIIICCCE!

Composing the Promise Way

You can also just compose the Promise way, and they’ll work for Promise based functions as well as synchronous ones allowing you to use interchangeably. Let’s first delete all the no-longer-needed imperative code:

let attachments = []
files.map(file => {
  if (file.scan === 'clean') {
    attachments.push({ filename: file.originalname, path: file.path })
  }
})

value.attachments = attachments
req.attachments = attachments

And we’ll take the remaining mix of synchronous and imperative code, and one by one wire together:

let emailBody = Mustache.render(template, value)
let emailService = config.get('emailService')
const transporter = nodemailer.createTransport({
  host: emailService.host,
  port: emailService.port,
  secure: false,
})

const mailOptions = {
  from: emailService.from,
  to: emailService.to,
  subject: emailService.subject,
  html: emailBody,
  attachments: attachments,
}

transporter.sendMail(mailOptions, (err, info) => {
  if (err) {
    err.message = 'Email service unavailable'
    err.httpStatusCode = 500
    return next(err)
  } else {
    return next()
  }
})

You hopefully are getting trained at this point to start noticing “globals in my function”. Note our current line of code is:

let emailBody = Mustache.render(template, value)

But nowhere in the function arguments do we pass the render function to use. Let’s quickly modify the ever-growing Express route function signature from:

const sendEmail = curry((readFile, config, createTransport, getUserEmail, req, res, next) =>

to:

const sendEmail = curry((readFile, config, createTransport, getUserEmail, render, req, res, next) =>

We’re already in a Promise at this point, so we can return a value here, or a Promise and we’ll be sure we can add another .then if we need to. One trick VSCode, a free text and code editor by Microsoft, has is highlighting variables. Before we shove this rendered email template variable in the Monad train, let’s see if anyone down the tracks needs it. We’ll select the whole variable, and watch how VSCode will highlight usage of it as well:

Crud… it’s a ways down, AND it’s mixed in with this emailService thing. Let’s highlight him and see where he’s grouped:

This’ll be tricky. Good news, rendering the email and loading the email service configuration can be done at the same time. Let’s keep that INSIDE the Promise now until we feel comfortable we no longer need the userEmailAddress, emailTemplate, fileAttachments in scope. A lot more pragmatic people would be fine with keeping the code this way, and using JavaScript’s built in feature of closures, and move on with life. However, imperative code is harder to test, and results in LONGER code vs. smaller, pure functions that are easier to test. You don’t always START there, though. It’s fine to write imperative, then write “kind of pure” and keep refactoring your way there. That’s part of learning, figuring our the idea of how your code should work, or both.

...
.then( ([userEmailAddress, emailTemplate, fileAttachments]) => {
    return Promise.all([
      render(render, template, userEmailAddress),
      getEmailService(config)
    ])
    .then( ([emailBody, emailService]) => ...
...

And we’ll clean up the code below to use our pure functions first imperatively:

...
.then( ([emailBody, emailService]) => {
  const transportObject = createTransportObject(emailService.host, emailBody.port)
  const transport = createTransport(transportObject)
  const sendEmailFunction = transport.sendEmail
  const mailOptions = createMailOptions(
    emailService.from,
    emailService.to,
    emailService.subject,
    emailBody,
    fileAttachments
  )
  return sendEmailSafe(sendEmailFunction, mailOptions)
})

… and then refactor to more functional:

...
.then( ([emailBody, emailService]) =>
  sendEmailSafe(
    createTransport(
      createTransportObject(emailService.host, emailBody.port)
    ).sendEmail,
    createMailOptions(
      emailService.from,
      emailService.to,
      emailService.subject,
      emailBody,
      fileAttachments
    )
  )
})
...

Note the fileAttachments comes from the scope higher up. The sendEmailSafe function requires a nodemailer transport. We create that from our function that creates the Object from the emailService. Once created we need that sendEmail function to pass it to the sendEmailSafe so we just immediately go .sendEmail in the first parameter. The createMailOptions is another function that simply creates our Object from the emailService object, the rendered via Mustache emailBody, and the virus scanned fileAttachements. One last touch is to remove the squiggly braces {} as we’re no longer writing imperative code, and the return statement as Arrow functions have an implicit return when you remove the squiggly braces.

This last part is left over from the callback:

), reason => {
      return next(reason)
    })

Typically you defer Promise error handling higher up the call stack; meaning, “let whoever is calling me deal with error handling since Promises that call Promises have their errors propagate up”. That’s fine, so… we’ll delete it.

After all that refactoring, here’s what we’re left with:

const sendEmail = curry((readFile, config, createTransport, getUserEmail, render, req, res, next) =>
    Promise.all([
      getUserEmail(get('cookie.sessionID', req)),
      readEmailTemplate(readFile),
      filterCleanFilesAndMapToAttachments(req)
    ])
    .then( ([userEmailAddress, emailTemplate, fileAttachments]) => 
      Promise.all([
          render(render, template, userEmailAddress),
          getEmailService(config)
        ])
        .then( ([emailBody, emailService]) =>
          sendEmailSafe(
            createTransport(
              createTransportObject(emailService.host, emailBody.port)
            ).sendEmail,
            createMailOptions(
              emailService.from,
              emailService.to,
              emailService.subject,
              emailBody,
              fileAttachments
            )
          )
        )
    ))

Coverage Report

Let’s unit test it; it’ll be hard because we have a lot of stubs, but we can borrow from the ones we’ve already created in the other tests. I’m not going to DRY the code at all in the tests as that would require too much brainpower at this point, but when you get an Agile Sprint or time to pay down technical debt, this is one of the stories/tasks you add to that list.

… before we do, let’s run a coverage report to see how much work we have cut out for us (we’re ignoring my fake npm module and the user stuff for now). Run npm run coverage && open coverage/lcov-report/index.html:

And the details around our particular function:

Status Quo at This Point

Wonderful; the only thing we need to test is the composition of those functions in Promise.all. Rather than create 20 billion stubs, and ensure they’re setup “just so” so the sendEmail unit test passes or fails, we’ll continue to our strategy of pulling out teency pieces, wrapping them in pure functions, testing those, repeat. Let’s start with the first Promise.all:

const getSessionIDFromRequest = get('cookie.sessionID')
const getEmailTemplateAndAttachments = curry((getUserEmail, readFile, req) =>
  Promise.all([
    getUserEmail(getSessionIDFromRequest(req)),
    readEmailTemplate(readFile),
    filterCleanFilesAndMapToAttachments(req)
  ]))

Then we’ll unit test the getEmailTemplateAndAttachments (he’ll end up ensuring we’ve tested the new getSessionIDFromRequest):

describe('getEmailTemplateAndAttachments when called', ()=> {
    const reqStub = {
        cookie: { sessionID: '1' },
        files: [{scan: 'clean', originalname: 'so fresh', path: '/o/m/g'}]
    }
    const getUserEmailStub = () => 'email'
    const readFileStub = (path, encoding, callback) => callback(undefined, 'email')
    const readFileStubBad = (path, encoding, callback) => callback(new Error('b00mz'))
    it('should succeed with good stubs', ()=> {
        return expect(
            getEmailTemplateAndAttachments(getUserEmailStub, readFileStub, reqStub)
        ).to.be.fulfilled
    })
    it('should succeed resolve to having an email', ()=> {
        return getEmailTemplateAndAttachments(getUserEmailStub, readFileStub, reqStub)
        .then( ([userEmail, emailBody, attachments]) => {
            expect(userEmail).to.equal('email')
        })
    })
    it('should fail if reading file fails', ()=> {
        return expect(
            getEmailTemplateAndAttachments(getUserEmailStub, readFileStubBad, reqStub)
        ).to.be.rejected
    })
})

And we’ll then swap it out for the raw Promise.all:

const sendEmail = curry((readFile, config, createTransport, getUserEmail, render, req, res, next) =>
    getEmailTemplateAndAttachments(getUserEmail, readFile, req)
    .then( ([userEmailAddress, emailTemplate, fileAttachments]) => 
      Promise.all([
          render(render, template, userEmailAddress),
          getEmailService(config)
        ])
        .then( ([emailBody, emailService]) =>
          sendEmailSafe(
            createTransport(
              createTransportObject(emailService.host, emailBody.port)
            ).sendEmail,
            createMailOptions(
              emailService.from,
              emailService.to,
              emailService.subject,
              emailBody,
              fileAttachments
            )
          )
        )
    ))

… and then re-run coverage. Just run npm run coverage and you can refresh the coverage in the browser:

As you can see, coverage isn’t going to let us off that easy. That’s ok, we can re-use these stubs for the final battle. Let’s do the last Promise.all.

describe('renderEmailAndGetEmailService when called', ()=> {
    const configStub = { has: stubTrue, get: () => 'email service' }
    const renderStub = stubTrue
    const renderStubBad = () => { throw new Error('intentionally failed render')}
    it('should work with good stubs', ()=> {
        return expect(
            renderEmailAndGetEmailService(configStub, renderStub, 'template', 'user email')
        ).to.be.fulfilled
    })
    it('should resolve to an email', ()=> {
        return renderEmailAndGetEmailService(configStub, renderStub, 'template', 'user email')
        .then( ([emailRendered, emailService]) => {
            expect(emailRendered).to.equal(true)
        })
    })
    it('should fail if rendering fails', ()=> {
        return expect(
            renderEmailAndGetEmailService(configStub, renderStubBad, 'template', 'user email')
        ).to.be.rejected
    })
})

And swap it out:

const sendEmail = curry((readFile, config, createTransport, getUserEmail, render, req, res, next) =>
    getEmailTemplateAndAttachments(getUserEmail, readFile, req)
    .then( ([userEmailAddress, emailTemplate, fileAttachments]) => 
      renderEmailAndGetEmailService(config, render, emailTemplate, userEmailAddress)
      .then( ([emailBody, emailService]) =>
        sendEmailSafe(
          createTransport(
            createTransportObject(emailService.host, emailBody.port)
          ).sendEmail,
          createMailOptions(
            emailService.from,
            emailService.to,
            emailService.subject,
            emailBody,
            fileAttachments
          )
        )
      )
    ))

programming – Software, Fitness, and Gaming – Jesse Warden

React Redux Thunk vs Elm

Introduction

What is React, Redux, Thunk, and Elm?

Building and Compiling React

Building and Compiling Elm

HTML in React

HTML in Elm

Working With CSS in React

Working with CSS in Elm

Coding in React

Prop Types

Flow or TypeScript

Coding in Elm

Side Effects in JavaScript

Side Effects in Elm

Closures in React

Closures in Elm

Errors in React

Errors in Elm

Redux in React

Reducers

Store

Action Creator

Many Types

Why Are We Using This?

Redux Thunk

Connecting Redux to React

Elm Architecture

Bugs in React

Swallowed Errors via Misspellings

Null Pointers Because of the Lack of Types

Missing Case Statements

Logic Error: Off By 1

Errors in Elm

Null Pointers

Maybe

Error Type

Logic Errors

Conclusions

React, JavaScript, Redux, and Thunks

Elm

Advent of Code 2018 in Elm Review

Introduction

Why Elm?

Overall Challenges With Elm

Out of Practice with Types

No Loops, Only Recursion

Syntax Whitespace

Verbose Anonymous Functions

Approaching Full Lisp with Tons of Parenthesis

Tooling Coloring

Modern Web Compilation Toolchain

Type Hinting is “Ok”

Concurrency

Day 1 – 6 Review

Day 1: Frequency Parser

Day 2: Checksum Parser

Day 3: Claims Parser

Day 4: Sleep Schedule

Day 5: Polymer Parser

Day 6: Coordinates Finder

Conclusions

Functional Programming Unit Testing in Node – Part 6

Next, Logging, and Conclusions

Contents

Next is Next

Ors (Yes, Tales of Legendia was bad)

Pass Through

Mopping Up

sendEmail … or not

There And Back Again

Should You Unit Test Your Logger!?

Conclusions

Code & Help

Functional Programming Unit Testing in Node – Part 5

Noops, Stub Soup, and Mountebank

Contents

The Final Battle?

Noops