DEV Community: Diego Palacios Lepore

Memoization in JavaScript

Diego Palacios Lepore — Wed, 24 Apr 2024 10:11:39 +0000

Following my previous post about closures in JavaScript, I wanted to continue the conversation and talk about memoization, which is a performance optimization technique that leverages closures.

Memoization relies on function purity. Pure functions consistently return the same output for identical input arguments. Memoization enhances efficiency by caching these arguments along with the output they generate. When these arguments are passed again, the function retrieves the result from the cache instead of recalculating it. This is basically why memoization is ideal only on pure functions, but this will be clearer as I illustrate the concept in the following example.

Consider a basic function to calculate the sum of numbers:

function sumNums(...nums) {
  return nums.reduce((total, num) => total + num, 0);
}

console.log(sumNums(1, 2, 3)); // Output: 6

Now, imagine that instead of a straightforward operation like summing three numbers, we're dealing with a more complex function that uses recursion and challenging computations. In such cases, memoization is particularly valuable.

In our example, memoization optimizes the function by ensuring that the arithmetic operation is performed just once. This is achieved by storing 1, 2, 3 as the key and 6 as the value in an object that acts as the function’s cache. In my demonstration, I'll use an object for the cache, but you can choose any data structure that best suits your specific needs and preferences.

Let's define a memo function that takes another function and memoizes it, and then let's memoize our sumNums function:

/**
 * Memoizes a function to cache its results based on the arguments provided.
 * If the result for a given set of arguments is already in the cache, it retrieves it from there.
 * Otherwise, it calculates the result, stores it in the cache, and returns it.
 *
 * @param {Function} fn - The function to be memoize.
 * @returns {Function} The memoize function.
 */
function memo(fn) {
  const cache = {};

  return (...args) => {
    // Generate a unique key based on arguments to store function results
    const key = JSON.stringify(args);

    // Check if the result is already cached
    if (cache[key]) {
      return cache[key];
    }

    // Calculate the result and cache it if it's not already cached
    const result = fn(...args);
    cache[key] = result;
    return result;
  };
}

// Create a memoize version of the sumNums function
const memoizedSumNums = memo(sumNums);

console.log(memoizedSumNums(1, 2, 3)); 
// Calculates and returns 6

console.log(memoizedSumNums(1, 2, 3)); 
// Fetches and returns 6 from cache without recalculating

I encourage you to try it out by memoizing different functions. For instance, you could try memoizing a fibbonacci function. And then you can compare how fast it runs with and without memoizing it.

To wrap up, memoization is a powerful technique for boosting the efficiency of pure functions by avoiding unnecessary recalculations, and enhancing performance. However, while memoization can significantly cut down on processing time, especially in scenarios involving complex tasks, it does so at the cost of increased memory usage.

As results are cached, memory consumption can grow, depending on the number and size of the cached results. This trade-off needs careful consideration, particularly in environments where memory is limited.

Opt for memoization when the benefits of reduced computation outweigh the costs of additional memory usage. This way, your functions not only run faster but also remain efficient in their use of system resources, keeping your code optimized and maintainable.

A Practical Introduction to Closures in JavaScript

Diego Palacios Lepore — Fri, 05 Apr 2024 23:06:33 +0000

Closures are a very interesting topic, and it is a demonstration of how to leverage the lexical scope in JavaScript.

Let's start by showing a code example first:

function outerFunction() {
  let count = 0;

  return function innerFunction() {
   count += 1;
   console.log(`Count is now ${count}`)
  }
}

Before adding more code, I think it is important to mention that when a function is invoked, after doing its stuff and returning its output, all the variables and functions and any data inside that function will be completely gone.

So, one might think that, if that's the case, the count variable will dissapear right after outerFunction is invoked, and the returned function will lose access to the count variable.

But, due to the lexical nature of JavaScript, when a function is created, like innerFunction in this case, it will always be returned along with its scope.

Even after the outerFunction has finished executing, the innerFunction retains access to the variables in its outer scope, allowing it to keep data private and alive throughout the lifecycle of the application.

Let's continue with our example above:

function outerFunction() {
  let count = 0;

  return function innerFunction() {
   count += 1;
   console.log(`Count is now ${count}`)
  }
}

const myFunction = outerFunction() // outerFunction is executed and, and myFunction becomes innerFunction

