DEV Community: Osman Cea

Flow control, short-circuit expressions and functional programming in JavaScript

Osman Cea — Thu, 30 Dec 2021 11:19:58 +0000

A couple of days ago while doing code review I saw a snippet like this:

React.useEffect(() => {
  someCondition && doSomething()
}, [someCondition, doSomething])

You don't need to know what React.useEffect does or anything, I just want to focus on the body of the callback function.

I suggested my colleague to use an if statement instead of the short-circuit expression. When asked why it was preferable to use an if instead, I didn't have a reasonable answer. It just felt better to me.

But feeling better is not an acceptable reason, specially because it is highly subjective. What feels better to me won't necessarily feel better for the rest of the team.

So I just did what any other person would do: I obsessed about it (😅), trying to rationalize why it felt better.

Disclaimer: This article just describes my reasoning around this topic. Like it or not, that's completely up to you. I'm not suggesting this as a "best practice" or anything else.

One thing I learned from watching Rich Hickey's talks is to always start with a definition:

In computer science, an expression is a syntactic entity in a programming language that may be evaluated to determine its value.

Here's a bunch of expressions in JavaScript:

42                              // 42 
'foo'                           // 'foo'
false                           // false
const nums = [1, 2, 3]          // ??
nums                            // [1, 2, 3]

Values in JavaScript evaluate to themselves, and variables holding values evaluate to whatever they hold. Notice the fourth line in the snippet above: in JavaScript assignments are also expressions. What do you think the expression const nums = [1, 2, 3] evaluates to?

Well, it evaluates to undefined.

In other programming languages (like Python) a variable assignment is not an expression, but a statement. Here's the definition for statement:

In computer programming, a statement is a syntactic unit of an imperative programming language that expresses some action to be carried out.

The important word here is action. Keep that in mind for now.

Here's a bunch of statements in JavaScript:

for (let n of nums) { /*...*/ }
while (true)        { /*...*/ }
if (nums.length)    { /*...*/ }

Ignoring the fact that assignment is an expression (a useless expression, if I do say so myself) it would be reasonable to think that expressions are to values as statements are to actions.

Short-circuit evaluation

More definitions, yey:

Short-circuit evaluation, minimal evaluation, or McCarthy evaluation (after John McCarthy) is the semantics of some Boolean operators in some programming languages in which the second argument is executed or evaluated only if the first argument does not suffice to determine the value of the expression.

Here's an example:

true || false                 // true

In the previous snippet of code, the right-hand side expression of the OR operator is not evaluated since the first argument is enough to determine the value of the whole expression.

It's kinda weird to think about it like this using literals, since literals evaluate to themselves. We'll write this differently so it's easier to reason about:

const aCondition = true
const anotherCondition = false

aCondition || anotherCondition   // true

Since aCondition is true, there's no need for looking up the value of anotherCondition, whatever that is.

Let's try with another example:

const person = {
  get name() {
    console.log('Bayum!')
    return 'Bodoque'
  }
}

true || person.name           // true

If you run this code, you'll notice 'Bayum!' is not logged to the console, since the left-hand side of the || operator is already true, which is good!

But what's the deal with this?

Side effects, functional programming & Haskell

We'll take a brief detour and continue with, guess what, another definition:

Haskell is a general-purpose, statically typed, purely functional programming language with type inference and lazy evaluation.

Let's write a little function with Haskell that prints "42" to the console:

doSomething = putStrLn "42"

Using ghci, which is the Glasgow Haskell Compiler interactive environment (think of a REPL), we can check the type of our doSomething function:

Prelude> doSomething = putStrLn "42"
Prelude> :t doSomething 
doSomething :: IO ()

