DEV Community: Sam Holmes

The Reactor Pattern

Sam Holmes — Wed, 11 Mar 2020 03:24:41 +0000

The Reactor Pattern is a way to achieve a reactive-programming style of coding with the use of a primitive called a Reactor. Similar to how Promises are a primitive concerned with asynchronous control-flow, Reactors are proposed to be a primitive concerned with the data streams and the propagation of change.

What are Reactors

Reactors are objects that maintain an internal state and implement two methods to retrieve and update the state. Along with this, they maintain two arrays of other Reactor objects: an ancestors array and descendants array. These two arrays act as data-binding relationships between Reactors and establish a graph of data propagation:

A Reactor should invoke the update methods for each of its descendants after its internal state has been changed. Each descendant should have access to the state from its ancestors when being updated. This allows for automatic propagation of change throughout the graph.

How to use Reactors

Let's discuss how to use a specific implementation of a Reactor.

const myReactor = new Reactor(initialState);

In this example a Reactor is instantiated from the Reactor class. The state of the Reactor is defined by the initialState constructor argument. The initialState is optional and can be omitted, but by doing so the Reactor's internal state is undefined.

With this specific implementation, state can be accessed and redefined using the state getter/setter:

myReactor.state = newState;
console.log(myReactor.state);

The getter/setter internally invokes the the retrieve and update methods.

State can be defined as an expression by using a function as the state argument.

const myReactor = new Reactor(() => 1 + 1);

This allows you to define a Reactor's state as an expression of other Reactor's state.

const noun = new Reactor('world');
const message = new Reactor(() => `Hello ${noun.state}`);

The implementation will automatically link the message Reactor to the noun Reactor by adding noun to the ancestor array in message and message to the descendants array in noun. Because this relationship is established, the Reactor class will know to invoke message.update() when noun changes its internal state.

const noun = new Reactor('world');
const message = new Reactor(() => `Hello ${noun.state}`);

console.log(message.state); // "Hello world"

noun.state = 'Reactors';

console.log(message.state); // "Hello Reactors"

Dynamic Graphs

The state of the Reactor graph is not static, but rather dynamic. This means that the ancestors for a Reactor is not fixed throughout the life of the Reactor.

const hungry = new Reactor(true);
const food = new Reactor('pancake');
const drink = new Reactor('milk');

const consuming = new Reactor(() => hungry.state ? food.state : drink.state);

In this example, consuming will always have two ancestors: hungry and either food or drink depending on the state of hungry. If hungry is "truthy", then consuming will be linked to changes of food, otherwise it will be linked to changes of drink. The structure of the Reactor graph can change during propagation of state changes.

This dynamism of the graph means that Reactors typically are optimized to react to only the changes which concern them.

Side-effects

A Reactor can be pure with no side-effects if all state within a Reactor's expression function is composed of constants or other Reactors.

const pure1 = new Reactor(() => 23);
const pure2 = new Reactor(() => pure1.state * 2);
const pure3 = new Reactor(() => pure1.state + pure2.state);

Pure Reactors only have access to variable (changing) state that is from other Reactors; only from state within the Reactor graph. In addition, A pure Reactor cannot have side-effects:

// Accessing state outside of the graph is not pure
const notPure1 = new Reactor(() => document.title);
// Producing side-effects is placing state outside of the graph and is not pure.
const notPure2 = new Reactor(() => console.log(otherReactor.state));

Although perfectly legal and legitimate, creating impure Reactors should be handled with care. It is recommended to place these Reactors towards the tips of the Reactor graph. Doing so will improve the dependability of your applications.

Conclusion

Reactors are an awesome new tool at the developer's disposal. It can supplement an existing application's state management needs and it can also act as a replacement for all state management. This is only the beginning for this pattern. I'm excited to see where the community will take this pattern in the future!

Optional Chaining in JavaScript Right Now!

Sam Holmes — Fri, 15 Nov 2019 23:03:33 +0000

In case you don't know what Optional Chaining is, it's the ability to safely access properties of a variable without a reference error.

var obj = undefined
obj?.foo // Returns undefined without throwing an error

