Forem: Aaron Thompson

Closure & Common Use Cases

Aaron Thompson — Wed, 28 Oct 2020 18:08:54 +0000

A closure is a function bundled with its lexical environment

JavaScript is a lexically scoped language. This means that functions use the variable scope that was in effect when they were defined (not the variable scope in effect when they are invoked).

Technically, all JavaScript functions are closures, but because most functions are invoked from the same scope they were defined, it doesn't matter that there was a closure involved.

Closures are commonly used for encapsulation (the ability to have private properties for objects), functional programming (curried functions, partial applications) and to grant access to variables inside event listeners.

Let's take a look at each of these use cases to help us understand what closure is.

Encapsulation

Say we had a factory function that returned a counter object:

const counter = () => ({
    n: 0,
    count() { this.n++ },
    reset() { this.n = 0 }
})

const counter1 = counter();
counter1.count();
counter1.count();
console.log(counter1.n) // 2
counter1.n = 0; // << We don't want this
console.log(counter1) // { n: 0, ... } uh oh!

Buggy or malicious code could reset the counter without calling the reset() method as shown above.

As mentioned in my post on encapsulation, this breaks a fundamental principle of good software design:

“Program to an interface, not an implementation.” — Gang of Four, “Design Patterns: Elements of Reusable Object-Oriented Software”

We only want to be able to communicate with counter by using its interface and by passing messages (methods) such as count() or reset(). We don't want to be able to reach in and manipulate properties such as n directly. Unfortunately, the property n forms part of the public interface for this object and so it is easily manipulated. Let's change that. Closure can help us out here. Take a look at this revised example:

const counter = () => {
  let n = 0;
  return {
    count() { n++ },
    reset() { n = 0 },
    getCount() { console.log(n) }
  }
}

const counter1 = counter();
counter1.count();
counter1.count();
counter1.getCount() // 2
console.log(counter1.n) // undefined

Before we dissect this. Reconsider our definition of closure - a function bundled with its lexical environment. The lexical environment being the variable scope that was in effect when the function was defined.

n is in scope when count, reset and getCount are defined and so, when counter returns and the object is created, the only code that will have direct access to n is this instance of the counter object and the methods on it.

Note that the reference to n is live and each invocation of counter creates a new scope independent of scopes created by previous invocations and a new private variable within that scope. So what is n for counter1 may not the what is n for counter2.

Partial application

A partial application is a function that has been applied some but not all of it's arguments. Let's look at an example:

const trace = label => value => {
  console.log(`${ label }: ${ value }`);
};

trace is a function that takes a label and a value and logs it to the console.

Because this function is curried we can create specialist 'sub-functions' that are partial applications of the full trace function:

const traceLabelX = trace('Label X')

console.log(traceLabelX.toString()) // 'value => {console.log(`${label}: ${value}`);}'

traceLabelX(20) // 'Label X : 20'

If you log traceLabelX to the console you see it return a function that takes in a value and logs the label and the value. But where is label? This function's closure has access to the label it was returned with anywhere it is now used.

Event listeners

Open up VSCode and make this little .html page and open it up in a browser.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    Closures in event listeners
  </body>

  <script>
    const body = document.body;
    const initButtons = () => {
      let button;
      for (var i = 0; i < 5; i++) {
        button = document.createElement("button");
        button.innerHTML = "Button " + i;
        button.addEventListener("click", (e) => {
          alert(i);
        });
        body.appendChild(button);
      }
    };
    initButtons();
  </script>
</html>

What do you think happens when you click on the buttons? Each button click will return an alert with '5'. Why is this? The first thing to note here is that we are using var not let to declare i. As such this is a bit of a contrived example as you would very rarely use var for variable declaration these days but stick with me as it will help you understand closures. Remember - var is function scoped and let is block scoped.

The for loop is within the initButtons function and var is 'hoisted' to the top of the function.

Every time a loop completes a button is created with an attached event listener who's callback has reference to i. As subsequent loops complete, i updates, as too does each event-listeners reference to it. This is the problem, every closure has access to the same reference to i.