doSomething is a function that takes no arguments and its return type is IO (), or IO of unit (an empty set of parentheses is called unit and it's similar to void in JavaScript). In Haskell all functions with side effects have a return type of IO of something. Pure functions can't call effectful functions. If you want to have a side effect, the return type should always be IO of something.

Although not mandatory, we can explicitly write type annotations:

doSomething :: IO ()
doSomething = putStrLn "42"

-- Here's another function that takes two Ints 
-- and returns another Int, just for contrast
add :: Int -> Int -> Int 
add a b = a + b

Alright, detour is over, enough Haskell, let's get back on track.

Short-circuit expressions and flow control

A function invocation can always be replaced by its return value if it depends only in its inputs. Another way to phrase it, is that a function invocation can only be replaced by its return value if the function has no side effects.

This property is called referential transparency. Referentially transparent functions are also known as pure functions.

When doing functional programming, our goal is to maximize the surface area of code that's written with pure functions: they are easier to test and easier to reason about. So for most of your functions in a program, you're going to be interested in their return values:

const whatIsThis = someCondition && doSomething()

If we're not interested about the result of doSomething, then it's probably worthless to store the value of the expression into whatIsThis, but the expression will still have a value, whether it is used or not:

function doSomething() {
  console.log("42")
}

someCondition && doSomething()   // `false` when `someCondition` is `false`
                                 // `undefined` when `someCondition` is `true`

If we don't care about the value of the expression, then doSomething is most likely an effectful function. But JavaScript is no Haskell so there's no way to tell if doSomething is effectful or not without looking at its implementation. And even then, it wouldn't be necessarily something straightforward to figure out.

I think this is why I prefer to use an if statement instead of a short-circuit expression for flow control in effectful functions: for me it makes it completely unambiguous that we don't care about the return value, hence it's a side effect.

But what about effectful functions that DO return something?

We don't have a compiler like GHC to enforce purity in our functions, but we can still follow a similar convention that only effectful functions can call other effectful functions. Haskell does this using monads.

Instead of writing an explanation about this topic, let me point you to this really straightforward video that makes a wonderful job:

https://youtu.be/C2w45qRc3aU

CLEAN architecture for React apps

Osman Cea — Tue, 12 Oct 2021 10:47:55 +0000

I originally published a Spanish version of this article on my website:
Arquitectura CLEAN para el frontend

On layered architecture 🍰

Layering is not a novel concept. It's been around in the industry for more than a couple of years (some of you reading this document are probably younger than layering) and it's one of the first architectural styles created. In short, layering is nothing more than dividing the concerns of your application into different layers, like in a cake, where the upper layers can talk to the bottom layers but no the other way around.

Layers interact through facades, so as long as the public APIs are honored, a layer doesn't have to know anything about internal implementation details of other layers.

Let's take a look at the following diagram:

The most typical layered architecture has three layers: UI, Domain and Infrastructure. Our systems can have as many layers as needed, it doesn't have to be just 3. It's just that this is the most typical one.

Translating this into a React application, what we would do is have our view components in the top layer. Then our state management solution would go in the layer below. Last but not least we would have an infrastructure layer for talking to external resources, like our backend, a firebase database, pusher, local storage, and any other external source of information.

For a small application this is good enough, and it's probably how we've been writing React applications for a long time. But as applications grow, these layers keep getting fatter and they start doing too much, which makes them harder to reason about.

Before jumping into that mumbo jumbo, let's talk real quick about the benefits of layering and why we want to explore implementing a layered architecture.

Ease of reasoning

Divide and conquer: the best way of solving a big problem is splitting it into smaller problems that are easier to solve. We can reason about a layer independently without worrying about the implementation of other layers.

Substitution

Layers can be easily substituted with alternative implementations. It's not like we're switching our http library everyday, but when the time comes, the change is self contained within a layer and it should never leak outside the layer's boundaries. Refactoring becomes easier and less intrusive.

Evolution

Architectures that scale must have the capacity of evolving as software matures and requirements change. Although we like to do some design upfront, there are things that will only show up after development starts. When using layers, we can delay decisions about implementation details until we have enough information to make a sensible choice.

Decoupling

Dependencies between layers are controlled since they're one directional. Aiming for low coupling (while maintaining high cohesion, or colocation) is a nice way to avoid our application becoming a big ball of mud.

Testability

Having a layered architecture allows testing each component in isolation easy. Although this is nice, in my opinion it is not the greatest benefit in terms of testability. For me the greatest benefit of layered architectures is that it’s easier to write tests while working on the code. Since each layer should have a well defined responsibility, it's easier to think about what's worth testing during implementation.

All of the things mentioned above help us to write code that's easier to maintain. A maintainable codebase makes us more productive as we spend less time fighting against technical debt and more time working on new features. It also reduces risk when introducing changes. Last but not least, it makes our code easier to test, which ultimately gives us more confidence during development and refactoring.

Now that we know the benefits of layering and layered architectures, let us talk about what type of layered architecture we are proposing for a large React app.

CLEAN architecture

CLEAN architecture is a type of layered architecture composed by various ideas from other layered architectures, like Onion architecture, Hexagonal architecture and Ports and Adapters architecture among others.

The core idea behind CLEAN is putting the business and the business entities at the center of a software system, and each other layer wrapping the entities. Outer layers are less specific to the business whilst inner layers are all about the business.

We'll describe briefly what each layer does in CLEAN architecture, in order to understand how we can leverage some of these concepts in our React applications.

Entities

At the center of the diagram we have entities. In classical CLEAN architecture, entities are a mean of containing state related to business rules. Entities should be plain data structures and have no knowledge of our application framework or UI framework.

For a frontend application, this is where we have the logic related to the entities of our system. We commonly put these entities into a state management library. We'll discuss about this with more details later on.

Use Cases

Use cases are close to what user stories are in agile terminology. This is where the application business rules live. A use case should represent something a user wants to achieve. Use cases should have all the code to make that happen in a way that makes sense to the application. Notice that use cases can only depend on inner layers, so in order for stuff to happen inside a use case (let's say make an http request) we have to inject dependencies into our use case and apply inversion of control.

Controllers / Presenters / Gateways

This layer contains framework code that implements the use cases. Typically the UI layer would call the methods exposed by the controllers or presenters.

Framework & Drivers

The outermost layer is where all the IO operations are contained. User input, http connections, reading from a web storage, etc. This is where our UI framework lives.

It is worth noting that as any other layered architecture, we can add as many layers as our system needs. With that being said, let's see how these concepts match with what we usually do with React to implement this architecture on a toy application.

A really convoluted counter application

We'll talk about each concept on CLEAN architecture through a ~~really convoluted~~ simple counter application. Our application will look something like this:

Let's describe some of the requirements of our application.

The initial value should come from a remote data source
The counter can't be decremented when the counter value is 0
We should persist the counter value back to our remote data source

We'll talk about each layer for our counter application:

Entities

In the center of the universe we have our domain entities. In this case we'll define a Counter interface with nothing more than a value property. This could also be just a plain type alias for number (type Counter = number;).

It's important to say that this is how we're going to understand a Counter entity in the rest of our application, so this definition is kind of the "source of truth" in terms of what a counter is.



// domain/counterEntity.ts
export interface Counter {
  value: number;
}

Although we could use a class for representing the data model, an interface works just fine.

Domain model

According to Martin Fowler:

An object model of the domain that incorporates both behavior and data.

Inside our domain model we can define operations over our entities. In this case a simple increment and decrement functions will do.

Notice that the business rule that the counter value can never go under zero is defined here, right next to the entity definition.



// domain/counterModel.ts
import type { Counter } from "./counterEntity";

const create = (count: Counter["value"]) => ({ value: count });
const decrement = (counter: Counter) => ({
  value: Math.max(counter.value - 1, 0)
});
const increment = (counter: Counter) => ({ value: counter.value + 1 });

export { create, decrement, increment };

We could put the entity interface and the domain model in the same file and it would be completely fine.

Data Store (a.k.a repository)

This layer is for what we typically think of as state management. However, here we only define the shape of our data access layer, not the implementation. For this we can use an interface.



// domain/counterStore.ts
import type { Counter } from "./counterEntity";

interface CounterStore {
  // State
  counter: Counter | undefined;
  isLoading: boolean;
  isUpdating: boolean;

  // Actions
  loadInitialCounter(): Promise<Counter>;
  setCounter(counter: Counter): void;
  updateCounter(counter: Counter): Promise<Counter | undefined>;
}

export type { CounterStore };

Use cases

As mentioned previously, use cases can be defined as user stories, or things a user (or any other external system) can do with our system.

There are 3 use cases for our application

Get the counter initial value from a data source
Increment the counter value
Decrement the counter value

Notice that updating the counter value in the remote data source is not a use case. That is a side effect of incrementing or decrementing the counter. For this layer it doesn't even matter that the data source is remote.

Get counter use case



// useCases/getCounterUseCase.ts
import type { CounterStore } from "../domain/counterStore";

type GetCounterStore = Pick<CounterStore, "loadInitialCounter">;

const getCounterUseCase = (store: GetCounterStore) => {
  store.loadInitialCounter();
};

export { getCounterUseCase };

For this particular case we've defined an interface Store for the data store (a.k.a repository) that only needs to have a getCounter method. Our real Store implementation will probably have many more methods, but this is the only thing we care about in this layer.

Increment counter use case



// useCases/incrementCounterUseCase.ts
import { updateCounterUseCase } from "./updateCounterUseCase";
import type { UpdateCounterStore } from "./updateCounterUseCase";
import { increment } from "../domain/counterModel";

const incrementCounterUseCase = (store: UpdateCounterStore) => {
  return updateCounterUseCase(store, increment);
};

export { incrementCounterUseCase };

Decrement counter use case



// useCases/decrementCounterUseCase.ts
import { updateCounterUseCase } from "./updateCounterUseCase";
import type { UpdateCounterStore } from "./updateCounterUseCase";
import { decrement } from "../domain/counterModel";

const decrementCounterUseCase = (store: UpdateCounterStore) => {
  return updateCounterUseCase(store, decrement);
};

export { decrementCounterUseCase };

Update counter use case

The two previous use cases use this updateCounterUseCase to update the counter value under the hood. As you can see use cases can be composed.



// useCases/updateCounterUseCase.ts
import debounce from "lodash.debounce";

import type { Counter } from "../domain/counterEntity";
import type { CounterStore } from "../domain/counterStore";

type UpdateCounterStore = Pick<
  CounterStore,
  "counter" | "updateCounter" | "setCounter"
>;

const debouncedTask = debounce((task) => Promise.resolve(task()), 500);

const updateCounterUseCase = (
  store: UpdateCounterStore,
  updateBy: (counter: Counter) => Counter
) => {
  const updatedCounter = store.counter
    ? updateBy(store.counter)
    : store.counter;

  // Early return so we only persist the data when it makes sense
  if (!updatedCounter || store.counter?.value === updatedCounter?.value) return;

  store.setCounter(updatedCounter);

  return debouncedTask(() => store.updateCounter(updatedCounter));
};

export { updateCounterUseCase };
export type { UpdateCounterStore };

Notice how we debounce the call to store.updateCounter here so we only update our remote source counter once the user stops clicking (I've also implemented an optimistic update). , instead of debouncing the button click. Putting this logic here might feel counterintuitive at first, but now the application logic is contained in a single place rather than spread between the view layer and the data layer.

In reality this implementation really should go in the repository, but to be honest there's no clear consensus. Some articles say you should inject services here while other implementations hide the asynchrony in the repository, like I've done. I haven't tested both approaches extensively to make up my mind yet. If you ask me, it depends on how much you want to make this library agnostic or not.

Controllers / Presenters / Gateways

As you probably noticed, we haven't written anything specific to React so far: it's only been plain ole TypeScript. This is the first layer where we're going to use React code.

The role of this layer is to encapsulate use cases so they can be called from the UI. For this we can use plain react hooks.

We'll use a ViewModel kind of pattern here (we'll elaborate more deeply on the role of this component later on):



// controller/counterViewModel.ts
import React from "react";

import type { CounterStore } from "../domain/counterStore";
import { getCounterUseCase } from "../useCases/getCounterUseCase";
import { incrementCounterUseCase } from "../useCases/incrementCounterUseCase";
import { decrementCounterUseCase } from "../useCases/decrementCounterUseCase";

function useCounterViewModel(store: CounterStore) {
  const getCounter = React.useCallback(
    function () {
      getCounterUseCase({
        loadInitialCounter: store.loadInitialCounter
      });
    },
    [store.loadInitialCounter]
  );

  const incrementCounter = React.useCallback(
    function () {
      incrementCounterUseCase({
        counter: store.counter,
        updateCounter: store.updateCounter,
        setCounter: store.setCounter
      });
    },
    [store.counter, store.updateCounter, store.setCounter]
  );

  const decrementCounter = React.useCallback(
    function () {
      decrementCounterUseCase({
        counter: store.counter,
        updateCounter: store.updateCounter,
        setCounter: store.setCounter
      });
    },
    [store.counter, store.updateCounter, store.setCounter]
  );

  return {
    count: store.counter?.value,
    isLoading: typeof store.counter === "undefined" || store.isLoading,
    canDecrement: store.counter?.value === 0,
    getCounter,
    incrementCounter,
    decrementCounter
  };
}

export { useCounterViewModel };

The view model not only binds the use cases to framework specific functions, but it also formats the data to semantic variables, so the presentation logic is contained in a single place, rather than scattered throughout the whole view.

Frameworks & Drivers

Ok so this is the outermost layer and here we can have all our specific library code, for this particular example it would mean:

React components
A state management library store implementation
A counter API service so we can persist the data to the data source
An HTTP client for talking to the remote data source
Internationalization
and much more

We'll start creating the API service:

Counter API Service



// data/counterAPIService.ts
import httpClient from '../../shared/httpClient'; // Esto puede ser una instancia de axios, para este caso es irrelevante
import type { Counter } from '../domain/counterEntity';
import { create } from '../domain/counterModel';

const BASE_URL = 'counter';

function getCounter(): Promise<Counter> {
  return httpClient.get<number>(BASE_URL).then(res => create(res.data));
}

function updateCounter(counter: Counter): Promise<Counter> {
  return httpClient.put<number>(BASE_URL, { count: counter.value }).then(res => create(res.data));
}

export { getCounter, updateCounter };

Data Store Implementation (a.k.a. repository implementation)

The beauty about layered architecture is that we don't care about how the hell layers are implemented internally. For the CounterStoreImplementation we could use anything: mobx, redux, zustand, recoil, react-query, a simple React component, whatever, it doesn't matter.

We'll use redux here for good measure, just to demonstrate that the implementation details don't leak into the other layers:



// data/counterActionTypes.ts
export const SET_COUNTER = "SET_COUNTER";
export const GET_COUNTER = "GET_COUNTER";
export const GET_COUNTER_SUCCESS = "GET_COUNTER_SUCCESS";
export const UPDATE_COUNTER = "UPDATE_COUNTER";
export const UPDATE_COUNTER_SUCCESS = "UPDATE_COUNTER_SUCCESS";



// data/counterActions.ts
import type { Counter } from "../domain/counterEntity";
import { getCounter, updateCounter } from "./counterService";
import * as actionTypes from "./counterActionTypes";

const setCounterAction = (counter: Counter) => (dispatch: any) =>
  dispatch({ type: actionTypes.SET_COUNTER, counter });

const getCounterAction = () => (dispatch: any) => {
  dispatch({ type: actionTypes.GET_COUNTER });

  return getCounter().then((counter) => {
    dispatch({ type: actionTypes.GET_COUNTER_SUCCESS, counter });

    return counter;
  });
};

const updateCounterAction = (counter: Counter) => (dispatch: any) => {
  dispatch({ type: actionTypes.UPDATE_COUNTER });

  return updateCounter(counter).then((counter) => {
    dispatch({ type: actionTypes.UPDATE_COUNTER_SUCCESS });

    return counter;
  });
};

export { setCounterAction, getCounterAction, updateCounterAction };



// data/counterReducer.ts
import type { AnyAction } from "redux";
import type { CounterStore } from "../domain/counterStore";
import * as actionTypes from "./counterActionTypes";

type CounterStoreState = Omit<CounterStore, "loadInitialCounter" | "setCounter" | "updateCounter">;

const INITIAL_STATE: CounterStoreState = {
  counter: undefined,
  isLoading: false,
  isUpdating: false
};

const counterReducer = (state: CounterStoreState = INITIAL_STATE, action: AnyAction) => {
  switch (action.type) {
    case actionTypes.SET_COUNTER:
      return { ...state, counter: action.counter };
    case actionTypes.GET_COUNTER:
      return { ...state, isLoading: true };
    case actionTypes.GET_COUNTER_SUCCESS:
      return { ...state, isLoading: false, counter: action.counter };
    case actionTypes.UPDATE_COUNTER:
      return { ...state, isUpdating: true };
    case actionTypes.UPDATE_COUNTER_SUCCESS:
      return { ...state, isUpdating: false };
    default:
      return state;
  }
};

export { counterReducer };
export type { CounterStoreState };

With all of our typical redux code in place, only now we can create a counter store implementation for the CounterStore interface:



// data/counterStoreImplementation.ts
import React from "react";
import { useDispatch, useSelector } from "react-redux";

import type { AppRootState } from "../../main/data/appStoreImplementation";
import type { CounterStore } from "../domain/counterStore";
import type { Counter } from "../domain/counterEntity";

import type { CounterStoreState } from "./counterReducer";
import {
  getCounterAction,
  setCounterAction,
  updateCounterAction
} from "./counterActions";

const counterSelector = (state: AppRootState) => state.counter;

const useCounterStoreImplementation = (): CounterStore => {
  const { counter, isLoading, isUpdating } = useSelector<
    AppRootState,
    CounterStoreState
  >(counterSelector);
  const dispatch = useDispatch();

  const setCounter = React.useCallback(
    (counter: Counter) => setCounterAction(counter)(dispatch),
    [dispatch]
  );

  const loadInitialCounter = React.useCallback(
    () => getCounterAction()(dispatch),
    [dispatch]
  );

  const updateCounter = React.useCallback(
    (counter: Counter) => updateCounterAction(counter)(dispatch),
    [dispatch]
  );

  return {
    counter,
    isLoading,
    isUpdating,
    setCounter,
    loadInitialCounter,
    updateCounter
  };
};

export { useCounterStoreImplementation };

View

The last layer we'll show case here is the UI or View layer. This is the integration point for all of our components:



// view/AppView.tsx
import React from "react";

import Button from "../../shared/ui/Button";
import Count from "../../shared/ui/Count";
import Spinner from "../../shared/ui/Spinner";

import { useCounterViewModel } from "../controller/counterViewModel";
import { useCounterStoreImplementation } from "../data/counterStoreImplementation";

const CounterView = () => {
  const store = useCounterStoreImplementation();
  const {
    count,
    canDecrement,
    isLoading,
    getCounter,
    incrementCounter,
    decrementCounter
  } = useCounterViewModel(store);

  React.useEffect(() => {
    getCounter();
  }, [getCounter]);

  return (
    <div className="App">
      {isLoading ? (
        <Spinner />
      ) : (
        <>
          <Button onClick={decrementCounter} disabled={!canDecrement}>
            dec
          </Button>
          <Count>{count}</Count>
          <Button onClick={incrementCounter}>inc</Button>
        </>
      )}
    </div>
  );
};

export default CounterView;

There's not much to say about this layer rather than the mapping from our view state to whatever UI elements are being shown on the screen is really straightforward, since we mapped our business rules to semantic variables on the View model.

Recap

And that is it, this is a nice way to implement CLEAN architecture on React applications. Sum up, the benefits an architecture like CLEAN brings to the table are:

It makes our code easier to reason about, since each layer has a well defined role and we can focus on a single layer without knowing the implementation details of the other layers
This also enables substitution of any layer. With a well defined surface and limits between our layers, it's easier to try new technologies, among other things.
By respecting the dependency rule we're able to isolate the business from framework specific code, making it easier to describe, implement and test
Each layer can be tested independently during implementation, which is far more convenient than writing tests after everything is in place.

Now, the big question is: Should you use CLEAN on your current/next project? The quick answer is there are no silver bullets. CLEAN architecture has its advantages and disadvantages; while it makes our code more structured, it also brings a lot of boilerplate. And as I mentioned before, implementing CLEAN for an application as the one we've shown here it's a massive overkill. We'll talk about more tradeoffs in a following article.

Last but not least, you can find the source code here.

If you liked the content, don't forget to share it on Twitter and follow me there.

Beware: I mostly tweet JavaScript rants on Spanish.

References

Martin Fowler - Catalog of Patterns of Enterprise Application Architecture https://martinfowler.com/eaaCatalog/domainModel.html
Denis Brandi - Why you need use cases interactors https://proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576
Bob Martin - The Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Daniel Mackay - Clean Architecture, an introduction https://www.dandoescode.com/blog/clean-architecture-an-introduction/
CodingWithMitch - 2 Key Concepts of Clean Architecture https://www.youtube.com/watch?v=NyJLw3sc17M
Frank Bos and Fouad Astitou - Fuck CLEAN Architecture https://www.youtube.com/watch?v=zkmcy9WQqUE
Ian Cooper, The Clean Architecture https://www.youtube.com/watch?v=SxJPQ5qXisw

Using React and RxJS together

Osman Cea — Wed, 03 Jun 2020 13:21:56 +0000

Cover image by Wu Yi on splash.

This article was originally posted on Spanish in my blog

This article is not a tutorial about React nor about RxJS, but just some of my thoughts about how to use RxJS on React applications.

RxJS is a library for Functional Reactive Programming (FRP from now on) in JavaScript. If you google what is FRP, you'll probably find a lot of really cool definitions, each one a little bit more complex than the previous one.

My favorite definition of FRP is:

The essence of FRP is to specify the dynamic behavior of a value when declaring it
– Heinrich Apfelmus

Mind-blowing right?

What does this mean?

When doing FRP we try to specify how the value of a variable is going to change over time at declaration time. It might seem rather strange how code like this would look, since JavaScript doesn't have primitives for doing something like this (generators is the closest thing I can think of).

On React land there IS a way to define the value of a variable that could satisfy this definition, but with some limitations. Consider the following example:

const greeting = React.useMemo(() => `${greet}, ${name}!`, [greet, name]);

useMemo lets us define a computed value that will be recalculated whenever their dependencies change. In our case, the value of greeting will be recomputed depending on the values of greet and name. Fair enough, greeting is just the result of a simple expression `${greet}, ${name}!`, but it turns out we control when its value is recomputed by using useMemo, which is convenient for our definition of reactivity.

Wonderful! And that could be all, folks, and we'd live happily ever after. However, useMemo only lets us define greeting when greet and name change, but it doesn't provide any information about where and how those values change and how they are updated.

The million dollar question is: How and where do these dependencies change?

Looking at a more realistic example:

import * as React from 'react';

const GreetSomeone = ({ greet = 'Hello' }) => {
    const [name, setName] = React.useState('World');
    const greeting = React.useMemo(() => `${greet}, ${name}!`, [greet, name]);

    React.useEffect(() => {
        fetchSomeName().then(name => {
            setName(name);
        }, () => {
            setName('Mololongo');
        });
    }, []);

    return <p>{greeting}</p>;
};

Out GreetSomeone component receives greet from props and name is the result of a promise returned by calling fetchSomeName.

Although the definition of greeting hasn't changed, we cannot determine just by reading it that one of the values on the dependency array comes from a Promise and that by extent, is async.

In JavaScript there are no primitives for determining the async nature of this expression (neither in React).

Observables to the rescue

Let's get away from React for a while and let's see if we can express greeting (and fulfill our FRP definition) using RxJS. We'll start by defining two Observables that will emit the values of greet and name, and we will compose them to get another Observable back that will represent how greeting changes over time:

import { combineLatest, of } from 'rxjs';
import { map } from 'rxjs/operators';

const greet$ = of('Hello');
const name$ = of('World');

const greeting$ = combineLatest(greet$, name$).pipe(
    map(([greet, name]) => `${greet}, ${name}!`)
);

greeting$.subscribe(greeting => {
    console.log(greeting);    
});

// =>: "Hello, World!" -- When we subscribe to greeting$

In our React example the value of name came from a Promise. In RxJS land, defining the async nature of name is quite simple, we only have to create an Observable from fetchSomeName and handle weather the Promise is resolved or rejected in the following way:

import { combineLatest, from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const greet$ = of('Hello');
const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo')),
);

const greeting$ = combineLatest(greet$, name$).pipe(
    map(([greet, name]) => `${greet}, ${name}!`)
);

greeting$.subscribe(greeting => {
    console.log(greeting);    
});

// ✏️: "Hello, World!"      -- When we subscribe to greeting$
// ✅: "Hello, Thundercat!" -- When `fetchSomeName()` is resolved
// ❌: "Hello, Mololongo!"  -- When `fetchSomeName()` is rejected

And that is all it take to define the async nature of name$ and by extent, the async nature of greeting$.

Back to React

Considering what we know so far. How we could implement our RxJS solution in React?

To answer this question, it's convenient to first understand that useMemo is kind of equivalent to useState + useEffect. For example:

const greeting = React.useMemo(() => `${greet}, ${name}!`, [greet, name]);

Can be described like:

const [greeting, setGreeting] = useState(() => `${greet}, ${name}!`);

useEffect(() => {
    setGreeting(() => `${greet}, ${name}!`);
}, [greet, name]);

Although in practice both snippets yield similar results, there are a couple of substantial differences on how they do it.

The callback function we pass to useEffect runs after render, while the useMemo variable is calculated before render. In other words, during the first render the value of greeting with useMemo will already be computed; whilst in our useEffect version, its value on the first render will be the value defined with our useState.

The fact we can describe a state update inside a useEffect callback, is just pointing out that updating state is in practice a "side effect", as in it is affecting the real world. In the case of useMemo, this is conveniently handled by React.

With that being said, the strategy to use RxJS with React is basically by deferring the way we handle these (side) effects from React to RxJS.

We'll start by copying all of our RxJS code inside our GreetSomeone component. In order to render our component whenever greeting$ emits a value, we have to let React know that something happened by using some mechanism familiar to React, like useState:

import * as React from 'react';
import { combineLatest, from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const GreetSomeone = ({ greet = 'Hello' }) => {
    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => {
        const greet$ = of(greet);
        const name$ = from(fetchSomeName()).pipe(
            startWith('World'),
            catchError(() => of('Mololongo')),
        );

        const greeting$ = combineLatest(greet$, name$).pipe(
            map(([greet, name]) => `${greet}, ${name}!`)
        );

        const subscription = greeting$.subscribe(value => {
            setGreeting(value);
        });

        return () => {
            subscription.unsubscribe();
        }
    }, []);

    return <p>{greeting}</p>;
};

After the first render (when the component "mounts"), the function we passed to useEffect will be executed, and with that all the logic to calculate the value of greeting.

One problem with our current solution is that if the of value of greet changes, greeting will not be recomputed. This is because our greet$ Observable is defined when the useEffect callback is executed, and this just happens once. Any change to greet will not be propagated to greet$, and by extension neither greeting$ will know about it.

One thing we could do is add greet as a dependency to useEffect, making sure that the callback is executed every time greet changes. Although this solves our problem, it could have some unexpected consequences.

The effect callback will be executed EVERY time greet changes. When the callback runs, not only we will be defining greet$ with the latest value greet, but also name$ will be redefined, and this will execute the getSomeName function again.

In our initial example we are only interested in calling getSomeName once, so let's forget about this alternative.

Something interesting about the dependency array of React hooks: The hook callback will be executed only when its dependencies change, and React tracks these changes by just doing plain old value comparison. In JavaScript, primitive values are equal when their values are equal (5 is always equal to 5) but things like objects are only equal if they point to the same reference (memory address, call it whatever you like).

What this actually means is that if we have an object as a dependency, and the reference to that object doesn't change, it doesn't matter how the inner properties of that object change: the hook simply will not be executed. It will only run when the variable we are observing points to a different reference.

What we'll do then, is define greet$ as a BehaviorSubject (using a ref) that will emit values whenever greet changes:

import * as React from 'react';
import { BehaviorSubject, combineLatest, from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = React.useRef(new BehaviorSubject(greet));

    // Observe `greet` with `useEffect` and forward the value to `greet$`
    React.useEffect(() => {
        greet$.current.next(greet);
    }, [greet]);

    // Rest of the code remains almost the same
    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => {
        const name$ = from(fetchSomeName()).pipe(
            startWith('World'),
            catchError(() => of('Mololongo')),
        );

        const greeting$ = combineLatest(greet$.current, name$).pipe(
            map(([greet, name]) => `${greet}, ${name}!`)
        );

        const subscription = greeting$.subscribe(value => {
            setGreeting(value);
        });

        return () => {
            subscription.unsubscribe();
        }
    }, [greet$]);

    return <p>{greeting}</p>;
};

BehaviorSubject is kinda like an event emitter which we can subscribe to (just like we do with regular Observables), but as with any event emitter, we con produce values imperatively calling the next method. We store our subject with useRef, which lets us persist our reference between renders.

But how this is better if we have more code?

First, our main useEffect callback just runs once: Hooray!

Second, we can hide the implementation details using a custom hook:

const useObservedValue = value => {
    const subject = React.useRef(new BehaviorSubject(value));

    React.useEffect(() => {
        subject.current.next(value);
    }, [value]);

    return React.useMemo(() => subject.current.asObservable(), [subject]);
};

And then:

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = useObservedValue(greet);
    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => { /* etc */ }, [greet$]);

    return <p>{greeting}</p>;
};

