react – 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

Easier Asynchronous State Modelling in React Redux or Hooks

JesterXL — Sun, 17 Feb 2019 19:52:28 +0000

Introduction

Modelling state for asynchronous actions in React using Redux via thunks or sagas is verbose. It requires a lot of code. It also is easy to accidentally miss flipping one of the values and result in a wrong state that your UI then shows the wrong thing. Thankfully there are ways to use Algebraic Data Types to model this state that results in less code in your reducers, whether in Redux or Hooks’ useReducer, as well as in your components. Below we’ll show the 3 problems modelling using Objects can cause and how to solve them using ADT’s.

All code shown below is on Github. The masterbranch has the Object way of modelling, and the types branch has the ADT solutions.

Most of the post below is based on prior art from Making Impossible States Impossible by Richard Feldman, and Solving the Boolean Identity Crisis by Jeremy Fairbank. Like Redux, stolen from Elm.

Defining The Problem

When you load data from a remote data source, most likely from a REST based HTTP server, you’ll have 3 states: loading, error, and success. This means loading the data, the data failed to load because of an error, and the data successfully loaded.

Loading State

Loading state

Error State

Error state

Success State

Success state.

To slowly model the above into a finite state machine, you start with loading state in your reducer so your component knows “if loading, show the loading state, else don’t”. You default it to trueso your UI will be assumed to be waiting to load data.

const initialState = {
  isLoading: true
}

When the data loads, you can set the isLoadingto false and put your data on the Object:

const initialState = {
  isLoading: false
  , foods: [...]
}

However, for errors, you need to indicate that it IS an error, so you add another Boolean:

const initialState = {
  isLoading: false
  , foods: undefined
  , isError: true
}

For logging and for the UI, you need to show this Error so you then add it as well:

const initialState = {
  isLoading: false
  , foods: undefined
  , isError: true
  , error: new Error('b00m b00m ')
}

Problem #1: Lots of Verbose, Duplicate Code

Every single asynchronous action in your application has about the same 3 states and 4 properties in an Object to represent it. You then go to represent it in a basic reducer function. When using Redux or useReducer, you use reducer functions, which is the name for the function you put in a reducefunction, like Array.prototype.reduce or Lodash’ reduce. Below, “foods” is our reducer function:

const foods = (state=defaultState, action) => {
  switch(action.type) {
    case LOAD_FOODS:
      return {
        ...state
        , isLoading: true
      }
    case LOAD_FOODS_FAILURE:
      return {
        ...state
        , isLoading: false
        , isError: true
        , error: action.error
      }
    case LOAD_FOODS_SUCCESS:
      return {
        ...state
        , isLoading: false
        , foods: action.foods
  }
}

However, either through TDD, manual testing, or unit tests, you start to find out basic problems with your reducer function, and state machines in general: the transitions between states can lead to impossible states… and your UI freaks out… or doesn’t and hides the weirdness.

If we go from loading to error, that’s fine, our state is:

const state = {
  isLoading: false
  , foods: undefined
  , isError: true
  , error: new Error(...)
}

Problem #2: Impossible States

But if we then retry, we’ll go from loading to success which results in:

const state = {
  isLoading: false
  , foods: [...]
  , isError: true
  , error: new Error(...)
}

Wat. How do we have foodsand an isError set to true!?

Problem #3: Incorrect and Unclear UI Behavior

You know something’s wrong when your UI shows an error even though the Network Panel in Chrome shows a status code 200 for the request and the JSON data all looks good:

const FoodsView = props => {
    useEffect(() => {
        props.loadFoodsThunk()
    }, [])

    if(props.foods.isLoading) {
        return (<Loading />)
    }
    // WHY IS IT STOPPING HERE FOR A SUCCESS!?!
    if(props.foods.isError) {
        return (<Failed error={props.foods.error}/>)
    }

    return (
        <FoodsList foods={props.foods.foods} calories={props.calories} addFood={props.addFood} removeFood={props.removeFood} />
    )
}

You realize you need to be super explicit about state transitions to ensure you don’t accidentally end up in an impossible state like the above where you have a success and error at the same time. We’ll make our reducer way more verbose to ensure all the unit tests pass:

const foods = (state=defaultState, action) => {
    switch(action.type) {
        case LOAD_FOODS:
            return {
                ...state
                , isLoading: true
                , isError: false
                , error: undefined
                , foods: undefined
            }
        case LOAD_FOODS_FAILURE:
            return {
                ...state
                , isLoading: false
                , isError: true
                , error: action.error
                , foods: undefined
            }
        case LOAD_FOODS_SUCCESS:
            return {
                ...state
                , isLoading: false
                , isError: false
                , error: undefined
                , foods: action.foods
            }
        default:
            return state
    }
}

While cool in that it’s the same pattern, it can be monotonous to duplicate this easily in each of your async reducers that need it without copy pasta. Worse, this is just 3 states. In some cases, especially in Enterprise applications where you’re dealing with legacy code or services that just go down a lot because of technical debt or high traffic, you could be in an “unstable” state, similar to the Circuit Breaker Pattern. That’s ok and expected, but you can start to see how your Object grows, and it’s not always so obvious what state transition bugs could occur, so you make your reducer even more verbose.

In an Object Oriented (OOP) code base, we’d just wrap this in a class with methods to ensure safe transitions. This abstraction makes it easier to read and we can test the class in isolation. That won’t help the UI part above, though.

So what do we do in a Functional Codebase?

Solving The Problems

To prevent the duplicated code, ensure you can’t reach impossible states in an FP way, and make your UI more clear and easier to debug, we’ll use an Algebraic Data Type, sometimes called a Tagged Union, provided by Folktale. There are other libraries you can use for this such as Crocs and Sanctuary. If you want to learn more, I have a video Fun With Folktale which covers the basics at 26:55.

First, npm install folktale or yarn add folktale and let’s import it:

import { union } from 'folktale/adt/union'

We have a default initial state that looks like:

const defaultState = {
    isLoading: true
    , error: undefined
    , isError: false
    , foods: undefined
}

Let’s model that same data structure with a type in Folktale:

const FoodsState = union('FoodsState', {
    LoadingFoods() { return {} }
    , FoodsLoaded(foods) { return { foods } }
    , FoodsError(error) { return { error } }
})

Instead of 4 un-related, yet related, properties, we can see our 3 states clearly:

LoadingFoods: loading the food data
FoodsLoaded: the list is loaded, and the Array is inside
FoodsError: the list failed to load, and the Error is inside

We can leave them in FoodsState, but let’s destructure them so it’s less to type:

const { LoadingFoods, FoodsLoaded, FoodsError } = FoodsState

Solving Problem #2: Many States is Now One State at a Time

Since there are 3 different Objects, we solve problem #2: You can only be in 1 state at a time. Let’s update our reducer’s function signature that has the defaultState:

const foods = (state=defaultState, action) => {

To show this:

const foods = (state=LoadingFoods(), action) => {

Way more clear than “defaultState” or “initialState”; it says exactly right there what state we’re starting in: Loading. Notice it can’t magically be FoodsLoaded or FoodsErrorat the same time like it could in our Object.

Solving Problem #1: Verbose Code is Now Less Code

Let’s take our massive reducer function switch statement:

switch(action.type) {
    case LOAD_FOODS:
        return {
            ...state
            , isLoading: true
            , isError: false
            , error: undefined
            , foods: undefined
        }
    case LOAD_FOODS_FAILURE:
        return {
            ...state
            , isLoading: false
            , isError: true
            , error: action.error
            , foods: undefined
        }
    case LOAD_FOODS_SUCCESS:
        return {
            ...state
            , isLoading: false
            , isError: false
            , error: undefined
            , foods: action.foods
        }
    default:
        return state
}

… and use our union types to write less code AND still ensure only 1 state at a time:

switch(action.type) {
    case LOAD_FOODS:
        return LoadingFoods()
    case LOAD_FOODS_FAILURE:
        return FoodsError(action.error)
    case LOAD_FOODS_SUCCESS:
        return FoodsLoaded(action.foods)
    default:
        return state
}

Who’s your buddy? WHO’S YOUR BUDDY!?

If the action.typeis loading, cool, we’re loading. If the type is failure, we return a failed type and put the error in side. Lastly, if we’re successful, we return a success with our data inside. 28 lines to 10.

Solving Problem #3: Unclear UI Showing Wrong State to More Clear, Deterministic, and Easier to Debug

Lastly, our UI can more clearly represent this state. Instead of the imperative, abort early and render based on our guess at what the Object means:

const FoodsView = props => {
    useEffect(() => {
        props.loadFoodsThunk()
    }, [])

    if(props.foods.isLoading) {
        return (<Loading />)
    }
    
    if(props.foods.isError) {
        return (<Failed error={props.foods.error}/>)
    }

    return (
        <FoodsList foods={props.foods.foods} calories={props.calories} addFood={props.addFood} removeFood={props.removeFood} />
    )
}

We can instead run a pure function against the type using matchWith:

const FoodsView = props => {
    useEffect(() => {
        props.loadFoodsThunk()
    }, [])

    return props.foods.matchWith({
        LoadingFoods: () =>
            (<Loading />)
        , FoodsError: ({ error }) =>
            (<Failed error={error} />)
        , FoodsLoaded: ({ foods }) =>
            (<FoodsList foods={foods} calories={props.calories} addFood={props.addFood} removeFood={props.removeFood} />)
    })
}

No need to inspect different Booleansand guess you did it in the right order, or have things break even if you did, you now have VERY clearly named states to match against using a pure function.

Conclusions

Modelling asynchronous data in Redux or the useReducer React Hook can result in states that are impossible, yet your UI goes there by accident. This results in verbose reducers that are a pain to maintain as the amount of fetch calls in your application grows. Unless you have good tests, it also will sometimes result in UI bugs if you accidentally don’t model a state just right with all the Boolean flags set to the correct values.

Using ADT’s, or tagged unions, we can ensure impossible states are impossible to get to, we can significantly reduce how much reducer code we write, and our UI render code becomes more clear, testable, and debuggable.

Et tu, Action Creators?

And before you ask, sadly no, you cannot use them for Action Creators. Redux and various Redux libraries expect Action Creators to be pure Objects, and the type property to a String. I suppose you could create your own middleware, thus drastically reducing your reducer size and they’d become map functions vs. reducer functions. But at that point, you’re better off using Elm, heh!

Can Strong Typing Help Here?

On that note, be aware that TypeScript and Flow, currently, cannot detect if you’ve handled all match cases. For example, if you do this in your UI:

return props.foods.matchWith({
    LoadingFoods: () =>
        (<Loading />)
    , FoodsError: ({ error }) =>
        (<Failed error={error} />)
    , FoodsLoaed: ({ foods }) =>
        (<FoodsList foods={foods} calories={props.calories} addFood={props.addFood} removeFood={props.removeFood} />)
})

Notice we misspelled FoodsLoadedto FoodsLoaed. The compiler in Elm would catch that and not compile, but TypeScript and Flow will not. This will result in a runtime exception. The pattern matching proposal for JavaScript is at Stage 1 at the time of this writing so until that solidifies, if you’re a TypeScript fan, they have better ways of doing pattern matching the TypeScript way which’ll give you ADT’s + strong typing guarantees. It’s too verbose for my taste, though.

react – 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

Easier Asynchronous State Modelling in React Redux or Hooks

Introduction

Defining The Problem

Loading State

Error State

Success State

Problem #1: Lots of Verbose, Duplicate Code

Problem #2: Impossible States

Problem #3: Incorrect and Unclear UI Behavior

Solving The Problems

Solving Problem #2: Many States is Now One State at a Time

Solving Problem #1: Verbose Code is Now Less Code

Solving Problem #3: Unclear UI Showing Wrong State to More Clear, Deterministic, and Easier to Debug

Conclusions

Et tu, Action Creators?

Can Strong Typing Help Here?