We could fix this in a couple of ways:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    Closures in event listeners
  </body>

  <script>
    const body = document.body;

    const initButton = (name, alertMessage) => {
      button = document.createElement("button");
      button.innerHTML = "Button " + name;
      button.addEventListener("click", (e) => {
        alert(alertMessage);
      });
      body.appendChild(button);
    };

    for (var i = 0; i < 5; i++) {
      initButton(i, i);
    }
  </script>
</html>

Each event listener is now scoped to the alertMessage param which is defined on function invocation.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    Closures in event listeners
  </body>

  <script>
    const body = document.body;

    const initButtons = () => {
      let button;

      for (let i = 0; i < 5; i++) {
        button = document.createElement("button");
        button.innerHTML = "Button " + i;
        button.addEventListener("click", (e) => {
          alert(i);
        });
        body.appendChild(button);
      }
    };
    initButtons();
  </script>
</html>

Or just use let instead of var within the loop. Using let will ensure that each iteration of the scope has its own independent binding of i.

Has this helped you understand closure? Let me know in the comments!

References

https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-closure-b2f0d2152b36#.11d4u33p7
https://medium.com/javascript-scene/curry-and-function-composition-2c208d774983
JavaScript: The Definitive Guide, 7th Edition by David Flanagan

Function Composition

Aaron Thompson — Wed, 28 Oct 2020 13:22:53 +0000

All of software development is composition. The breaking down of huge problems into smaller pieces and stitching them together so that, not only are the smaller problems solved independently of each other but they work together to solve the bigger problem. JavaScript Applications mix functional programming and object-oriented programming extensively. We make objects for our functions and functions can make more objects.

The breaking down of problems into smaller problems and stitching them together (from a functional perspective) is the topic of this post. How you do it matters for your growing codebase.

Composing Functions

What does it mean to 'compose' functions? Take a look at the below example:

import { doSomething, doSomethingElse, createFinalData } from "./functions";

// Composing example 1
const doALot = (data) => {
  const editedData = doSomething(data);
  const furtherEditedData = doSomethingElse(editedData);
  const finalData = createFinalData(furtherEditedData);
  return finalData;
};

const result = doALot(someData);

// Composing example 2
const pipe = (...fns) => (x) => fns.reduce((y, f) => f(y), x);

const doALot = pipe(doSomething, doSomethingElse, createFinalData);

const result = doALot(someData);

Before we move on, let's breakdown that pipe function as I found it hard to understand at first.

pipe takes a list of as many functions as you like and gathers them together into an array called fns. That's what the rest (...) operator is doing.
Passing a list of functions returns another function that takes an initial value (which above is someData). fns is then iterated over using .reduce and each function is applied to the output of the one before it.

As you can see from the two examples, in both cases we are passing data down a 'pipeline' to be transformed. Even if perhaps a little unfamiliar, the second example is objectively better because we eliminate wiring and connectivity code. pipe implicitly passes the return value to the next function and reduces the surface area of our code. Less surface area means less chance for bugs, less syntactical 'noise', and less cognitive load when reading.

The implementation details of the functions in the pipeline above are hidden for the simplicity of the example, but you can see that they all take one input and return one output. This output is then passed to the next in line. What if doSomething needed 2 parameters? Can we still use pipe like above? Yep! Keep reading.

To learn how to compose functions like this we need to understand currying.

Currying

Normally a function might expect multiple parameters like this:

const add3 = (a, b, c) => a + b + c

add3(1,2,3) // 6

A curried version of this function would look like this:

const add3 = (a) => (b) => (c) => a + b + c

add3(1)(2)(3) //6

You can see here that a curried function takes its arguments one at a time but ends up with the same result.

The reason that curried functions are so convenient is that they transform functions that expect multiple parameters into functions that accept one arg at a time. This means that they can fit into functions composition pipelines like pipe in our example above.