myFunction() // Count is now 1
myFunction() // Count is now 2
myFunction() // Count is now 3

So basically functions can carry with them the scope in which they were created. This includes any variables or fucntions that were in scope at the time of creation.

So as you can see, when we return innerFunction from outerFunction, we're not just returning the innerFunction code, we're returning a package of the function and its scope, and this scope that gets returned along with the function, and to which the function keeps access to, is what we call a closure.

Long story short: in JavaScript, a closure is created every time a function is created.

Comming soon...

I will continue expanding on this topic soon, by deepen the discussion on lexical scoping and practical applications like memoization.

Understanding Array.prototype.sort() in JavaScript: A Beginner's Guide

Diego Palacios Lepore — Fri, 25 Aug 2023 09:34:57 +0000

Introduction

Have you ever stumbled upon the Array.prototype.sort() method and found yourself scratching your head?

You're not alone! It's an incredibly useful tool, but it can be somewhat confusing. So, grab a coffee, and let's see how sort() operates, using some practical examples to clarify things.

Basic Sorting: An Unexpected Twist

Starting with the fundamentals, the sort() method, by default, arranges array elements as strings in ascending sequence:

const nums = [40, 1, 5, 200];
nums.sort();
console.log(nums); // Output: [1, 200, 40, 5]

Surprised? It's because sort() converts numbers into strings for comparison, making '200' smaller than '40'.

Tailored Sorting with a Compare Function

Need more precision? You can employ a compare function with sort():

nums.sort((a, b) => a - b);
console.log(nums); // Output: [1, 5, 40, 200]

Here's the secret formula:

Below 0: a comes before b.
0: a and b remain unchanged.
Above 0: b comes before a.

Want the reverse order? Simply reverse the equation:

nums.sort((a, b) => b - a);
console.log(nums); // Output: [200, 40, 5, 1]

String Sorting

Need to sort strings? Think about case insensitivity:

const fruits = [ 'Kiwi', 'Banana', 'banana', 'Cherry', 'apple', ];
fruits.sort((a, b) => a.toLowerCase().localeCompare(b.toLowerCase()));
console.log(fruits); // Output: [ 'apple', 'banana', 'Banana', 'Cherry', 'Kiwi' ]

But why does this also work?

const fruits = [ 'Kiwi', 'Banana', 'banana', 'Cherry', 'apple', ];
fruits.sort((a, b) => a.localeCompare(b));
console.log(fruits); // Output: [ 'apple', 'banana', 'Banana', 'Cherry', 'Kiwi' ]

It's due to the String.prototype.localeCompare method, which adjusts to the locale and environment.

Object Sorting: Managing Your Digital Shop

Have a product array?

const merchandise = [
  { name: 'Laptop', price: 1000 },
  { name: 'Mouse', price: 20 },
  { name: 'Keyboard', price: 50 }
];

Sort by cost effortlessly:

merchandise.sort((a, b) => a.price - b.price);
console.log(merchandise);
// Output: [{ name: 'Mouse', price: 20 }, { name: 'Keyboard', price: 50 }, { name: 'Laptop', price: 1000 }]

Advice and Warnings: The Small Details

On-the-spot Sorting: sort() modifies the original array. No duplicates here!
Consistency: Sometimes the sequence remains, sometimes not. It's unpredictable!
Undefined Values: They always land at the tail end.

Conclusion: Sort Like an Expert

The Array.prototype.sort() method is akin to a multi-tool for array sorting in JavaScript. Yes, it has its oddities, particularly with numbers, but with a tailored compare function, you have the reins. Now that you've mastered it, you'll see it as an essential part of your developer toolkit. Enjoy sorting! 🚀

To-Do app: Composition API as an alternative to Vuex

Diego Palacios Lepore — Sat, 10 Oct 2020 23:21:25 +0000

After reading an Anthony Gore's article about using the new Composition API as some sort of replacement of Vuex, for smaller projects, I took a simple todo app I built in Codepen, and then I created a new Vue 3 app (using the vue cli) and lastly, I moved all the state and mutation methods from each component to one single file (global.js - which will be something like the store, in Vuex).

Source code and foreword

Here's a list of the source code and the Codepen I will refer to in this article:

Codepen: Vue To-do app

GitHub repo: todo-app-vue3

Netlify: https://relaxed-yonath-fa8475.netlify.app/