This is an experimental JavaScript feature proposal, however, we can use a form of this feature today with the help of the a Proxy object!

Let's define a function which will return a special Proxy object which will prevent references on undefined values allowing us to safely query for properties.

function safe(value){
    return new Proxy({}, {
        get: (_, prop) => {
            if (prop === 'unsafe')
                return value
            else if (value && typeof value[prop] !== 'undefined')
                return safe(value[prop])
            else
                return safe(undefined)
        }
    })
}

Now we can use this function as an alternative to the Optional Chaining Operator like so:

var obj1 = undefined
var obj2 = {foo:23}

console.log(safe(obj1).foo.unsafe) // Returns undefined without throwing an error
console.log(safe(obj2).foo.unsafe) // Returns 23
console.log(safe(obj2).foo.bar.baz.unsafe) // Returns undefined

There is a con to this approach in that unsafe becomes a reserved property within the chain. Though, we can implement a second parameter to the safe function to take care of this edge case:

function safe(value, unsafe = 'unsafe'){
    return new Proxy({}, {
        get: (_, prop) => {
            if (prop === unsafe)
                return value
            else if (value && typeof value[prop] !== 'undefined')
                return safe(value[prop])
            else
                return safe(undefined)
        }
    })
}

That's all for now. Let me know in the comments what you think of this pattern.

I've open sourced this idea as an NPM package: safeunsafe

Cheers!

Reactive Programming in JavaScript

Sam Holmes — Tue, 11 Jun 2019 19:43:30 +0000

Reactive programming is a declarative programming paradigm concerned with the propagation of change. If you'd like a full explanation I'd recommend reading Paul Stovell's article, What is Reactive Programming? In this article, I will show you how you can implement a reactive programming environment in JavaScript.

State as a Graph

In order to accomplish reactive programming in JavaScript, we will need to manage our state on our own and construct a dependency graph for our variables. This way, when a variable's state changes, we propagate that change to all other variables that depend on that state. For example:

a = 10
b = a + 1
c = a + 2

This code would construct the following graph:

   a
  / \
 b   c

The graph's purpose is to establish a dependency relationship between our variables. This way, when a changes, we know to re-evaluate (or update) b and c. In other words, b and c are dependent on a.

We'll implement our graph using an object that maps a dependency variable's reference to a set of dependent references:

let depgraph = {}

depgraph[a] = {b: true, c: true}

To make our lives easier we can create addDependent and removeDependent functions to add and remove dependents in the graph.

// Adds a dependent to the depgraph
function addDependent(dependency, dependent) {
  depgraph[dependency] = depgraph[dependency] || {}
  depgraph[dependency][dependent] = true
}
// Removes a dependent from the depgraph
function removeDependent(dependency, dependent) {
  depgraph[dependency] = depgraph[dependency] || {}
  delete depgraph[dependency][dependent]
}

State

In our program, variables will hold the reference to their state rather than the value of their state. We will use Symbol() to create unique references for our variables. This guarantees that our references don't have any collisions with each other.

However, we will need a place to store the actual values of our variables (a cache). So, we will use an object to map references to values:

let state = {}

state[a] = 10
...

_Notice that a is not a string; this is cause it is equal to a unique Symbol for the variable.

Updaters

Now we need a way to evaluate variables at any point in time. So, we will need to maintain an "updater" function for each variable in order to re-evaluate a variable's state.

let updaters = {}

updaters[a] = () => 10
updaters[b] = () => state[a] + 1
updaters[c] = () => state[c] + 2

You can think of the updaters as storing the right-side expression of the assignment for each variable. Now at any point we can invoke a variable’s updater to retrieve its state.

Let’s bring it all together. We have a graph that maps out the dependency relationships. We have the state stored in a single location. And we have a set of updater functions. When a variable’s state changes, we want to find all of its dependents in our graph and run each of their updater functions in order to get the new state. We of course recursively continue this process for any dependents of those variables as well. To do this, let’s construct a series of functions that will be our reactive programming API.

The API

Our API will consist of a set of functions: declare, bind, update, reorg, retrieve, and remove. To understand how we will be using the API, let’s look at the native JavaScript equivalents to each function:

// Variable declaration
let a = true
// becomes
let a = declare(true)

// Variable assignment
a = false
// becomes
update(a, false)

// Variable assignment (with dependencies)
a = b + 1
// becomes
bind(a, () => retrieve(b) + 1)

// Value retrieval
console.log(a)
// becomes
console.log(retrieve(a))

// Finally, memory deallocation
// JavaScript's GC takes care of this for us,
// but we need to manually release our variables.
remove(a)

The function reorg will be used internally and has no native equivalency.

Let's get into the implementation details of each function.

declare

function declare(expr) {
  if (typeof expr === 'undefined') expr = () => undefined

  let ref = Symbol()

  return bind(ref, expr)
}

This function will allow us to declare a new variable and bind an expression to it using bind. This will replace our native variable declarations with the following:

let a = declare(10)
let b = declare(() => retrieve(a) + 1)
let c = declare(() => retrieve(a) + c)

bind

function bind(ref, expr) {
  updaters[ref] = () => update(ref, expr)
  reorg(ref)
  return ref
}

This function will be used to bind an expression to a reference.

We create an updater for the reference, invoke reorg, and then return the reference. It'll all make more sense as we go along. But the most important thing to note is that the updater is a function that updates the reference with the given expression.

reorg

function reorg(ref) {
  // Remove ref as a dependent to other refs in the graph
  // Effectively detaching it it from the graph
  Object.getOwnPropertySymbols(depgraph).forEach(dependency =>
    removeDependent(dependency, ref)
  )

  // Run the updater and retrieve the dependencies during the update
  let dependencies = updaters[ref]()

  // Update the graph using dependencies
  // Effectively, re-attaching the updated ref to the graph
  if (dependencies) {
    dependencies.forEach(dependency => addDependent(dependency, ref))
  }
}

The purpose of this function is to dynamically maintain dependency relationships between references. In other words, when ever a variable is defined (using declare or bind) we must establish it as a dependent on any variables in its expression.

This function will reorganize the graph given a single reference. First, it will detach the reference from the graph, run its updater function, and then reattach it to the graph. The updater function always returns the reference’s dependencies, so we know how it should be reconnected to the graph.

update

function update(ref, expr) {
  let dependencies

  // Set to object to effectively gather all state retrievals
  stateRecentlyAccessed = {}

  // Execute expression and set actual state
  state[ref] = typeof expr === 'function' ? expr() : expr

  // If statement prevents error (not sure why stateRecentlyAccessed is null sometimes)
  if (stateRecentlyAccessed)
    dependencies = Object.getOwnPropertySymbols(stateRecentlyAccessed)

  // Set stateRecentlyAccessed to null to turn off listening
  stateRecentlyAccessed = null

  // This is where we invoke dependent updaters
  if (depgraph[ref]) {
    Object.getOwnPropertySymbols(depgraph[ref]).forEach(reorg)
  }

  return dependencies
}

Now we get to the core or our implementation. This function will update the state and return all the dependencies of a reference's expression.

This is where you notice stateRecentlyAccessed. I admit that I forgot to mention this global. It should hold the references recently accessed using retrieve. It'll make more sense if we look at the retrieve function.

retrieve

function retrieve(ref) {
  if (stateRecentlyAccessed) {
    stateRecentlyAccessed[ref] = true
  }
  return state[ref]
}

This function simply retrieves the state for a reference, but it also has one side-effect. The side-effect here is modifying stateRecentlyAccessed. Anytime a reference's state is accessed, stateRecentlyAccessed is modified so that it contains a property using the reference as its property accessor. The stateRecentlyAccessed global variable is how update can return a list of dependencies and how the system is able to maintain the variable relationships dynamically.

remove

function remove(ref) {
  // Removes it from state and updaters
  delete state[ref]
  delete updaters[ref]

  // Removes it from depgraph
  Object.getOwnPropertySymbols(depgraph).forEach(dependency => {
    if (dependency === ref) {
      delete depgraph[dependency]
    } else {
      Object.getOwnPropertySymbols(depgraph[dependency]).forEach(dependent => {
        if (dependent === ref) {
          delete depgraph[dependency][dependent]
        }
      })
    }
  })
}