useObservedValue returns the memoized value of subject.current.asObservable() to discourage emitting values manually on our Subject using next.

Continuing with our refactoring, we can extract the definition of name$ from the useEffect callback (we can actually extract it from out component entirely, FWIW).

We'll also define greeting$ outside of useEffect:

import * as React from 'react';
import { from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo')),
);

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = useObservedValue(greet);
    const greeting$ = React.useMemo(
        () => combineLatest(greet$, name$).pipe(
            map(([greet, name]) => `${greet}, ${name}!`)
        )), []
    );

    const [greeting, setGreeting] = React.useState('');

    React.useEffect(() => {
        const subscription = greeting$.subscribe(value => {
            setGreeting(value);
        });

        return () => {
            subscription.unsubscribe();
        }
    }, [greeting$]);

    return <p>{greeting}</p>;
};

Finally, our useEffect only responsibility is to subscribe to greeting$ and persist each emitted value with setGreeting.

We could even encapsulate this with another custom hook:

const useObservable = (observable) => {
    const [value, setValue] = React.useState();

    React.useEffect(() => {
        const subscription = observable.subscribe((v) => {
            setValue(v);
        });

        return () => {
            subscription.unsubscribe();
        };
    }, [observable]);

    return value;
};

Finally:

import * as React from 'react';
import { from, of } from 'rxjs';
import { catchError, map, startWith } from 'rxjs/operators';