If you take a look at the todo app I created in Codepen you'll notice I'm not even using Vuex, I'm just using both props to pass data down to children and $emit to pass data/communicate up to parent components.

One of the advantages of the new Composition API is that now we have access to reactive features outside of components, which is quite powerful.

So here's what I did after creating my Vue 3 app, and putting the components code into its own files, and basically making the app work like it is working on Codepen:

Move the state and mutation functions to a global file

The first thing I did was to create the global.js file in /src.

Inside global.js, I imported the reactive and the readonly APIs. Let's take a look at the code in 'global.js' - I will add the comments in the code snippet.

import { reactive, readonly } from "vue";

/* 
Wrapping our object with reactive() makes, 
as it clearly suggests, our object reactive 
(it even affects all nested properties).
*/

const state = reactive({
  tasks: [
     {
      id: 1,
      description: "Finish the course",
      done: false,
     }, 
     {..}, 
     {..}, 
     {..}, 
     {..}
  ],
  nextId: 6,
  tasksFiltered: [],
  activeTab: "all",
})

/* 
All these functions below are a combination of
mutations and actions (when comparing with Vuex).
But, of course, we are always free to organize our code
however we want.
*/

const filterTodos = function(filterOption) {..}

const addTodo = function(todo) {..}

const deleteTask = function(task) {..}

const toggleTaskStatus = function(task) {..}

// Export an object with the state and mutations
export default { 
  // With readonly(), we prevent our state to be mutated
  // outside of the global.js module
  state: readonly(state), 
  filterTodos, 
  addTodo, 
  deleteTask, 
  toggleTaskStatus
}

Use Provide / inject

Then, we need to make global.js (our "custom store") accesible to all of the App.vue child components. To do so, we have to use the provide property inside our App.vue in order to make global.js available to all the child components, so we import global.js in App and then, we provide it.

Right after that, in each component, we need to inject global in order to use it on each of them.

Now a screenshot of each child component (but remember, you can always go to the repo and take a look a the code)

TodoList.vue

Form.vue

Header.vue

This approach can be improved, and could serve as a simpler alternative. Of course, Vuex is more debuggable and we can track mutations in the vue dev tools. So it will always depend on the project we're working on or our personal choice and point of view.

What do you think about this approach?
Do you have any suggestions?

Hope you found this article useful! 🙂

Understanding “this” in JavaScript by focusing on “where” and “how” a function is invoked

Diego Palacios Lepore — Sun, 20 Sep 2020 00:39:47 +0000

In this article I talk about what I've learned about how to know where this points to in a given function. Basically this is me sharing with you, in my own words how to do so.

And yes, I did that weird drawing at the top 😀

Firstly, it is important to understand that the this binding is not determined when a function is declared, instead, it is determined by where that function is invoked, and also based on how that function was invoked.

Step 1: WHERE

The first thing we need to do is find where the function was invoked in our program. It could have been invoked from either the global execution context or from a local execution context , and the only way to find our function's call-site (besides watching directly in our code) is by looking at the call stack. Here's a very simple example that you can try in the console in order to see the stack.

First, copy and paste the following code in your browser's console:

function baz() {
    bar()
}

function bar() {
    foo()
}

function foo() {
    debugger
}

baz()

Then, in the devtools, under the sources tab, and then under the Call Stack section, you will see a list of functions. This way we can know for sure that foo() call-site is bar() , and bar() call-site is baz(), and finally baz() call-site is the global execution context, which in this case is shown as anonymous.

foo         (VM431:10)
bar          (VM431:6)
baz          (VM431:2)
(anonymous) (VM431:13)

Now that we know how to find our function's call-site (where) , let's talk about the set of rules that determine the this binding (how) .

Step 2: HOW

When a function is invoked, a new Local Execution Context is created. That Local Execution Context has information about the function (its place in the call stack, the arguments length and - among other things - a property called this).

The value of this (what object is it pointing to) is determined based on how the function is invoked.

We can invoke our functions in 4 different ways, following 4 different rules, namely:

Default Binding
Implicit Binding
Explicit Binding
New Binding

Extra: I will also talk about how the this binding is determined on arrow functions.

Default Binding

var x = 20

function foo() {
  console.log(this.x)
}

foo.x = 40

foo()  // 20

A default binding is made when we do a regular function call, like we did here with foo(). In non-strict mode the this binding will reference the global object, but on strict mode it will be undefined.