A function can take any number of inputs, but can only return a single output. For functions to be composable, the output type must align with the expected input type:

f: a => b
g:      b => c

What if g was expecting two inputs?

f: a => b
g:      (x,b) => c

How would we introduce x? We would have to curry g. Going back to our doSomething example. If it in fact, required 2 parameters, we could define it something like this:

const doSomething = (data1) => (data2) => {/* something */}

Note that it is not enough to simply curry. You need to make sure the functions take the parameters in the right order. This is often called the data-last approach whereby the application is gradually 'specialized' and the data is passed last to provide the result.

What do you think of function composition like this? Let me know in the comments.

References:

Objects and how to make them

Aaron Thompson — Wed, 28 Oct 2020 00:54:03 +0000

I've recently been trying to get my head around how to make objects in JavaScript (specifically, many of them), as well as understanding .prototype, __proto__, prototypal inheritance vs class inheritance, and object composition. It's quite a deep subject and this blog post probably scratches the surface but I hope it helps you understand it a little better too.

I'll start by looking at how we make one object and how this evolves to a factory function, constructor function, and classes. Then we'll look at why you might want to favor certain methods.

These thoughts aren't my own, rather an amalgamation of what I've learned elsewhere. What you are about to read, I sourced from the following references. If you don't quite get everything you need from this post I'd encourage you to dig into these:

Just one

This is how we make an object in JavaScript:

const name = "Aaron";

const thing = {
  name,
  setName(name) {
    this.name = name;
    return this;
  } 
}

It's called an object literal. Note the use of shorthand syntax here too. This reads the same as:

const thing = {
  name: "Aaron",
  setName: function(name) {
    this.name = name;
    return this;
  } 
}

Great, we can make one, what about more than one?

Factory functions

We could envisage creating a function to make lots of objects looking a bit like this:

function Thing(name) {
  const thing = {};
  thing.name = name;
  thing.setName = function (name) {
    this.name = name;
    return thing;
  };
  return thing;
}

const thing1 = Thing("Aaron");

This is a factory function. It can be written in a couple of different ways including arrow function syntax (more on that later).

Imagine that every instance of Thing has a setName method. As such, ideally, we would want all instances of Thing to share the same setName method. We could achieve that like this:

const sharedThingMethods = {
  setName(name) {
    this.name = name;
    return this;
  },
};

function Thing(name) {
  const thing = Object.create(sharedThingMethods);
  thing.name = name;
  return thing;
}

const thing1 = Thing("Aaron");

Object.create() is the key here. It creates a new object and uses it's argument as the delegated object for failed lookups. So, say you did thing1.setName("new name"), JavaScript will look to sharedThingMethods for the setName() method as it doesn't exist on the instance of Thing.

As it turns, out JavaScript has a built in way of doing the above and it's the functions .prototype property.

What is prototype?

For this bit you will need a browser window open and dev-tools at the ready. No, seriously, don't just read it 😉.

Copy and paste the Thing function into the console and then, console.dir(Thing). This will list all the properties of the Thing function object and you should have something like below.

Check out prototype: constructor: f Thing(name). What is this and how does it relate to our sharedThingMethods?

All functions (defined with the function key word - more on this in a bit) have a .prototype property that references an object. This object has a .constructor property that refers back to the function it belongs to. Turns out, this prototype object functions in more or less the same way as sharedThingMethods. As it stands, as you saw in your console, Thing isn't making use of it's prototype, let's change that.

function Thing(name) {
  const thing = Object.create(Thing.prototype); // <<< This bit changes
  thing.name = name;
  return thing;
}

Thing.prototype.setName = function (name) {
  this.name = name;
  return this;
};

const thing1 = Thing("Aaron");

Now, on failed lookups, instead of being referred to the sharedThingMethods object we will be referred to the prototype. We now have a situation like this:

Note setName on the functions .prototype and the instances __proto__.

You could also picture it like this:

Every instance of Thing has a __proto__ property that refers to the Functions .prototype. setName is shared among all instances of Thing via the function's prototype.