Finally, we need a way to remove a reference and clean up after it. Unfortunately, we can't take full advantage of JavaScript's garbage collector because references are always used in the global variables state, updaters, etc. So, we have to do manual clean up our reference variables using this function. It may be possible to implement a garbage collector of our own, but for simplicity I chose to leave that idea alone.

Using our API

Let's construct an example using our API.

let coordinates = declare('Move your mouse!')
let mouseX = declare()
let mouseY = declare()

bind(coordinates, `${retrieve(mouseX)},${retrieve(mouseY)}`)

document.addEventListener('mousemove', (ev) => {
  update(mouseX, ev.clientX)
  update(mouseY, ev.clientY)
})

declare(() => document.body.innerHTML = retrieve(coordinates))

In this example, we declare a coordinates variable as well as two others: mouseX and mouseY. We bind coordinates to an expression depending on mouseX and mouseY.

After this, we update mouseX and mouseY in the mousemove event. We don't need to use bind in this case because we know they wont have any retrieve() function calls. Using update is a bit more performant because it skips the reorg.

We also declare document.body.innerHTML to be equal to the coordinates. Notice we don't need the reference that this declaration returns. You could however use the reference to access the innerHTML state if it's used in another part of your program. For example,

let innerHTML = declare(() => document.body.innerHTML = retrieve(coordinates))

// Use innerHTML reference somewhere else...

Final Notes

You now have the tools necessary to write reactive programs. Some things to consider doing to improve the implementation:

Better garbage collection.
Use Proxy() to make the API more terse.
Write a transpiler that abstracts away the API altogether.

All in all, I hope this acted as a good introduction to reactive programming.

An Alternative Ternary

Sam Holmes — Fri, 24 May 2019 21:10:20 +0000

Like many languages, JavaScript has the conditional (ternary) operator. What's wonderful about this operator is that it can be nested in expressions and it returns a value. This is a good thing for functional programming and composability.

However, sometimes you don't need the second "falsey" part of the condition, so you end up with a placeholder for the false condition. This is reflected in React/JSX quite often:

return (<div>
  {confirm ? (
    <p>Your action has been done</p>
  ) : (
    ''
  )}
</div>)

It's like forcing the programmer to use else for every time he or she uses if.

The Alternative

The alternative to the ternary operation is to use the && (AND) operation.

return (<div>
  {confirm && (
    <p>Your action has been done</p>
  )}
</div>)

Because the AND operator will short-circuit if the left-operand is falsey, it acts identically to the first part of the ternary operator.

What's even more interesting is that we can combine the AND operator with || (OR) to get the same effect as the ternary operator:

return (<div>
  {confirm && (
    <p>Your action has been done</p>
  ) || (
    ''
  )}
</div>)

This means that we can easily extend a statement with one conditional concern to two concerns.

We don't stop there. We can embed these AND/OR statements just like we could with ternary.

return (<div>
  {isHappy && (
    <p>I'm feeling good</p>
  ) || (
    isHungry && (
      <p>I'm feeling hangry</p>
    ) || (
      <p>I'm feeling sad</p>
    )
  )}
</div>)

As you can see, && and || map to if and else pretty respectively. Wonderful!

Gotchas

A couple of things to note if you decide to use this pattern.

Parentheses are important. The rule is to always wrap your outcome expression: condition && (outcome) || (outcome). Doing so will allow you to nest more conditional expression within the outcome expressions clearly. Note, it is not necessary if you do not intend to nest more conditional expressions.
What the expression evaluates to may not be expected. For example: var selectedItem = selectedItemId && items[selectedItemId] In this case you might be tempted to think that selectedItem === undefined in the case that selectedItemId is falsey. Incorrect. Rather, selectedItem === selectedItemId. This is because an && operation evaluates to the either the last truthy value or the first falsey value (such is the case in the example). Such incorrect expectations should be accompanied with a explicit outcome for a falsey value: var selectedItem = selectedItemId && items[selectedItemId] || undefined

Naming the Pattern

This pattern needs a good name to go by so teams can decide whether to adopt this pattern. Let's go with:

Short-Circuit Conditionals (SCC)