It's worth mentioning that in the first line we declare a variable x and assign the value of 20. And this is like doing window.x = 20. Long story short, a property is created in the global object, and this is the reason why this.x is 20.

When foo is invoked, something like this happens under the hood:

foo.call(window)   // non-strict

foo.call(undefined)   // strict

Even though we will revisit this subject later in one of the 4 rules, I'll briefly explain what's the call() method doing here: The call() method is explicitly setting to what object this will be bound to.

Implicit Binding

When we invoke a function in the context of an object, this will point to that object. Let's take a look at the following code:

var x = 20 

const myObj = {
  x: 50,
  foo: function() {
     console.log(this.x)
  }
}

myObj.foo() // 50

I would like to clarify that the anonymous function declaration in myObj.foo (aka method, since it is declared inside an object) does not belong to myObj. Remember that since functions are callable objects, they are assigned by reference (like all objects are), unlike the primitive values, which are assigned by copy.

In order to illustrate my point, consider the following code:

var x = 20 

const myObj = {
  x: 50,
  foo: function() {
     console.log(this.x)
  }
}

myObj.foo()  // 50

const foo = myObj.foo
foo()  // 20

When we declare const foo, we assign a reference to the same function myObj.foo is pointing to, and then, by doing a stand-alone invocation of foo, the default binding rule is applied, and since we're not using strict-mode, this will point to the global object, in this case, the window.

As you can see, and like I said before, the binding of this is not determined when the function is declared, but when the function is invoked and most importantly on how that function is invoked.

Explicit Binding

All functions have access to three different methods that allow us to invoke them and explicitly set the object that this will be bound to. I'm talking about the call(), apply() and bind() methods.

Consider the following code:

const obj = {
  x: 'Hi there'
}

function foo(name, age) {
  console.log(
    `${this.x}, my name is ${name}, and I'm ${age} years old`
  )
}

foo.call(obj, 'Diego', 31)  
// 'Hi there, my name is Diego, and I'm 31 years old'

foo.apply(obj, ['Diego', 31])  
// 'Hi there, my name is Diego, and I'm 31 years old'

const bar = foo.bind(obj, 'Diego', 31)
bar()  // 'Hi there, my name is Diego, and I'm 31 years old'

Let's talk about each of the call methods in our snippet:

call() : Invokes and receives (as its first argument) an object that will explicitly be bound to this. It also receives the function's arguments separated by a comma.
apply() : It does the same thing as call(), but the only difference is that the arguments are passed inside an array.
bind() : It's also similar to call() but instead of immediately invoking the function, it returns a function with this bound to the object passed as its first argument. In this snippet we store the returned function in a const and below that we make the invocation.

New Binding

A function invocation with the new keyword at the beginning is referred to as a constructor call. Let's now consider the following code snippet:

function foo(name, age) {
   this.name = name
   this.age = age
}

const bar = new foo('Diego', 31)

console.log(
`My name is ${bar.name}, and I'm ${bar.age} years old`
) 

// My name is Diego, and I'm 31 years old

When we do a constructor call on the foo method, this is what happens:

First, it creates and return a new object. Something like Object.create({}).
this will point to the newly created object, which in this case has a reference to that object in bar.
And lastly, the newly created object is linked to the function's prototype. In other words, the bar object delegates its [[Prototype]] / __proto__ to the foo's prototype object.

Just as a refresher, all functions have a prototype object. It only has one property, constructor , which happens to be a reference to the function itself.

foo.prototype
/*
Output:

{ constructor: ƒ foo(name, age), __proto__: Object.prototype }
*/

bar.__proto__    

// or

Object.getPrototypeOf(bar)

/* 
Output:

{ constructor: ƒ foo(name, age), __proto__: Object.prototype }
*/

foo.prototype === bar.__proto__  // true
foo.prototype === Object.getPrototypeOf(bar) // true

These are the 4 rules that will determine the this binding of a function. So now we know the questions we need to ask ourselves in order to know where this is pointing, namely:

where has the function been invoked?
how the function was invoked?

Arrow functions and `this`

But there's one more thing to consider...

Unlike the 4 rules above, the this binding in arrow functions is determined by its parent scope. In other words, the this binding of an arrow function is the same as its container function:

var name = 'Global'

function foo() {

  const bar = () => {
      console.log(this.name)
  }

  return bar
}

