Asynchronous Javascript

Functional Programming Paradigm in Javascript

Functional programming is all about separation of concerns and packaging our code into separate chunks so everything is organised and each part concerns itself with the one thing it's good at. This might sound similar to Object Oriented Programming because they both provide a separation of concerns, but Functional Programming keeps data and functions separate. It is a view of the world where there is data, and then the data is interacted with, but the data and functions are not combined as one piece, or one object. Generally, there will be a focus on simplicity, and the data and methods won't be attached to objects or classes. Functions will operate on well defined data structures like arrays or objects rather than belonging to it.

The goals of Functional Programming are very similar to Object Oriented Programming:

  • Clear and understandable
  • Easy to extend
  • Easy to maintain
  • Memory efficient
  • DRY

When it comes to functional programming, we have a few very important pillars. The key pillar here is pure functions. This maintains the separation between the data of a program and the behaviour of the program, and all objects created in functional programming are immutable.

In modern web development, FP is a very common paradigm seen in major libraries like modern React.js, Next.js, Redux, and more.


//amazon shopping
const user = {
  name: 'Kim',
  active: true,
  cart: [],
  purchases: []
}
// item = {
//   name: 'name',
//   price: 3
// }

const addToCart = (user, item) => {
  item.price += item.price / 100 * 0.03;
  user.cart.push(item);
}

const purchaseItems = (user) => {
  user.cart.forEach((item, index) => {
    user.purchases.push((item));
    user.cart.pop(item);
  })

}

// implement a cart feature
// 1. add items to cart
// 2. add 3% tax to item in cart
// 3. buy item: cart  --> purchases
// 4. empty cart

// bonus:
// accept refunds
// track user history

Pure Functions

Let's have a look at the first key pillar, pure functions. Pure functions are a function that will always return the same output, given the same input, and it cannot modify anything outside of itself. No side effects. Here's an example to show the difference between pure and impure functions:

const array = [1,2,3]

// impure function, mutates array
function mutateArray(arr) {
  arr.pop() // changes the array that is passed into the function
}

// impure, mutates array.
function mutateArray2(arr) {
  arr.forEach(item => {
    arr.push(1);
  })
}

// With these functions that mutate our data, it can be unclear what is happening with our end result of the array so we have to look through the whole thing line by line to find out
// in a large code base this can make things very messy quickly

Here we have impure functions which will take our array, and modify it. In large codebases like this it can quickly become very messy and hard to find why our data ends up the way it is, can become very buggy, and overall hard to debug. We would have to go line by line through all of our code that touches the data to find out what is happening. Let's try to make this a little nicer using pure functions:

const array = [1,2,3]

// returns a new array instead of modifying the old data.
// only modifies data within its own scope
function removeLastItem(arr) {
  const newArray = [].concat(arr);  // make a new array and concat the values into it, as objects are passed by reference in javascript and we don't want to modify the original array
  newArray.pop();
  return newArray
}

function multiplyBy2(arr) {
  return arr.map(item => item*2)
}

console.log(removeLastItem(array));
console.log(multiplyBy2(array));
console.log(array);

In the above example, we now have two functions that take data, but only modify the properties within their own local scope. Each function will return a new array instead of modifying the existing one. This means that there will never be any side effects when data is passed into the function. Each of our logs at the end are returning three separate arrays using the data from the original array without modifying it. Because we have no shared state between these functions, we are able to write code that helps us avoid bugs, we have very predictable and testable code.

So can we have practical code that is 100% pure with no side effects? Having no side effects means code that will only ever affect data within its own scope. Philosophically this means that any input and output of data is actually a side effect itself, so if we're ever outputting our values somewhere, even just console logging it, it would become impure technically. So the answer is no, because you cannot have a program that runs without any side effects and does something like interacting with a browser. Our goal isn't to have code that is 100% pure, but rather to keep as much of it pure as we can. Our goal is to minimise side effects and organise our code with specific parts that have side effects, but keeping the rest of it pure, simple. and reusable. Purity in this way helps us to maintain our code easier and isolate api calls, database calls, input, and output so our code becomes more predictable.

In functional programming, a function should:

  • Only have one task.
  • Always return something. If we input data, we expect it to output data.
  • should be pure.
  • have no shared state.
  • have an immutable state.
  • be composable.
  • be predictable.

Let's break this down a little and go into some of the core concepts that help us write our functions to fit this criteria.

Idempotence

Idempotence is a concept that is important for Functional Programming. It means that when we give a function the same inputs, we will get the same expected output.


// not idempotent as it will not return the same result
function notGood(num) {
  return Math.random(num)
}

notGood(5);

This is an important and useful concept that you see in http requests, and is very important for parallel and distributed computation as it makes our code predictable. If we run the same function 1000 times we will always get the same result.

Imperative vs Declarative Code