const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo')),
);

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greet$ = useObservedValue(greet);
    const greeting$ = React.useMemo(
        () =>
            combineLatest([greet$, name$]).pipe(
                map(([greet, name]) => `${greet}, ${name}!`)
            ),
        [greet$]
    );

    const greeting = useObservable(greeting$);

    return <p>{greeting}</p>;
};

And that is it! We've specified the dynamic behavior of greeting$ at its definition place. You can see a working demo here.

Sorting things out

Ok, I get it. The solution I've implemented is not the cleanest and has a lot of rough edges. But, it is a good starting point to understand what it takes to use RxJS Observables in React.

Rather than using our own custom hooks, we could use a library for handling all the boilerplate. Let's take a look at the same example using rxjs-hooks:

import * as React from 'react';
import { from, of } from 'rxjs';
import {
    catchError,
    combineLatest,
    map,
    pluck,
    startWith,
} from 'rxjs/operators';
import { useObservable } from 'rxjs-hooks';

const name$ = from(fetchSomeName()).pipe(
    startWith('World'),
    catchError(() => of('Mololongo'))
);

const GreetSomeone = ({ greet = 'Hello' }) => {
    const greeting = useObservable(
        input$ =>
            input$.pipe(
                pluck(0),
                combineLatest(name$),
                map(([greet, name]) => `${greet}, ${name}!`)
            ),
        '',
        [greet]
    );

    return <p>{greeting}</p>;
};