const obj = {
  name: 'Diego'
}

const fn = foo()
fn()  // 'Global'

const fn2 = foo.call(obj)
fn2()  // 'Diego'

When the foo function is invoked, the arrow function will inherit the this from foo.

In const fn = foo() since foo() invocation is a regular/normal function call, the Default Binding rule is applied, so in this case the foo's this points to the window object (if we are on strict mode it will be undefined).

But, in const fn2 = foo.call(obj) , the Explicit Binding rule is applied, since we're explicitly setting the obj that will be bound to foo's this, which is the obj object.

And even if we do a fn2() (invoking our returned arrow function) which according to the 4 rules is a Default Binding, it will ignore those rules, and use the this binding of foo's invocation, in this case obj.

Final words

Like I said at the begging, this post is me writing in my own words what I learned from the YDKJS book series, specifically the from the this & Object Prototypes book from Kyle Simpson. I fully recommend all the books from the series.

NaN, isNaN() & Number.isNaN()

Diego Palacios Lepore — Sun, 23 Aug 2020 14:45:09 +0000

The number type has several special values, and one of them is NaN, which is a special value in JavaScript representing a computational error in numeric operations.

In this article I am going to share some of the things we need to be aware of when working with this special value.

I suggest you try the code snippets as you find them along the article.

The naming is confusing

Let's do a typeof on NaN to see what it returns:

typeof NaN  // "number"

As you can see it returns "number" as the type, so it clearly means that NaN is actually a number... wait a second, what!? 😮

So, it would have been better to name this special value something like: "Not a Valid Number" or similar, in order to avoid the confusion.

The NaN special value represents some sort of error in the number set. It is returned when we try to do a mathematic operation and it fails. So, In this case, the NaN special value is returned.

The equality quirk

If we want to check if some value stored in a variable is NaN, using either the === or the == operators won't work since NaN is the only value that is not equal to itself.

const x = 10 / "foo"  // This will evaluate to NaN

x === NaN    // false
x == NaN     // false

NaN !== NaN  // true

Checking if a value is `NaN`

There are two methods that can help us test if a value is NaN. We can use either the built-in global utility method isNaN() or the Number.isNaN() utility. But you will see bellow why is recommended to always use Number.isNaN() instead of isNaN(). Let's try them out:

const y = "foo" * 10  // This will evaluate to NaN
const z = "bar"

isNaN(y)   // true
isNaN(z)   // true
isNaN(20)  // false
isNaN("55")// false

It seems that the isNaN() utility is taking the NaN literally as Not a Number.

Let's thinkg about it for a moment... 🤔

It seems the isNaN() logic is somethimg like this:
"If the value passed is (or evaluates to) either the special value NaN or something that is not of the type number ( typeof x !== "number" ), then return true"

However, this is clearly not accurate, because, as far as we know typeof NaN === "number", so it should return true only if we pass something that is (or evaluates to) the special value NaN, and it should return false if the value is not of type of number.

Let me elaborate a bit more on this.

The logic should be instead something like this:
"If the value passed is literally the value NaN return true, otherwise return false".

Fortunately, there's a utility method (a replacement of isNaN) that does exactly that:

const a = 20 / "foo"  // This will evaluate to NaN
const b = "bar"
const c = 35
const d = {}

Number.isNaN(a)   // true
Number.isNaN(b)   // false
Number.isNaN(c)   // false
Number.isNaN(d)   // false

If you want to check the browser support for this built-in utility method, you can go to Can I Use: Number.isNaN.

A couple of polyfills for Number.isNaN

Writing these polyfills will help us understand these utilities a bit more.

if(!Number.isNaN) {
  Number.isNaN = function(n) {
    if( typeof n === "number" ) {
      return window.isNaN(n)
    } 
    return false
  }
}

So in this one, we filter the value and make sure it has the type of number, if so we use the isNaN utility.

But we can use an even simpler solution, considering the fact that NaN is not equal to itself. Let's see:

if(!Number.isNaN) {
  Number.isNaN = function(n) {
    return n !== n
  }
}

Extra

We can also use the Object.is() method to check if two values are the same. It is helpfull because it covers even the corner cases like -0 === 0 // true (which should be false in this particular case) and it covers the NaN equality quirk as well.

Object.is(NaN, NaN)  // true

If you want to learn more about Object.is you can go to this MDN link.