Imperative code is code that tells the machine what to do and how to do it. Declarative tells it what to do and what should happen. It doesn't tell the computer how to do things. Computers are naturally more imperative. We have to tell them how to do things. Humans on the other hand tend to be more declarative, meaning we can just tell people what we'd like them to do and they can figure out how to do it. For example if we ask someone to fetch us a glass of water we don't have to tell them to walk over to the nearest source of water, to grab a cup, to fill the cup, to bring it to us in their hand, and then hand it directly to us. But we would have to tell a computer how to do all of these things very precisely. The most obvious case of imperative programming is with assembly or machine language, in which we have to tell the machine exactly where in memory we want to put our data. As we move to higher and higher level languages, the code tends to become more declarative, we can for example declare a variable and assign its value but we don't need to tell the machine exactly how to do this in memory. Another example can be found in basic loops:


// imperative, we have to tell it our full range of indexes, to increment through the loop, and so on.
for (let i = 0; i < 1000; i++) {
  console.log(i);
}


// a little more declarative, we don't have to tell it to increment through our range
[1,2,3].forEach(item => console.log(item));

In web development, jQuery is an example of very imperative code. We generally had to tell our browser every dom manipulation we wanted, and how to do it. Compared to something like React where we don't have to manipulate everything directly, we simply tell it what we want and what should happen, which is much more declarative. Functional programming tends to lean towards being more declarative compared to imperative. While at the end of the day, all of our code will be compiled down into instructions for the computer to follow, but for our code we can make it declarative for human clarity and ease of understanding.

Immutability

Immutability is a very important concept. It means not changing our data or state. In Functional Programming instead of changing our state, we want to make copies of the state and return a new state each time we want to make a change.



const obj = {name: 'Tim'}

// pure function
function clone(obj) {
  return {...obj};
}

// function to update the name without mutating the original object
function updateName(obj, name) {
  const obj2 = clone(obj);
  obj2.name = name
  return obj2
}

const updatedObj = updateName(obj, 'bob');
console.log(obj, updatedObj);               // here we can see that we have two objects now. The original object is still in tact, but we have an updated object with the new name that we can use also.

Looking at this, someone might ask whether or not this is memory efficient, given we are making copies in memory when we want to change the state. When it comes to Functional Programming, most data structures like arrays or objects follow what is called Structural Sharing. This means that under the hood, only the changes made to the state are taking up new memory. The original values are actually not repeated in memory, so it is more like we are just borrowing those values. Thanks now to memory being fairly cheap and readily available in computers, this is not a big worry, especially with under the hood optimisations.

Higher Order Functions and Closures

While we have already covered the topics of Closures in a previous post, it is important to go over them again briefly as well as going into Higher Order Functions in javascript when it comes to Functional Programming. The key concept in javascript that makes this very important is that functions are treated as first class citizens.

Higher Order Functions are functions that takes one or more functions as arguments, or returns a function as a result, also known as a callback.


// Higher Order Function
const hof = () => () => 5;
hof() // returns function that returns the value of 5
hof()() // returns value of 5

// takes a function as an argument
const hof2 = (fn) => fn(5);
hof2(function a(b) { return b })  // returns value of 5

Because functions are first class citizens and we can do higher order functions, this means we can also do closures. Like objects, closures are a way to contain some sort of state. In javascript we create a closure whenever a function accesses a variable outside of its immediate scope. It is fairly easy to do this by defining a function within another function, and expose the inner function by returning it or passing it to another function.


const closure = function() {
  let count = 0;
  return function increment() {
    count++
    return count;
  }
}

const incrementFn = closure();
incrementFn(); // returns 1
incrementFn(); // returns 2

Here we can see that the increment function has access to its parent functions scope, and can increment the count variable. This example does not follow our Functional Programming principles as we have made a function that is impure and is modifying a state outside of its own scope, but we can still follow these concepts with closures and they can be really useful to access data outside of the functions own scope. This example would be closer in line with our principles:



const closure = function() {
  let count = 5;
  return function getCounter() {
    return count;
  }
}

const getCounter = closure();
getCounter();

By doing this, we have now created private variables, where our count variable is now private data and cannot be readily changed, but we can still access the data. This is a key way in which closures are used for Functional Programming in javascript. We just have to be careful not to modify the state.

Currying

Currying is a technique that translates the evaluation of a function that takes multiple arguments into evaluating a sequence of functions, each with a single argument. This sounds confusing but we can think of it like this: we take a function that can take multiple parameters, and using currying we modify it into a function that takes one parameter at a time.


// basic function
const multiply = (a, b) => a*b;
multiply(3,4)


// how do we get this to take one parameter at a time?
const curriedMultiply = (a) => (b) => a*b;    // because of closures we have access to our 'a' variable inside of the 'b' function

curriedMultiply(5)(3);

// but how is this useful? Well, now we can create multiple utility functions out of this
const curriedMultiplyBy5 = curriedMultiply(5);

// we now have a function that will always multiply our number by 5 no matter what, as it has access only to the '(b) => a*b' part of the multiply function

Partial Application

Partial Application is a concept that sometimes gets confused with currying due to their similarities, though they are different concepts. Partial Application is a way for us to partially apply a function, and a process for us to produce a function with a smaller number of parameters. So we take a function, apply some of its arguments so the function remembers the parameters, and then it uses closures to be called with all the rest of the arguments. Suppose we wanted to use partial application to extend the above example to have 3 parameters to multiply. This is how it could look:

// currying

const multiply = (a, b, c) => a*b*c;
const curriedMultiply = (a) => (b) => (c) => a*b*c;
curriedMultiply(3)(3)(10) // returns 90


// partial application on the other hand says "I want you to call the function once, then apply the rest of the arguments to it. So on the second call we expect all the arguments"

const partialMultiplyBy5 = multiply.bind(null, 5) // the null here is just because we don't care about "this" here. 5 is an additional argument.

// Second call
partialMultiplyBy5(5, 10);  // returns 250. This is because the partial function value of 5 applies to the 'a' parameter. The values we then pass in apply to the b and c parameters respectively.

There we can see the difference. In our partial application, on the second call we expect all of our arguments. Currying in contrast expects one argument at a time. We'll later go over this concept to show a more practical use case.

Composition

While we've already covered a lot of topics and we can't necessarily see easy ways to use or combine these, we'll have to go over a few more before we can tie it all together. Composition in FP is the idea that any data transformation we do should be obvious. We can picture this almost like a conveyor belt where we have data which is then processed by a function, and so on until we have finished our objective. A highly composable system means we can easily select and assemble our functions in various combinations like an assembly line, and thus get different outputs depending on our specific needs. One key way we can use composition in javascript isn't provided natively, but is provided by many popular libraries such as Ramda. This gives us the compose() function. Say we want a function that will let us take a number and multiply it, but it must always return a positive value. Let's take a look at an example of this:



// build our own compose function, taking two functions and some data
const compose = (f, g) => (data) => f(g(data))  // 'f' is Multiply by 3, so we first want to make our data positive with 'g', and then use f to multiply by 3

const multiplyBy3 = (num) => num*3;
const makePositive = (num) => Math.abs(num);

const multiplyBy3AndAbsolute = compose(multiplyBy3, makePositive);

multiplyBy3AndAbsolute(-100) // returns 300

Here we can see that we've made our own compose function to combine two functions together. We can also change the order of operations here by putting the functions in a different order for our arguments. Because all of our functions are pure and composable, we can always do this. One thing we can notice here is that with our compose function our order of operations is always right to left. Another concept here is called "Pipe". Pipe means that we will be doing these with the reversed order of operations where the order of operations are left to right. Otherwise it is effectively the same concept.



fn1(fn2(fn3(50)));
compose(fn1, fn2, fn3)(50)  // take our data, then apply fn3, then fn2, then fn1
pipe(fn3, fn2, fn1)(50)  // take our data, then apply fn3, then fn2, then fn1
// here both will do the same but with a different order of operations for our arguments.

Arity

Our final term you might come across with Functional Programming and composition is Arity. Arity simply refers to the number arguments a function takes. Although this isn't a solid rule, generally the fewer number of parameters the easier it is to use a function. That way we can mix our functions a little easier with currying and composition. There's no hard right and wrong for arity, but keeping it low makes a function easier to understand and more reusable keeping in line with our core principles.

Practical Example

So now that we've covered a lot of the key principles of Functional Programming we can probably see why this is exciting. While it may look a lot like math (which it is based on), it gives us a good degree of separation which makes large codebases come together very nicely, and makes them easier to read and understand while reducing bugs because everything is predictable and easily tested with unit tests. This doesn't make it perfect for all use cases however, such as creating games where Object Oriented Programming is much easier to understand. In cases where we're doing a lot of processing directly with data, Functional Programming is extremely useful. Let's make an example shopping cart using these principles we've covered:



// Make an online shopping cart
// 1. Add items to cart
// 2. Add 10% gst to items in cart
// 3. Move items from cart to purchases when bought
// 4. empty cart

const user = {
  name: 'Kim',
  cart: [],
  purchases: []
}

// use a pipe function to connect everything together, is a lot easier if we use a library like ramda
const pipe = (f, g) => (...args) => g(f(...args));

function purchaseItem(...fns) {
  return fns.reduce(pipe)
}

function addItemToCart(user, item) {
  const updateCart = user.cart.concat(item)
  return Object.assign({}, user, {cart: updateCart}) // return new user state instead of modifying original state
}

function applyTaxToItems(user) {
  const { cart } = user;
  const taxRate = 1.10;
  const updateCart = cart.map(item => {
    return {
      name: item.name,
      price: item.price*taxRate
    }
  })
  return Object.assign({}, user, { cart: updateCart })
}

function buyItem(user) {
  return Object.assign({}, user, { purchases: user.cart })
}

function emptyCart(user) {
  return Object.assign({}, user, { cart: []})
}

purchaseItem(
  addItemToCart,
  applyTaxToItems,
  buyItem,
  emptyCart
)(user, {name: 'chair', price: 350})

So here we have a shopping cart where everything works with piping and with pure functions. If we ever need to add new functionality, we can just add new functions in there and the original functions won't need to be changed. This is a pattern we'll see commonly in libraries such as Redux for React, allowing us to share and act upon data between components. This is an increasingly common paradigm in web development, but overall because javascript is a fairly flexible language we can choose between OOP and FP paradigms to suit our particular projects requirements.