Factory functions 3 ways

So we understand that we can create a factory function to make lots of objects and we also understand what role the factory functions prototype plays in that. But, what happens when you use an Arrow function to define your factory function?

These three factory functions are almost identical, but there's a slight difference, can you tell?

// Factory 1 (the one we have already been looking at)
function Thing(name) {
  const thing = Object.create(Thing.prototype);
  thing.name = name;
  return thing;
}

Thing.prototype.setName = function (name) {
  this.name = name;
  return this;
};

const thing1 = Thing("Aaron");

// Factory 2
const proto = {
  setName(name) {
    this.name = name;
    return this;
  },
};

const Thing = (name) => {
  const thing = Object.create(proto);
  thing.name = name;
  return thing;
};

// Factory 3 ()
const Thing = (name) => ({
  name,
  __proto__: {
    setName(name) {
      this.name = name;
      return this;
    },
  },
});

What the hell is going on here? Why, with 'factory 2' does it look like we are going back to manually setting a prototype object and what's with the __proto__ in factory 3?

In summary: all these functions employ prototype delegation, they just do it differently. The first two are functionally equivalent - they share a single prototype between all instances. The last is different in memory usage. It creates a new prototype for each instance.

That's a lot of words, let's elaborate.

Arrow functions do not have a .prototype property, meaning they cannot be used as constructor functions (more on constructors in a bit) but they can be used as factory functions like above. Looking at factory 2, the lack of .prototype means you must delegate a prototype object yourself and pass it to Object.create(). Whether you go for factory 1 or 2 is completely a matter of preference but they both behave the same.

Factory 3 is different in that, is does create a prototype by defining __proto__ but it creates a new prototype for every instance created and lacks the memory saving benefit the other 2 have. So what is the point of the prototype in factory 3? Say we want to iterate over our Thing instance using something like Object.keys(thing1), we may wish to exclude methods like setName from this operation. Because some properties are common among all instances, including them may create unwanted 'noise' with little meaning. Putting them on the __proto__ property hides them from view.

From factory to constructor

So we've looked at factory functions, how they can be used to make multiple instances of objects, how we can create a prototype chain for delegation for object property lookups and how that might look difference depending on how you write your factory functions. Now let's look at how JavaScript adds some syntactical sugar to this whole process with constructor functions and classes.

A function is a constructor function if it is invoked with the new keyword i.e. const thing1 = new Thing("Aaron"). Transforming our factory function into a constructor function we can omit a few lines.

function Thing(name) {
  // const this = Object.create(Thing.prototype);
  this.name = name;
  // return this
}

Thing.prototype.setName = function (name) {
  this.name = name;
  return this;
};

const thing1 = new Thing("Aaron");

With a constructor function, the two lines that are commented out above are done for you implicitly. Note the object created is called this and is implicitly returned for you.

From constructor to class

Just a pinch more syntactical sugar with the class keyword leads us to this:

class Thing {
  constructor(name) {
    this.name = name;
  }
  setName(name) {
    this.name = name;
    return this;
  }
}

const thing1 = new Thing("Aaron");

It's important to note, this is functionally equivalent to the constructor function above. It just looks different.

Factory functions vs constructors vs classes

This post has worked through factory functions to constructors to classes, but let's take a step back and look at when we might use one over the other.

Classes are the same as constructor functions with a little more syntactical sugar. So, the pros and cons of constructor functions also apply to classes.

Constructors force callers to use the new keyword. Factories don't. That's the only difference but this does have some side effects.

Factory functions are sometimes regarded as an upgrade to constructor functions and is actually a common refactoring pattern.

Just to recap - the usage of the new keyword causes JavaScript to automatically create a new object, set this within the function to that object and return the object. This does not happen automatically in a factory function. You need to tell a factory function what to return (in most cases the new object) but this does add for a little more flexibility.

function ConstructorThing(name) {
  this.name = name;
}
ConstructorThing.prototype.setName = function (name) {
  this.name = name;
  return this;
};