You can look at their documentation to understand what useObservable does under the hood. But truth be told, the code surface is considerably reduced.

And voilá, that's all for today. By using RxJS we can express the async dynamic behavior of our state in a more declarative fashion, by using function composition and other fancy functional programming techniques.

It also lets us define really complex async logic that would be a nightmare to handle using plain old Promises.

Although there is some friction when using RxJS inside React, hooks play a great role in order to improve the way both libraries operate together.

If you liked the content, don't forget to share it on Twitter and follow me over there perhaps.

Beware: I mostly tweet JavaScript rants on Spanish.

An introduction to Reactive Programming in JavaScript

Osman Cea — Mon, 01 Jul 2019 03:05:35 +0000

This article was originally published in Spanish here.

Reactive programming is a declarative programming paradigm focused in (1) the usage of data streams and (2) change propagation. The zen of reactive programming is that everything is a stream.

But Osman, what is a stream?

Yeah, Osman. What is a stream?

About streams

According to Wikipedia:

In computer science, a stream is a sequence of data elements made available over time. A stream can be thought of as items on a conveyor belt being processed one at a time rather than in large batches.

Applying the zen of reactive programming: all the data and the events triggered during the lifecycle of an application can be represented as streams of data over time; and our programs are reactive when we react to these changes.

The most common example of reactiveness I can think of is the following:

const $increment = document.querySelector('#increment');
let counter = 0;

$increment.addEventListener('click', onIncrement);

function onIncrement(event) {
  counter += 1;
}

Yes, when registering onIncrement as an event listener for the click event, we are using reactive programming. We can think of every click on the $increment button as a collection of events over time, and for each event we react running onIncrement.

But not only clicks can be represented as a stream. Each time onIncrement is executed, we're mutating the value of counter over time, hence the value of counter can be represented as a stream as well.

Let's add a couple more functions to our example:

const $increment = document.querySelector('#increment');
const $decrement = document.querySelector('#decrement');
const $double = document.querySelector('#double');
const $halve = document.querySelector('#halve');

let counter = 0;

$increment.addEventListener('click', onIncrement);
$decrement.addEventListener('click', onDecrement);
$double.addEventListener('click', onDouble);
$halve.addEventListener('click', onHalve);

function onIncrement(e) {
  counter += 1;
}
function onDecrement(e) {
  counter -= 1;
}
function onDouble(e) {
  counter *= 2;
}
function onHalve(e) {
  counter /= 2;
}

The value of counter will change every time we click on any of the buttons and will be logged to the console. Unfortunately, changing the value of counter inside our event listener callbacks is not the best thing to do: even though we're expressing the intention of mutating counter in some way, it's not that clear that the value of counter is the result of a group of specific operations. It would be much better (or more declarative) if we could express the former code like this:

let counter = 0;

combine(
  onIncrementClick,
  onDecrementClick,
  onDoubleClick,
  onHalveClick,
).observe(result => {
  counter = result;
  console.log(result);
});

I'd dare to say, that even without knowing the implementation details of the combine and observe functions, it's way more clear and easier to understand the program's intention: from an initial value and combining a set of functions, we get a new value of counter.

Let's go back to the idea that everything is a stream.

Representation of clicks on $increment over time

The marble diagram above is a representation of click events on the button $increment over time, or phrasing it using the concepts we've been learning so far, a stream of clicks.

We can have a timeline for each button as well:

When combining our streams we have produced another stream called clicks. This stream is a representation of which buttons have been clicked over a window of time. If we associate each stream of clicks with a function that updates the value of counter, our clicks stream can also represent the value of counter over time.

We will see how to combine our events in a single stream later on.

Having clarified the nature of streams, let's talk about the second important concept in reactive programming, which is change propagation.

What is change propagation?

Change propagation is basically how we notify a module of our program that some of its dependencies have changed (or that some event has occurred) and that it has to react accordingly.

In reactive systems the ergonomics between the change emitter and whomever reacts to those changes has a different constitution than in proactive systems.

André Staltz explains this relationship brilliantly in this talk.

In summary, in a proactive system if a module triggers a change on another module, the former has the latter as a dependency. In reactive systems the relation is reversed. Let's see how this works with a code example:

class Cart {
  constructor(invoice) {
    this.items = [];
    this.invoice = invoice;
  }

  addItem(item) {
    this.items.push(item);
  }

  checkout() {
    const total = this.items.reduce(
      (acc, item) => acc + item.price,
      0
    );

    this.invoice.update(total);
  }
}