function factoryThing(name) {
  const obj = {
    name,
    setName(name) {
      this.name = name;
      return this;
    },
  };
  // Other code to manipulate obj in some way here
  return obj;
}

The fact that we can include other code to manipulate the object in some way and define the object to be returned means that the return value could vary based on parameters.

This flexibility is also beneficial from an encapsulation perspective. Consider the following factory function:

function createWallet() {
  const balance = 0;

  function privateMethod() {
    console.log("do a private thing");
  }
  function add() {
    console.log("add");
  }
  function empty() {}

  return Object.freeze({
    add,
    empty,
  });
}

Only the methods we expose in the return are public. Everything else is encapsulated.

By default class (and by extension constructor) properties are public and can be examined or modified outside the class. That being said, private fields are available in classes as an experimental feature.

Classes and constructors can create problematic hierarchies that lead to well-known problems in object oriented design, including fragile base classes, the 'gorilla banana problem' and the duplication by necessity. By using factory functions you can adopt an approach where composition is favored over inheritance but that's a huge topic for another blog post!

This is a huge topic and I'm looking forward to writing about it some more. I'm still learning so, as always, any constructive comments are appreciated.

Code Encapsulation

Aaron Thompson — Sun, 25 Oct 2020 18:52:38 +0000

Recently I've been trying to become a better software engineer and programmer and something I’m trying to get my head around is how to 'encapsulate' your code well. Encapsulation produces code that has loose coupling but high cohesion. Capsules of your code work seamlessly together but also independently of each other.

As put by Eric Elliott here, the encapsulation of code is the bundling of data and the methods that act on that data such that access to that data is restricted from outside the bundle. It's the local retention, hiding, and protection of state processes.

Code that is well encapsulated keeps in mind three timeless principles in software engineering:

Avoid shared mutable state. “Nondeterminism = parallel processing + mutable state” — Martin Odersky, designer of the Scala programming language
“Program to an interface, not an implementation.” — Gang of Four, “Design Patterns: Elements of Reusable Object-Oriented Software”
“A small change in requirements should necessitate a correspondingly small change in the software.” — N. D. Birrell, M. A. Ould, “A Practical Handbook for Software Development”

I'm still getting to grips with what these quotes truly mean and practicing them in my work but let's outline each in turn briefly to try shed some light:

First off, shared mutable state. This is where different parts of your code depend on the same data and that data is permanently modified by these parts. The input of one thing might depend on some state that is also modified by something else. If your program decides to run in a different order or parts run at the same time, chaos ensues! The results are unpredictable. Sometimes it works and sometimes it doesn’t.

Secondly, programming to an interface. This, from what I understand is programming by message passing. Message passing means that, instead of updating an object's properties directly, you call one of its methods and it might do what you want. This idea of encapsulating your code behind a public interface is interesting because it also addresses the third point above: "A small change in requirements should necessitate a correspondingly small change in the software". When you program like this it means that other code is not linked to implementation details. It just knows what message to pass.

Ok so we sort of know what encapsulation means but what does it look like in JS. Let's see a simple example:

Factory functions + Closures

In this example, the accountBalance is encapsulated within the createPerson factory function and can only be manipulated by calling pay() and getBalance() .

These are privileged methods which means they have access to the private data inside the containing function's scope, even after the function has returned. The references are also live, meaning that if the accountBalance changes it will change for every privileged function with access to it.

const createPerson = ({name = "thing", age = 20} = {}) => {
  let accountBalance = 10

  return {
    pay: () => accountBalance++,
    getBalance: () => accountBalance.toLocaleString()
  }

}

const person = createPerson()
person.pay()
console.log(person.getBalance()) // '11'

This is a very simple example of such an important concept but it highlights how certain data and code can be hidden behind a public interface and can only be manipulated by passing messages to the object instance created.

References:

https://medium.com/javascript-scene/encapsulation-in-javascript-26be60e325b4