class Invoice {
  constructor() {
    this.total = 0;  
  }

  update(total) {
    this.total = total;
  }
}

const invoice = new Invoice();
const cart = new Cart(invoice);

cart.addItem({ name: 'Miller Lite', price: 1.99 });
cart.addItem({ name: 'Chips', price: 1.50 });
cart.checkout();

console.log(invoice.total); // 3.49

The Cart class has the Invoice as a dependency (we pass an instance of Invoice to Cart as a constructor argument). The moment we invoke the checkout method, the update method on Invoice is called directly. In this case, we're triggering a change on the class Invoice from Cart class, hence our system is proactive.

Let's take a look at the reactive version:

const EventEmitter = require('events');

class Cart {
  constructor() {
    this.items = [];
    this.emitter = new EventEmitter();
  }

  addItem(item) {
    this.items.push(item);
  }

  checkout() {
    const total = this.items.reduce(
      (_total, item) => _total + item.price,
      0
    );

    this.emitter.emit('checkout', total);
  }
}

class Invoice {
  constructor(cart) {
    this.total = 0;
    this.cart = cart;

    this.cart.emitter.on('checkout', this.update.bind(this));
  }

  update(total) {
    this.total = total;
  }
}

const cart = new Cart();
const invoice = new Invoice(cart);

cart.addItem({ name: 'Miller Lite', price: 1.99 });
cart.addItem({ name: 'Chips', price: 1.50 });
cart.checkout();

console.log(invoice.total); // 3.49

The main difference here is that now Invoice has Cart as dependency, the other way around from the former example. Now when we call the checkout method, an event called checkout is emitted with the total fee as payload. Notice that we have not updated the total value inside the Invoice instance, we have only emitted a message that the checkout event has occurred. The Invoice instance is listening for an event of type checkout and whenever this event is emitted, it handles it calling the update method.

This, ladies and gentlemen, is reactivity.

The Observer Pattern 👀

We already know the principles of reactive programming, however it would be a nice idea that we take a look at a design pattern that can help us modeling the interaction between different parts of our program: the Observer Pattern.

According to Wikipedia:

The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

Let's take a look back to our first example:

const $increment = document.querySelector('#increment');
let counter = 0;

$increment.addEventListener('click', onIncrement);

function onIncrement(event) {
  counter += 1;
}

Let's say we want to have multiple counters instead of just one. How should we refactor our program? We could (a) modify the onIncrement function to update the counters inside its body, or (b) register more functions that listen to the same event.

Solution (a) is not that flexible. If we remove the event listener then we lose the ability to update any of our counters. We can't update one counter at the time as well:

const $increment = document.querySelector('#increment');
let counterA = 0;
let counterB = 0;

$increment.addEventListener('click', onIncrement);

function onIncrement(event) {
  counterA += 1;
  counterB += 1;
}

// After 3 seconds no counter will receive updates
setTimeout(() => {
  $increment.removeEventListener('click', onIncrement);
}, 3000);

For implementing solution (b) let's apply the Observer Pattern. We'll create a class called FromEvent that will serve as a subject:

class FromEvent {
  constructor(target, name) {
    this.observers = [];

    target.addEventListener(name, this.next.bind(this));
  }

  observe(observer) {
    this.observers.push(observer);
  }

  remove(observer) {
    this.observers = this.observers.filter(
      obs => obs !== observer
    );
  }

  next(e) {
    this.observers.forEach(obs => obs.next(e));
  } 
}

And we use our class FromEvent to register observers of the click event:

const $increment = document.querySelector('#increment');
let counterA = 0;
let counterB = 0;

const fromEvent = new FromEvent($increment, "click");

const updateCounter = (counter, callback) => (event) => {
  counter = callback(counter);
  console.log(counter);
};

const observerA = {
  next: updateCounter(counterA, value => value + 1)
};
const observerB = {
  next: updateCounter(counterB, value => value + 2)
};

fromEvent.observe(observerA);
fromEvent.observe(observerB);

// After 3 seconds only counterA will receive updates
setTimeout(() => {
  fromEvent.remove(observerB);
}, 3000);

In this case, we assign a high order function (updateCounter) to the next method of each observer, which is responsible for updating the value of each counter. Then we register each observer to the fromEvent subject using the observe function. This way, we have effectively model our program to have a source of changes (the subject) and multiple consumers (the observers).

Back to the beginning

With the knowledge we have acquired, let's implement our ideal API proposed at the beginning of the article:

let counter = 0;

combine(
  onIncrementClick,
  onDecrementClick,
  onDoubleClick,
  onHalveClick,
).observe(result => {
  counter = result;
  console.log(result);
});

We will start implementing combine, which is a function that takes two or more subjects as parameters and returns a new subject. The idea is that whenever any of the subjects emits an event, we must notify the observers of the subject returned by combine. When we register an observer on combine, we will also register that some observer on every of the subjects that we passed as arguments to combine.

const combine = (...subjects) => ({
  observe: observer => {
    subjects.forEach(subject => {
      subject.observe(observer)
    })
  }, 
});

And we can pass multiple streams as arguments:

const onIncrementClick = new FromEvent($increment, "click");
const onDecrementClick = new FromEvent($decrement, "click");

const clicks = combine(
  onIncrementClick,
  onDecrementClick
);

const clicksObserver = {
  next: e => console.log('click', e.target.id)
}

clicks.observe(clicksObserver);

Great! Now we have a way to combine multiple data streams.

Homework

So we covered all the bases about how to do reactive programming using the observer pattern. The only thing left to do now is map each stream of events to functions that can modify the counter value accordingly. In case you can't figure out where to start, you can add a map method to the FromEvent class in order to map each event to a value that's useful.

You can find my implementation of the solution here.

If you liked this article don't forget to share it and follow me on Twitter for more insights about JavaScript, Reactive Programming, Functional Programming, Frontend Development and more.

Cheers!