Forem: Enmanuel Durán

Understanding Big O Notation as a Software Developer

Enmanuel Durán — Fri, 30 Apr 2021 13:51:13 +0000

Originally posted on Enmascript.com, for a better reading experience click the link to the original post.

Big O is a highly popular notation that is often heard in the world of algorithms, performance and optimization. It is a pivotal topic for coding interviews at big companies such as Google, Amazon, Facebook... everybody says you should learn about it, but why? why would you or anyone learn about Big O if you are not taking interviews? In this article, I will try to explain from my perspective what Big O is, why it is useful and how you can apply it in an everyday basis to make you improve as a software developer.

Definition

There are multiple ways of writing algorithms, you can implement a feature using different approaches, everybody has a unique way of thinking and solving their way through problems, for this reason, we need a way to understand how these different solutions perform under different scenarios to help us determine which one works better based on our needs, Big O is a notation that allows us to evaluate this, specifically it allows us to evaluate growth rates by analyzing how time complexity (Time of execution) and space complexity (memory usage) scale for a given algorithm when larger input sizes are processed by it. Big O is driven by the upper bound or higher complexity found in an algorithm so the worst case complexity will be the Big O representation of your code..

For a formal definition of Big O I would recommend you to read the one from wikipedia which is pretty straightforward, if you have trouble understanding the formal definition do not worry, it is enough to understand the intuitive definition highlighted above.

Understanding How to Evaluate Complexities

To understand how to evaluate an algorithm or a piece of code we need to separate it into statements or operations and we need to understand how each of these affects the algorithm.

Let's define some important concepts before proceeding:

Complexity and Performance are two different things, The former specifies how the required resources for a program scale and the latter specifies how much of those resources are used taking into consideration the environment (the machine) in which an algorithm is running, the code, the time... So Complexity affects Performance but this is unidirectional, performance does not affect complexity.
Statements are the units or simple instructions executed in a program to perform an action, they could be in example:
- Defining a variable let a = 1;
- Making an arithmetic operation 3 + 2
- A Function call fn()

There are also Compound Statements that contain more than one instruction or operation, one example is: for (let i = 0; i < 10; i++) {} which is executing a loop but at the same time defining a variable i, making a comparison i < 10 and incrementing the variable i by 1 in each iteration.

The idea is that you understand that programs are a set of statements that determine their complexity. In Big O specifically, we care about the statements with higher complexity, where "higher" means less efficient, so after evaluating all the statements the one that will define the complexity of the algorithm is the less efficient complexity found, so:

Big O = max(complexity(statement1), ..., complexity(statementN))

Finally, two more concepts, as previously mentioned there are two types of complexities relevant to Big O:

Time Complexity evaluates how an algorithm will scale over time, helping us understand if it will be too slow or will be fast enough for our needs.
Space Complexity evaluates how an algorithm makes use of space over its execution, for example, how many variables we are defining, how an array or object grows to ensure that we will not cause any issues with memory consumption given our needs...

Constant

Constant or O(1) Complexity refers to an algorithm that no matter the input size it will always take the same amount of time/space to perform a task (therefore it is constant when the input size grows), in example let's evaluate a function that validates if the first element of an array is a number:

function isFirstElementNumeric(list) {
    return typeof list[0] === 'number';
}

If we evaluate this by statements we understand that:

Line 1: We are creating a function called isFirstElementNumeric
Line 1: We are creating a variable called list to hold the input.
Line 2: We are returning a value
Line 2: We are getting the typeof list[0]
Line 2: We are making a comparison against number

Notice how I have separated the lines into multiple statements, one line can have multiple statements, and some of those statements can be native implementations of the language like in this case when typeof is used, and this is important to understand, the inner implementation of native functionalities affects the complexity of an algorithm depending on how it is implemented by the language, so if you are evaluating an algorithm, you need to be careful to understand and account for the complexity of the inner works of the language.

If we evaluate the Time Complexity of the previous algorithm knowing the concept of constant we can determine that each statement is O(1), why? because for all the statements of this function no matter how big the input is, it will always take the same amount of time to evaluate every statement of the function, because in this case even if the array has 1000 elements we are just taking index 0 and same goes for space, we are not defining new variables when executing this function, and this next part is important, yes, we are using a variable list to hold the input but when evaluating space complexity we don't take into consideration the input itself because that is the very premise upon which the algorithm evaluation itself is based on, if we considered the input, then, for any function receiving a data structure capable of storing multiple properties it would be at least linear time (We will explain linear time in a bit).

The graph below represents how time complexity (Y Axis) gets affected when the input size (X Axis) grows, since time is constant time remains unchanged for any given input size.

Real-life usage of constant complexity

Pretty much everywhere, i.e:

Arithmetic operations
Variable definitions
Boolean Comparisons

Logarithmic

Also known as O(log(n)), As the name specifies, we determine a logarithmic time complexity when an algorithm runs in a time that is proportional to the logarithm of the input size as its size grows.

Logarithms can have different basis, so for example for a log of base 10:

log(1) = 0
log(2) = ~0.301
log(3) = ~0.477

and so on... As you can see the growth rate is still small and not linear. Usually, we are able to identify an algorithm that is O(log(n)) because it will divide itself into smaller and smaller pieces with each iteration or operation, the simplest example I can think of is the following:

function showIteratedValues(n) {
    let i = 1;
    let list = [];

    while (i < n) {
        i = i * 2;
        list.push(i);
    }

    return list;
}

If we evaluate this statement by statement we realize that lines 1,2 and 3 are constant time and in space, because we are defining a function and some variables and they do not change in respect of the input n, but when we reach the while statement things get interesting.

The while statement creates a loop based on the condition i < n, so the cycle will execute until that condition is false, this already takes more than constant time to execute, why? because for a bigger input n passed to this function the algorithm will take a longer time to execute because the while loop will have to potentially execute more iterations. With each iteration, the value of i will exponentially increase because we are multiplying i by 2 and in the next iteration the result * 2 and so on (you might be thinking "wait, exponentially?, aren't we talking about logarithmic time here?") yes, this is true but something important to notice is that logarithmic growth is the inverse of exponential growth meaning that if the loop's variable condition is increasing exponentially then the number of executions needed by the loop to finish decreases logarithmically, hence the time complexity is logarithmic.

How about space complexity? Good question, let's evaluate the statements in the loop:

i = i * 2; for the definition of the variable i inside of the while loop we can say that the space complexity is constant, why? because with each iteration the value of i is overwritten with the new value of i * 2, so this is not growing in space.
list.push(i) this right here is the key to the space complexity of this algorithm, every time an iteration happens the array list grows in parallel with time complexity, hence the space complexity of this statement is logarithmic.

Hence space complexity is logarithmic.

Real-life usage of logarithmic complexity

Binary Search.

Linear

One of the easiest complexities to identify along with constant, an algorithm has a linear O(n) complexity when it grows proportionally to the input, in other words when the growth rate is fixed when iterating over each input given:

function elevateToPowerOfTwo(list) {
    const n = 100;
    const powerOfTwoList = [];

    for (let i = 0; i < n; i++) {
        powerOfTwoList.push(i**2);
    }
}

Let's evaluate by statements again:

The first three lines of code are constant time and space, they are not changing for a bigger input.
for the for loop we have for (let i = 0; i < n; i++) { which contains 4 statements:
- let i = 0; which will get overwritten next time when it is incremented so it is constant.
- i < n a simple comparison constant.
- i++ increments i by 1 on each iteration, the value of i changes but the variable i is overwritten.
- The for statement itself, we will need to iterate over each value until i < n is no longer true, if n is a higher value we will have to iterate as many times as needed again until i reaches a value >= n and this is true of any n for this algorithm, as you can notice in linear time the correlation of the input size with the runtime is clear, if we increase n by a factor of 2 we already know that we will have to iterate twice as many times as before.

For Space complexity we can proceed to evaluate the next statement:

powerOfTwoList.push(i**2); which increases the array with each iteration until the loop is over, since the loop itself is linear time this array will grow in space at the same rate hence space complexity is linear.

if we compare this with logarithmic time complexity we will notice that logarithmic time is a bit more ambiguous, nevertheless, it is worth noting that logarithmic time is more efficient than linear because logarithmic time grows at a slower rate (due to the partitioning that happens through each iteration, thing that does not happen in linear time).

Real-life usage of Linear complexity

loops
Recursive Functions

Linearithmic

Linearithmic complexity is a combination of linear and logarithmic complexity hence O(n * log(n))

Linearithmic algorithms are slower than O(n) algorithms but still better than quadratic time algorithms (which we will see in a bit) a way to see them iteratively speaking is by combining our linear and logarithmic code examples, to end up with a linear cycle executing a logarithmic one inside so that:

O(n) * O(log(n)) = O(n * log(n))

But this is just one way to express it in code, linearithmic algorithms have many ways of presenting themselves recursively and by input division over time...

Following the iterative idea from before we could write:

function logarithmicExecutions(n) {
    for(let i = 0; i < n; i++) {
        let j = 1;
        let counter = 0;
        let logarithmicPossibilities = [];

        while (j < n) {
            j = j * 2;
            counter++;
        }

        logarithmicPossibilities.push(counter)
    }
}

Evaluating the code above and already having evaluated linear and logarithmic time complexity it becomes even clearer why it is linearithmic, however, the space complexity of this piece of code is not linearithmic, if you take a look closely it is linear space complexity given that logarithmicPossibilities grows proportionally to the outer loop which is o(n) and the rest of the variables are overwritten per iteration.

Real-life usage of Linearithmic complexity

they are usually found in sorting algorithms such:

Merge Sort
Heap Sort

Quadratic

An algorithm ison quadratic time or space complexity O(n^2) when it grows proportionally to the squared value of the input given so:

For 1 we define 1^2 = 1
For 2 we define 2^2 = 4
For 3 we define 3^2 = 9

and so on... visually speaking quadratic time would look something like this:

a good example of this type is when we are dealing with nested loops (one level of nesting), it does not mean that all nested loops are quadratic by any means, and I will explain this better below, but a typical case could be the next one.

const list = [1,2,3];
let total = 0;

for (let i = 0; i < list.length; i++) {
    total += i;

    for (let j = 0; j < list.length; j++){
        total += j;
    }
}

console.log(total);

If you take a look at the code above you'll see that we have an outer loop that executes up to n times where n = 3 (the length of list), inside of that loop we have another one that is doing the same thing, which means that for each element on the parent loop we are executing n times the inner loop:

So basically n * n hence n^2, however not all nested loops represent a quadratic time complexity, this only happens in cases where the two loops (outer and nested loop) are running the same amount of n times, in the code example above using list.length as n, but what happens if one of the loops has a different variable with a different size? - well in that case the complexity would be O(n * m), because both variables are distinct.

As for the space complexity of our algorithm above it is constant O(1) because memory is not increasing concering the input.

Real-life usage of quadratic complexity

Nested loops
Bubble Sort

Exponential

Also known as O(a^n) where a is constant and n is variable, not to be confused with polynomial where it is the opposite.

A simple example I can think of that takes exponential time is recursive Fibonacci without memoization (If you don't know what memoization is take a look at one of my previous articles Avoid recomputing heavy tasks by leveraging memoization in javascript).

let's take a look at the code:

function fibonacci(num) {
    if (num <= 1) {
        return 1;
    }

    return fibonacci(num - 1) + fibonacci(num - 2);
}

so why is it exponential? I think it is useful to look at a visualization to understand what is happening here:

For each new function call, the algorithm doubles the previous amount of executions which tells us that the exponent n is increasing with each recursive call in this case for base 2.

Note: There is a theorem that helps us determine the complexity of recursive algorithms called Master Theorem but it deserves its own article.

Real-life usage of Exponential complexity

Exponential algorithms in the form of O(a^n) which usually solve a problem of size n by recursively solving a smaller problems of size n-1.
Fibonacci sequence.

Factorial

Factorial time O(n!) is not an indicator of good performance but sometimes we can't do better than that, to put you into context let's remember its definition: The factorial of a non-negative integer number n is the product of all positive integers less than or equal to n.

Factorial algorithms are often found when making permutations and combinations.

so for example, the factorial of 4:

4! = 4 * 3 * 2 * 1

Real-life usage of Factorial complexity

A classic case scenario of this time complexity is the processing of every possible permutation of an array where n is the size of the array and so it is n! because we need to make all the permutations possible up to the length of n.

Permutations
Combinations

Due to complexity I have decided that I will write a separated article to explain one example of factorial complexity.

Hierarchy

So after everything we have learned, we can define that for an n large enough it holds that:

O(1) < O(log(n)) < O(n) < O(n * log(n)) < O(n^2) < O(2^n) < O(n!)

Which means that if you are evaluating your code and you find that it has an statement that is O(n) but there is another block of code that is O(n^2) then your code is O(n^2) because as previously mentioned, Big O cares about the upper bound.

There are other complexities that we are not including in this article like in example cubic complexity, but the idea is not to name them all, instead, I want to help you understand how to analyze your code to determine how efficient it is and of course dig deeper into the topic if you are interested.

Apply this knowledge in your day to day basis

One way to start practicing Big O notation is by thinking on the complexity of the problems you are solving, go back to problems you have previously solved, and see for fun if you can determine their complexity and if there is room for improvement for a future state, this is a very useful practice that will help you practice statement's complexity evaluation so that it becomes easier and easier, however, this does not mean that you need to refactor all your code, NO!, before doing improvements, make sure to measure if it is a real problem given the use case of the algorithm, don't apply blind micro-optimizations since that is not a good practice either, I have written an article on that matter called Code quality and web performance, the myths, the do's and the don'ts in case you wanna check it out.

When making a new implementation think in terms of scalability, feel free to do a naive implementation first and apply gradual improvements from there or take your time thinking on the implementation to get it right the first time, either way works, the important part is to think in terms of how each statement you are adding affects the algorithm as a whole.

Code reviews are also a perfect place to put this into practice, understand the business application of the code that you are reviewing but also the complexity that is being added to the codebase and see if it can be improved and if it is worth it.

Closing Thoughts

I have to say, writing this article was a lot of fun, I hope that I was able to incentivize you to keep learning about algorithms and their complexities, this is just a little part of everything that involves algorithm's complexities, in example besides Big O (O) we also have Big Omega (\Omega) to evaluate the lower bound, and Big Theta (\Theta) to evaluate the average case, so please do not stop here, if you have any comments or wanna reach out feel free to do it, as always the information is below.

See you next time!

Understanding Singly Linked Lists and some of their uses

Enmanuel Durán — Mon, 12 Apr 2021 15:16:10 +0000

Originally posted on Enmascript.com, for a better reading experience go to the original post.

Definition

Linked Lists are a fundamental data structure used to store information linearly, this information is not stored in contiguous places in memory rather linked lists use a pointer in each node that links to the next node that is stored.

A node in a linked list could be represented as follows:

which in code could be represented as:

class Node {
    constructor(value) {
        this.value = value;
        this.next = null;
    }
}

Allowing us to create a new node like:

const node = new Node('Node value');

As already stated each of these nodes contains data that is stored in this.value and has a direct reference to the next node in line through this.next, the first node of the linked list is usually referred to as the Head and the last node is called Tail, since the Tail is always the last node the value of its this.next property will always be null for singly linked lists.

So if we try to represent that in code we get something close to:

class LinkedList {
    constructor() {
        this.head = null;
        this.tail = null;
    }
}

1. Appending nodes to a linked list

Let's start by creating a linked list API, we already know how to represent a node and we know the basics, we know how we will represent the head and the tail, so we can start to define how we will append new nodes to the linked list, for this we need to consider that:

If not head is defined the new node should be defined as the head and also the tail.
If the head is defined we add the new node to the current tail's next property and we define the new node as the tail.

import Node from './LinkedListNode';

class LinkedList {
    constructor() {
        this.head = null;
        this.tail = null;
    }

    append(value) {
        // We create a new Node
        const node = new Node(value);

        if (!this.head) {
            // If not head is define we define it alongside with the tail
            this.head = node;
            // We  define the tail
            this.tail = node;

            return this;
        }

        // If the head is defined we attach the new node to the
        // tail's next property
        this.tail.next = node;
        // We make the new node the tail
        this.tail = node;

        return this;
    }
}

So now if we call append like:

const linkedList = new LinkedList();

linkedList.append(1)
linkedList.append(2)
linkedList.append(3)

We would get this result:

and if we do something like console.log(linkedList) you will get a result like:

{
    "head": {
        "value": 1,
        "next": {
            "value": 2,
            "next": {
                "value": 3,
                "next": null
            }
        }
    },
    "tail": {
        "value": 3,
        "next": null
    }
}

This is excellent, you can see how the nodes connect with each other, they are just objects connected to each other through their next property.

1.1. Time complexity for Appending nodes to a linked list

Appending an element to the end of the linked list requires us to modify the tail's next property and reassign the tail with the value of the new node.

this is true for any node we want to append which makes this a constant O(1) operation.

2. Prepending nodes to a linked list

Prepending a node is simpler since we already have the head of the list stored, the only thing we need to do is assign the new node as the head of the list and define its next property with a reference to the previous head Node.

class LinkedList {
    ...

    prepend(element) {
        const previousHead = this.head;
        this.head = new Node(element);
        this.head.next = previousHead;
    }
}

2.1. Time complexity for prepending nodes

It does not matter how many nodes the linked list has, it will always be the same process and complexity for prepending hence the time complexity of prepending is constant O(1).

3. Accessing and Searching nodes

The only way to access and search an element in a given linked list is through the iteration of the next property of all the nodes that come before the node we are looking for, it is important to note that if the element we are searching or trying to access is not found this would still require us to go through all the nodes in the list.

class LinkedList {
    ...

    find(value) {
        if (!this.head || value === undefined) {
            return null;
        }

        let currentNode = this.head;

        while(currentNode) {
            if (currentNode.value === value) {
                return currentNode;
            }

            currentNode = currentNode.next;
        }

        return null;
    }
}

i.e let's find the node 3 in the linked list below:

3.1. Time complexity of accessing and searching nodes

Knowing this we can stablish that accessing and searching an element would be O(n) where n = number of nodes in the list, even though we don't always search the whole list the big O notation analizes algorithms by their trend and worst case scenario and so we arrive at this conclusion.

4. Removing nodes from a linked list

Great, now as you can imagine, removing elements from a linked list is pretty straight forward:

Check if the node we want to remove is currently the head of our linked list, if so, we just remove the reference to such node by making this.head be the next node in line (since now there is no reference to the node with value 1 it will be garbage collected and removed):

If the node to remove is not the head, we iterate over the nodes until the node to remove is found, if the node is not found we don't do anything.
Once the node to remove is found we get the node previous to that one, we then modify this previous node's next property so that it points to the node that comes after the node to remove, in this way the reference to the node to be removed is lost and it can be garbage collected hence the node is removed from the linked list.

let's see how this would look in the code:

class LinkedList {
    ...

    remove(value) {
        if (!this.head || value === undefined) {
            return null;
        }

        let nodeToRemove = null;

        // Check if the node to remove is the head node
        if (this.head.value === value) {
            // We save the node just to return it later
            nodeToRemove = this.head;
            // If the node is the head we remove the node by assigning
            // the second node as the head.
            this.head = this.head.next;
        } else {
            // currentNode will be used to iterate over the nodes
            let currentNode = this.head;

            // We iterate over the nodes until there are no more nodes left to search
            // or until we find the node to remove
            while(currentNode.next !== null) {
                if (currentNode.next.value === value) {
                    // We save the node just to return it later
                    nodeToRemove = currentNode.next;
                    // If we find the node we remove it as explained on point 4.
                    currentNode.next = currentNode.next.next;
                } else {
                    // If the node has not been found we continue searching
                    currentNode = currentNode.next;
                }
            }
        }

        return nodeToRemove;
    }
}

Let's say we want to remove the node that contains the value 2, we would ideally do this by calling the method remove like:

linkedList.remove(2)

Which would modify the reference from the node with value 1 to be now the reference of the node with value 3, in this way node 2 is left out:

4.1. Time complexity for Deleting a node (From the beginning / Head node)

Deleting a node from the beginning of the list as previously seen just requires us to change the this.head value to be this.head.next in this way we remove the reference to the first node, since this operation is constant no matter the size of the list it is considered O(1).

4.2. Time complexity for Deleting the Tail or any node that's not the head

Doing this will require us to iterate over the list until we find the element to delete (Same that we need to search an node), then we just remove the node as usual so the time complexity would be O(n) where n = number of nodes in the list.

Space Complexity of linked lists

The space required for a linked list is directly correlated with the number of nodes that it holds, this means that the more nodes we have the more space we use and this grows linearly per node which makes linked lists O(n) for Space complexity.

Use cases and why to learn about them

Most of the cases where linked lists shine come in situations where we need to insert or delete multiple nodes, in these cases linked lists perform at a constant time which makes them ideal, also since linked list's space grows linearly we can also leverage their dynamic memory allocation in ocassions where we lack memory.

Another important point is that there are other structures that are and can be built with linked lists as a base, one good example are queues (That we will analyze later in another article)

Hope this article helped you understand linked lists a little.

Better ways of tracking data in your web application that you may not know of!

Enmanuel Durán — Mon, 22 Mar 2021 14:57:00 +0000

Originally posted on Enmascript.com, for a better reading experience go to the original post.

Tracking data in our applications nowadays is pivotal to business growth, if done properly it can provide fundamental insights for an application that will allow us to understand how to improve it, data helps us understand our users which allows companies to understand their strengths and weaknesses better. Finally, good tracking marks the difference between success and failure, that's why getting it right is so important.

1.Why using XMLHttpRequest and Fetch is not always the right choice

Usually, when we need to track actions in our applications in javaScript, we will make use of an XMLHttpRequest or even better the Fetch API, this will allow us to make asynchronous requests which send valuable information to our servers or analytics services, this works very well for many types of tracking interactions, for example tracking when a user scrolled past a certain section of the page
or checking the behavior of users to understand why a call to action may not be performing well.

In summary, asynchronous requests are used constantly for tracking, and with reason, they allow us to send information quietly and in parallel to avoid interrupting the user's flow, but, there are some edge cases in which they might not be as efficient, like tracking an element when the page is about to get unloaded.

Suppose that you want to track certain data and send it but the user decides to leave the page and go somewhere else, if your request is still in-flight the data will not reach the server because it will get canceled when going away from your page, so in essence:

The first click generates a request and since it has enough time to be processed it ends up being successful, on the other hand the second click happens right before the page gets unloaded which causes the request to be interrupted and therefore canceled, this right here is the reason why using rudimentary asynchronous request can't ensure the resolution of tracking requests.

2. Why using redirects is not the golden standard

Another popular way of tracking data nowadays is by leveraging redirects, this basically consists of a 3 steps process:

The user clicks a link, this link is not a direct connection to the destination URL, it is a link to an intermediary service.
The intermediary service receives the request with the information, it then processes it and sends it over to each service that may need the data (this includes sending data to the tracking services)
The user is finally redirected to the destination URL by the intermediary service.

This approach is good but it causes a delay in the user experience due to the redirection step that occurs synchronously, if the redirect takes long it may end up leading the user to leave the page, also if an unexpected error occurs in the redirecting layer the user might get stuck into this flow.

3. Enters the Beacon API

The Beacon API allows us to also send asynchronous requests to a web server but with a key difference, Beacon requests are guaranteed to be sent, yes, even after a page gets unloaded. This means that they are perfect to use for those cases in which:

You may want to track clicks on links.
When sending pivotal data in moments where users leave the site.
In cases in which you are not able to ensure the integrity of a normal asynchronous request.

To use the Beacon API it is very simple, you can access the function sendBeacon through the navigator object:

const url = `https://myurl.com/api/tracking`;
const data = new Blob([JSON.stringify({ tracked: true })], {type : 'application/json; charset=UTF-8'});

const beaconQueued = navigator.sendBeacon(url, data);

if (beaconQueued) {
    // The request was queued
} else {
    // Something went wrong when trying to queue the request
}

We can send data as an ArrayBufferView, ArrayBuffer, Blob, DOMString, FormData, or URLSearchParams object. In the example above we are sending the information by using the Blob object, this is commonly used to send information to your server so you can manipulate the data like a JSON object.

Some key concepts about the navigator.sendBeacon function:

It returns a boolean

navigator.sendBeacon returns a boolean value, which means that the "Beacon" request was either enqueued (true) to be processed or not (false), this does not necessarily mean the request will be successful but as per the Beacon definition, the request is guaranteed to be executed and completed.

It is executed after higher priority tasks

After enqueued, the request will be executed only after more important tasks have been processed, this is important to understand because this means that the request won't necessarily happen right away in some cases.

Beacon Request Size Limit

According to the documentation of the processing model for the Beacon API:

Requests initiated via the Beacon API automatically set the keepalive flag, and developers can similarly set the same flag manually when using the Fetch API. All requests with this flag set share the same in-flight quota restrictions that is enforced within the Fetch API.

and if we then read the Fetch API specs especially on section 4.6 it says the following:

If the sum of contentLength and inflightKeepaliveBytes is greater than 64 kibibytes, then return a network error.

which means that the size limit is roughly 65.5 Kilobytes (just for general knowledge 1 Kibibyte = 1.024 Kilobytes)

All this means that if we change a normal Fetch request for a Beacon based request, the following will occur:

As you can see the request would not get canceled, it would get enqueued, then stalled for the necessary time and finally executed.

4.The Ping Attribute, a curious case

Not many people know about this, but there is an HTML attribute used in anchor tags that is specifically created to help track information asynchronously in a non-blocking manner.

The Ping attribute allows you to execute a POST request to an URL or list of URLs specified, it sends the word PING as the request payload. This property is not supported by all browsers but the fact that many popular browsers support it presents a great advantage.

It is used in the following way:

<!-- For a single POST request URL -->
<a href="https://enmascript.com" ping="https://enmascript.com/api/tracking"></a>

<!-- For Multiple POST request URLS -->
<a
    href="https://enmascript.com"
    ping="https://enmascript.com/api/tracking https://enmascript.com/api/tracking-2">
</a>

When clicking the first link above it will take the user as usual to https://enmascript.com but in parallel it will make an asynchronous POST request to https://enmascript.com/api/tracking. You might be thinking what is the use of a POST request in which request's payload is a simple word called "PING"?, well, the answer is that you don't really need to send the data as a request payload.

You can use querystrings to send your data to a server

<a
    href="https://enmascript.com"
    ping="https://enmascript.com/api/tracking/?url=https://enmascript.com">
</a>

In this way you would only need to parse the URL to get the data, in NodeJS for example, you can use Express and you will get access to the query string value through req.query.url, which would return https://enmascript.com.

You can send cookies

As with any post request, you can send information through your headers using cookies, here you can track the session and any data you may need regarding the recent action.

A real use case of the ping attribute: How Google does it

The ping attribute is used by no less than Google, and not on any page, they use it to track users on their search result's page.

If you go to google and make a search for "Enmascript" and inspect the first result, you will find this:

And if you open your network and click on the link you will find a POST request with the PING payload executed to that URL:

I you look closely you can see that google is sending data through query strings and if you inspect the request headers, you will see that cookies are also being sent.

Now, you might be thinking: this is great, but what about Firefox and browsers that do not support the attribute by default?

Glad you asked, you can fallback to use a Beacon request or use a good old server redirect (both already explained above), in Google's case, they decided to handle this by using the redirect approach, so if you search in Firefox you will see that they are not using the ping attribute anymore, instead, they change the anchor's href attribute to be their redirect URL which finally leads to the destination URL.

The goal of this article is to open your mind to other possibilities to improve the consistency of your application, specially on how to efficiently track data while giving users the best experience possible. Remember to always take into consideration your user's privacy and do not take this lightly, make sure to only track what is necessary and keep data anonymized.

Hope you enjoyed it!

Leenker.com a place to organize and share useful Links and bookmarks

Enmanuel Durán — Fri, 29 Jan 2021 17:50:07 +0000

Hey, this is Enmanuel, just another passionate software developer like you, I love innovating where possible and bringing ideas to life, my most recent creation being https://leenker.com/.

In a nutshell, Leenker brings the Browser's bookmarks experience online with extra capabilities, it is probably my most ambitious project so far and I am very excited to share it, I thought about writing a long text about it, but it is better to let the project do the talking instead of getting you bored.

If you want to get to know the why's of the platform, learn about it and its policy: https://leenker.com/help

If you want to use it, I would highly recommend you to do it alongside the chrome browser extension for a better Experience https://chrome.google.com/webstore/detail/leenker/dnkgochdfgehdfbkpkpdbccefphnnmoa

Finally, this is an in-progress project and has many things to improve, (Accessibility, security...) take into consideration that it was built by only one person, so your feedback would be highly appreciated, any bugs or improvements you may recommend you can send them to admin@leenker.com

Hope you like it.

Come join me on https://leenker.com/

Show and hide content on click with just HTML

Enmanuel Durán — Mon, 14 Oct 2019 14:46:31 +0000

Originally posted on Enmascript.com, for a better reading experience go to the original post.

Multiple elements were introduced in HTML5 that are not yet widely known; one of them allows you to create interactive experiences such as accordions or dropdowns, the name of this element is <details>.

Toggling content visually with just HTML

I recently wrote an article on how to create an onclick toggler without using javascript by leveraging the powerful CSS :target selector, but that is not the only/best way to achieve this.

The <details> element allows us to implement a disclosure widget that hides and shows information depending on its boolean state open. This allows us to toggle content interactively and natively:

<details class="details-example">
    <summary>If you click me I will display a list of content</summary>
    <ul>
        <li>Option 1</li>
        <li>Option 2</li>
        <li>Option 3</li>
    </ul>
</details>

Demo
Available on https://enmascript.com/articles/2019/10/14/show-and-hide-content-on-click-with-just-html

As you can see, the <summary> shows up, and when clicking it, we are showing the rest of the information (the list of options).

We are able to achieve this with just HTML, I am adding some CSS to style the dropdown but only styles.

Extra tip (Javascript integration)

You can also execute complementary javascript when the open state of the details element changes, we can do that like this:

const detailsElement = document.querySelector('.details-example');

detailsElement.addEventListener('toggle', event => {
    if (event.target.open) {
        console.log('open');
    } else {
        console.log('closed');
    }
});

Very simple yet powerful feature, some of its more notorious applications are for accordions, dropdowns and toggling visual content in general. Companies such as github use it for their menus and interactions, hopefully now you will also be able to delete some javascript in your code base and use a native HTML element instead.

If you want to read more about this element, MDN has a pretty good explanation about the topic.

Hope it was useful, see you guys in the next one.

Toggle content on click without javascript (Yes you read that right)

Enmanuel Durán — Thu, 26 Sep 2019 14:42:56 +0000

Originally posted on Enmascript.com

Usually every time we want to toggle content on a website on click we use javascript. In this article, we are going to explore a different way of doing this by just using CSS capabilities.

The power behind :target selector

Not many people know this but there is a fantastic pseudo-class that allows us to apply styles to elements when a specific hash link is present or not in an URL, the name of this pseudo-element is :target and it is the protagonist of this short article.

Straight to the point, let's toggle stuff

Based on the explanation above, you may now imagine what I am about to do, so let's do it:

First, let's create a base HTML structure

<div>
    <p>This is some expandable content.</p>

    <p id="hashLink">
        I have expanded like a Pufferfish.
        <a href="#">Please collapse this poor fish.</a>
    </p>
</div>

<a href="#hashLink">Expand</a>

and some CSS:

#hashLink {
    display: none;
}

#hashLink:target {
    display: block;
}

What are we doing here? let's explain

We are creating one anchor to add a hash #hashLink to the URL (Expands the content).
We are creating a second anchor inside of the second paragraph to remove that anchor and leave it empty (Collapses the content).
The content we want to toggle is contained within a paragraph that has an id equal to the hash we are going to be adding to the URL.
We are adding a display: none; to the element with id hashLink so that it is hidden by default.
We are adding a display: block; to the #hashLink:target selector, this is what makes the magic happen, when the hash is present in the URL this style gets applied, creating the effect of toggling on click.

There is no really much more to explain, as you see it is straightforward, if you want to see a live example check the codepen below.

See this Pen from Enmanuel for a live Demo LYPawYY
(@enmanuelduran) on CodePen.

This selector is powerful, be creative and feel free to post cool things you decide to do with it.

Also you should know that there are other ways to accomplish this like using a hidden checkbox and toggle content on checked state.

6 Things you probably did not know javascript could do natively

Enmanuel Durán — Tue, 24 Sep 2019 11:39:29 +0000

Originally posted on Enmascript.com

#Did you know is a new series of Enmascript where we write short and concise explanations about topics we consider might be relevant or underestimated, if you are looking for more complete in-depth articles check out our other series.

JavaScript is a language that evolves fast; for this reason, it is sometimes hard to catch up with all its features and capabilities. On this short article, we will explore some of the features that you may not know existed.

Getting query string parameters

URLSearchParams is an interface that allows us to process query string parameters, it's been around for some years now but it might surprise you to know that it is not that popular between developers, let's see how to use it:

// to get the query strings from the current url use window.location.search
const queryStrings = new URLSearchParams('?browser=chrome&action=redirect');
queryStrings.get('browser');
queryStrings.has('action');

Simple enough, here more information about the complete API, in case you are interested in the complete functionality.

Create a unique list of elements using the Set object

Creating unique lists in javascript is a common task, this is usually achieved by applying filters or for loops, but there is another way to accomplish this leveraging the Set object.

const list = [1, 2, 3, 5, 2, 5, 7];
const uniqueList = [...new Set(list)];

We pass the array of primitive values to the Set object; it creates a collection of unique values which is then converted to a list using the spread operator syntax and array literals.

Cast a list of primitive values to a different type

Sometimes endpoints or processed data from the DOM doesn't return the type of values we need, I have seen this especially happening when processing dataset properties. Let's say we have the following list:

const naiveList = ['1500', '1350', '4580'];

We want to execute a sum of all the elements in the array, in JavaScript if you "sum" two strings like '1' + '2' they will concatenate, generally, to solve this we would leverage the parseInt function, but there is another way; We can cast the elements in the array to the type of primitive we need:

const castedList = naiveList.map(Number);

castedList now contains the values with the correct Number type.

Flatten nested array values

With the rise of Single Page Applications architectures such as Redux and concepts like frontend data normalization became more popular, part of this "data normalization" trend sometimes implies having all the ids of elements listed at the same level.

Let's say we have the following list and we want to flatten it:

const nestedList = [133, 235, 515, [513, 15]];
const flattenList = nestedList.flat();

and just like that our array of ids is now flattened.

Avoid object mutations with Object.freeze

When talking about functional code, one of the things that I have been asked the most is how to stop objects from mutating, the answer to this question is always the same Freeze them:

const immutableObject = {
    name: 'Enmascript',
    url: 'https://enmascript.com'
};
Object.freeze(immutableObject);
immutableObject.twitter = 'https://twitter.com/duranenmanuel';
immutableObject.name = 'Another name';
// immutableObject is still { name: "Enmascript", url: "https://enmascript.com" }

Created Controlled objects with Object.seal

Does the same as Object.freeze but it allows you to change the values of properties that were already defined in the object, this will enable you to _control _the properties declared in an object but not the definitions:

const controlledObject = {
    name: 'Barry Allen'
};
Object.seal(controlledObject);
controlledObject.name = 'Clark Kent';
controlledObject.hero = 'Superman';
// controlledObject will return { name: "Clark Kent" }

Do you know of any other javascript features that may not be popular but useful? share them with us.

A different way of handling required arguments in javascript functions

Enmanuel Durán — Sun, 22 Sep 2019 12:51:37 +0000

Originally posted on Enmascript.com

Usually in javascript if you want to validate required arguments, you would do something similar to this:

function Person(water, food, candy) {
    if (!water || !food) {
        throw new Error('water and food are required for Person');
    }

    // Do something with water and food...
}

The constructor Person Above would throw an error if no water or food is supplied, this is a relatively common and popular way of validating parameters, but there is a different more functional way to achieve this.

Create a helper function that throws an error:

const required = name => {
    throw new Error(`Parameter ${name} is required`);
};

In the case above we are passing an argument name to the function because it feels more natural to print the name of the parameter that is required.

Then we use it like this:

function Person(
    water = required('water'),
    food = required('food'),
    candy
) {
    // Do something with water and food
}

What is happening here? How does this validation work? It is very straight forward:

If we don't pass the required parameter's values, the required function is executed throwing an error and forcing the user to pass each mandatory value everytime the function is invoked.

Passing the name of the parameter to the required function is only a preference; we can decide not to pass it and make the helper function simpler, it is a personal choice.

This approach is not limited to this implementation, we can use this same principle to create our own argument's validators and reuse in our functions to enforce consistency and security.

Do you have ideas that are similar or related to this topic? share them with us.

Two exceptional use cases for the spread operator you may not know of

Enmanuel Durán — Fri, 20 Sep 2019 13:44:37 +0000

originally posted on Enmascript.com

One of the most popular features used in javascript after Ecmascript 2015 is without question the spread operator. In this short "Did you know" article, we will explore a couple of exceptional use cases that we consider to be very useful but that are not so well known.

Optional/Conditional Spreading

Add object properties and values based on a condition:

const isDog = true;

const obj = {
    key: 'value',
    ...(isDog && { woof: true })
};

In this way, we can add the woof property conditionally without having to use any if/else logic or similar approaches... if the condition returns true, it will add the property, otherwise, the object will remain untouched.

result of console.log(obj)

{ key: 'value', woof: true };

Copy objects and exclude selected properties

Let's say we like the parts of certain CPU and we would like to keep most of them except for the ssd, because of course, we would like to have more space:

// Original CPU
const CPU = {
    ram: '32gb',
    ssd: '64gb',
    micro: 'i7'
};

// new CPU copy without the 64GB ssd
const { ssd, ...newCPU } = CPU;

Now, if you console log newCPU you will see that it does not longer contain the ssd property, this happened because we excluded that property from the rest that were included in newCPU by leveraging the rest operator.

result of console.log(newCPU)

{ ram: '16gb', micro: 'i7' };

Do you have any more relevant use cases for the spread operator you would like to comment about? go a head and do that on reddit or twitter in our social links.

Efficient behavioral tracking in javascript applications

Enmanuel Durán — Mon, 15 Jul 2019 12:49:43 +0000

Originally published on Enmascript.com

Tracking is an essential part of product development, either for the web, mobile applications, or any software you might be working on; it is crucial to understand your users to make your business grow. On this article, we are going to explore multiple alternatives and patterns to implement tracking using javascript.

If you don't know what behavioral tracking is or you have not implemented tracking in your projects, I can compress the explanation in a single paragraph:

Behavioral tracking is the way companies get valuable information about meaningful events that have taken place in their platform/applications; this is especially useful to understand how users behave and to identify potential downfalls and opportunities in specific flows.

As you read in the simplistic definition above, it is all about getting valuable information from events, i.e., call to action clicks, users logins... to achieve this as developers, we need a technical implementation that allows us to apply this in an efficient and scalable manner, but, as you will soon realize, tracking comes with some technical challenges.

A starting point

Usually, you find that it is reasonably common between codebases to have isolated modules dedicated for tracking, these modules are just simple encapsulated functionalities that allow you to send information to an endpoint that stores the payload received from the users based on specific types of events.

Below a naive implementation of how a tracking module could look:

class Tracker {
    static get ENDPOINT_URL() {
        return "my.endpoint.domain/tracking"
    }

    async track(payload) {
        const response = await fetch(
            Tracker.ENDPOINT_URL,
            {
                 method: 'POST',
                 headers: {
                     'Content-Type': 'application/json',
                 },
                 body: JSON.stringify(payload)
            }
        );

        return response;
    }

    ...
}

As you can see above, we are just creating a class that contains a method that allows us to post information to an endpoint; this example is overly simple but is enough for this article's purpose, in a real-world escenario you will/should have a model that validates the parameters you want to track and the type of data sent as the payload.

For this article's purpose, we are going to start by having as a target tracking a subscription button, this so that we can understand how many users are engaging with it.

<button class="js-tracked-click subscription-button">
    Subscription Button 1
</button>

Let's see how we can apply different patterns to track this same element.

In module tracking

Consists of importing the tracking module in your application's modules and injecting the tracking function in the pieces of logic/relevant blocks of code. The implementation of this pattern would look something like this:

import Tracker from './Tracker';

class SubscriptionButton {
    constructor() {
        this._buttonHandler();
    }

    _onButtonClick() {
        console.log('Click handler function');

        Tracker.track({
            type: 'click',
            element: 'Subscription_button_1'
        });
    }

    _buttonHandler() {
        const button = document.querySelector('.js-tracked-click');

        button.addEventListener('click', this._onButtonClick.bind(this));
    }

    ...
}

Very simple and functional, this approach is widely used, it has some good and bad parts, lets analyze them:

Pros:

Flexibility. Since we are adding the tracking method inside of the script's functionality, it is effortless to add tracking to pretty much any logic.
Simplicity. Adding trackers is a simple task since it is just a matter of adding the function to the logic that requires it.
Unification. The tracking code is in the same place as the original's script code, while this is bad on one side, it is good in the way that it allows you to be aware of it anytime you have to make a change on functionality.

Const:

Single responsibility is not respected. Adding the tracking functionality inside of script's core code violates the single responsibility principle.
Tracked elements are not easy to identify. Each script contains the tracking functionality on its core which means that we need to go to its definition and look into the code where the tracking might be added
Scalability risk: Since this approach is very flexible it can quickly get out of hand so it might be a good idea to establish some ground rules.

Isolating tracked methods by extending its original definition

Extending the original class is another approach that seeks to isolate the elements that are tracked out of the original's script functionality, the idea is to extend the code to create an extra layer dedicated to tracking events, let's see an example:

We implement the script functionality:

class SubscriptionButton {
    constructor() {
        this._buttonHandler();
    }

    _buttonHandler() {
        this._button = document.querySelector('.js-tracked-click');

        this._button.addEventListener('click', this.onButtonClick.bind(this));
    }

    _onButtonClick() {
        this.elementHasClass = e.currentTarget.classList.contains('subscription-button');

        if (this.elementHasClass) {
            console.log('Click handler function');
        }
    }

    ...
}

then we implement the tracking:

import Tracker from './Tracker';

class TrackedSubscriptionButton extends SubscriptionButton {
    constructor() {
        super();

        this._trackedMethods();
    }

    _trackedMethods() {
        this._onButtonClickTracking();
        this._anotherTrackedElement();
    }

    _onButtonClickTracking() {
        if (super.elementHasClass) {
            super._button.addEventListener(
                'click',
                () => Tracker.track({
                    type: 'click',
                    element: 'Subscription_button_1'
                });
            );
        }
    }

    _anotherTrackedElement() { ... }
}

Notice how we are able to isolate the tracking related code in a different class, it is essential that you realize that we have to be careful to not duplicate the logic for the element you want to track, make sure the logic is trackable and reusable from the original class, notice that in the case above we are using a new event listener and condition, but the condition is actually the same from the parent's class, we are just reusing the property that defines it. This approach does not have to be implemented with inheritance; if you'd like to write functional and declarative code instead, you can use a Higher Order Function that wraps the tracking functionality.

Pros

Tracking code is isolated. Single responsibility principle is respected.
Tracked elements are natural to detect, modify, and delete, this is simple to achieve since everything is a single place per each module.
Scalability. If this approach is well applied, you can scale your codebase easily.

Const

Flexible but with constraints. We can add tracking to any element we want, but we always have to keep the tracking class into mind..
Mindset change. When using this approach you need to always have tracking in your mind in the same way you do with unit testing, you always need to make sure your code is trackable in the isolated class, this can be good but has to be well thought.
Dangerous code and duplicated logic. If you notice the tracking class, you will see we are adding a specific listener to track the click event, this can be dangerous especially if there is logic you need to add around the tracking (like a conditional). Also, you will have to expose properties through this so that the parent class can be inherited and used.

A Custom approach

Another way to keep tracking scalable and personalized is to create a customized centric tracking system, this pattern is prevalent and I have seen it being used in multiple companies, it usually consists on tracking interactions based on dataset properties, for example let's say you want to track a click on an element:

Elements to track:

<button data-click-tracking="subscription_button_left">
    Subscribe
</button>

<button data-click-tracking="subscription_button_right">
    Subscribe
</button>

Unified click tracker functionality:

import Tracker from './Tracker';

class ClickTracker {
    constructor() {
        this._bindClicks();
    }

    static get TRACKED_ATTRIBUTE() {
        return 'data-click-tracking';
    }

    static get TRACKED_ELEMENTS() {
        return document.querySelectorAll(`[${ClickTracker.TRACKED_ATTRIBUTE}]`);
    }

    _onClickHandler(event) {
        const element = event.currentTarget.getAttribute(ClickTracker.TRACKED_ATTRIBUTE);

        Tracker.track({ type: 'click', element }));
    }

    _bindClicks() {
        ClickTracker.TRACKED_ELEMENTS.forEach(element => {
            element.addEventListener('click', this._onClickHandler.bind(this));
        });
    }
}

In this way, all click tracked elements pass over the click handler and we are able to identify them by using a custom id passed through the dataset property. An excellent example of companies using this approach is Google on google tag manager where you can define custom classes or data properties to be tracked and send information to Google Analytics. I consider this approach to be the best of the ones mentioned so far since you can apply this same pattern for other types of events like scroll events, it is not limited to clicks.

Pros

Custom implementation. Made for the specific needs of the company.
Scalability. A single script is in charge of the tracking so the other scripts remain untouched.
Single Responsibility, it is preserved because the tracking functionality is in a dedicated module.

Cons

Constraints are present. Since this approach consist on tracking elements from the DOM, it wont be possible to cover all the cases, you will find out that especial functionalities still need to be tracked on its core code, this means that in especial ocassions you will have to import the tracking module and decide which approach you want to take In module tracking or extended approach.

Tracking asynchronous requests

Generally, you find yourself needing to track a form submission or a login event, for many reasons is not efficient to add the tracking to the button that submits the information (The login could fail, or the form request could return an error) which means we would be tracking data incorrectly.

For this, you could use the In module tracking approach by adding the tracking function to the 200 response, this would be fine but we would endup with multiple conditions for each request needed to be tracked.

let's say you have a centralized HTTP client that you use for all asynchronous request (which will almost always be the case); this client returns a promise so that you can execute some code per module, then we get assigned some tracking requirements as follow:

We would like to track the following events to get some meaningful information about our users and to learn how we can improve their experience on the platform:

Successful login events
Successful Subscription events
Logout events
Call to action clicks

So we notice that the call to action click can be easily tracked with a click tracking event, but what about the other ones? All of them are different events using different URLs and needing different data to be tracked, so if we use a centralize HTTP client it would look something like this:

function HTTPPost(url = '', data = {}) {
    return fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
         },
        cache: 'no-cache',
        redirect: 'follow',
        referrer: 'no-referrer',
        body: JSON.stringify(data),
    })
    .then(response => response.json());
}

export default HTTPPost;

and then we would be able to use it to track data like:

import HTTPPost from './http-client';

HTTPPost('/api/login', {userId, password, source: 'modal' })
    .then(response => {
        Tracker.track({ type: 'successful-login', ...response })
    }
    .catch(error => console.error(error))

The approach above is not actually bad but we would have to import the Tracker module in every file that will execute the successful asynchronous request which sometimes is something that will be a let down depending on the company's policies.

Centralizing Asynchronous tracking

This will be the last approach we will cover on this article and it is one that I really like. The fundaments of this approach relies on adding the tracking function once in the HTTPPost method, then we can leverage a dictionary that will contain the URLs we want to track, these will be mapped to a model of properties where each URL will require to be successfully tracked, something like this:

Let's explain with code step by step:

1) We add the tracking in the HTTPClient

We basically take the code from the previous approach and add the tracking on the promise response:

import Tracker from './Tracker';

function HTTPPost(url = '', data = {}) {
    return fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
         },
        cache: 'no-cache',
        redirect: 'follow',
        referrer: 'no-referrer',
        body: JSON.stringify(data),
    })
    .then(response => response.json())
    .then(response => Tracker.request(url, response));
}

export default HTTPPost;

As you see we are executing Tracker.request on all requests, now we have to define which requests we actually want to track and which parameters are relevant to be tracked for those requests, so we can make use of a dictionary like this:

const TRACKED_URLS = {
    '/api/login': ['userId', 'source', 'url', 'type'],
    '/api/logout': ['userId', 'time', 'type'],
    'api/subscription': ['userId', 'source', 'type'],
    ...
};

export default TRACKED_URLS;

In the example above we are using a list to store the valid properties just to make the example simpler, you can create a real model that properly validates the information that each tracked URL needs. After this, the method in charge of tracking the requests could be added to the tracking module. We can do something like this:

import TRACKED_URLS from './tracked-urls';

class Tracker {
    static get ENDPOINT_URL() {
        return "my.endpoint.domain/tracking"
    }

    async track(payload) {
        const response = await fetch(
            Tracker.ENDPOINT_URL,
            {
                 method: 'POST',
                 headers: {
                     'Content-Type': 'application/json',
                 },
                 body: JSON.stringify(payload)
            }
        );

        return response;
    }

    request(url, data) {
        const URL_PROPERTIES = TRACKED_URLS[url];
        const PAYLOAD_PROPERTIES = Object.keys(data);

        const arePropertiesValid = URL_PROPERTIES
            && URL_PROPERTIES.every(property => (
                PAYLOAD_PROPERTIES.includes(property)
            ));

        if (!arePropertiesValid) return false;

        this.track(data);
    }
}

Very simple, the request method just verifies that all the tracked elements have the correct properties passed, it serves as a centralized filter and as a centralized request's tracking dictionary, This approach is straight forward and scales very well because you have all the tracked URL's in a single place which allows you to add and delete on demand quickly.

As stated at the beginning, this article's intention is to show the good and the bad parts of each tracking implementation so that you can decide which one is better for you and your team.

That is it for now, I hope you have enjoyed it -- if you did, remember that you can share it with your friends or leave a comment on reddit or twitter by clicking on the social links.

See you in the next one!

Code quality and web performance, the myths, the do's and the don'ts

Enmanuel Durán — Tue, 04 Jun 2019 14:38:56 +0000

This article was originally posted on Enmascript.com

Optimization is a word that englobes a significant scope of possibilities, especially in the world of software development. Developers always like to "optimize," but what is it really? -- This word is many times miss-used to excuse subjective point of views, other times it is used only to demonstrate "improvements" that are not sincerely necessary. In this article, we are going to be talking about the mistakes we make as developers when trying to improve our code bases by "optimizing" them, and, we are going to see which are some excellent ways to start doing this correctly.

Always measure first, quantify, and please... don't just blindly "optimize".

A fundamental lesson that we as software developer learn with the years is that numbers matter, something is impactful if you have a way of quantifying the co-relation between the effort you have applied to it and the results it has given.

For example, there is a common belief that lines of code are somehow inversely related to higher performance or better quality.

Usually having less code means less surface area to cover, which means, more clarity and less possibility of bugs. However, this only applies if you have a "high quality" code base that is secure, consistent and is using the right tools for the right job.

Let me elaborate a little bit, take the following piece of code:

const mainWrapper = document.querySelector('.wrapper');


if (mainWrapper) {
    const element = document.querySelector('.inner-box');

    element.classList.add(enabledInteractionClass);
    mainWrapper.classList.remove(enabledInteractionClass);
}

There is nothing wrong with the code above. It just has an extra couple of variables to make the code more declarative. I have seen code reviews where people convert this implementation to:

const mainWrapper = document.querySelector('.wrapper');
let enabledInteractionClass = 'enabled-box';

const enabledElementClass = mainWrapper
    ? document.querySelector('.inner-elm').classList.add(enabledInteractionClass)
    : mainWrapper.classList.add(enabledInteractionClass);

Then, the argument comes where a developer says, "we can avoid the extra variable for document.querySelector('.inner-elm')" and he/she calls this an optimization, your answer is that you like it more the first way because it is more declarative in comparison, and you spent 5 mins discussing this. What the code reviewer does not realize is that he is now defining enabledInteractionClass all the time, and he is using the variable enabledElementClass for something that does not require it, so where is the improvement? Was this a decision based on a solid foundation? How does this code make the codebase better? is it measurable?

Disclaimer: I'm in favor of well constructed/used ternary operators and short-circuiting, this example just shows how NOT to use a tool just for the sake of less lines of code or to defend a subjective point of view.

There is a term for worthless micro-optimizations that end up in a waste of time.

Bikeshedding is the art of wasting time by having technical disputes over minor, marginal issues, issues that won't have a real positive impact in your work while there are more important things to look at. So, the next time someone wants to argue over insignificant improvements, just say the word bikeshedding. The etymology for this term can be found on wiktionary.org and urbandictionary has another good definition for it.

The point being, micro-optimizations are something you should avoid doing without basis, if you want to optimize some code, measure and identify bottlenecks first.

Measure first

Suppose your website/application is a little bit slow when you scroll, don't just go and increase the throttle time for your listener and mark it as done, analyze what is going on and understand what the reason behind this issue is. A way to measure scroll performance is through Frames Per Second (FPS), so you know you have a quantifiable way to understand what is happening and a starting point.

Let's see a good way to tackle this problem

First, check if the code/tasks executed on the scroll are doing what they suppose to be doing, scroll junkiness could be caused by memory leaks.
If the code is wrong, fix it, if it is ok look at your alternatives:
- Can we use IntersectionObserver instead of the scroll event?
- Is throttle needed? can we debounce it?
If after looking at your alternatives you don't see any other option then as a last resource consider increasing the throttle time.

Why to go through all this trouble instead of just increasing the time? because nothing ensures you that after increasing the time it won't happen again, or even worst, nothing ensures that there is not a more important issue underneath.

This is just an example applied to scroll performance, but the same principle can be applied over any other circumstance by having the correct metric to measure.

Improve the quality of your code base

Some of the most common ways of optimizing code bases are linters, if you use javascript ESLint is a good one -- As for your styles, you could use Stylelint. You can later add these two elements as required steps in your build process to create an extra layer of consistency, linters are a good way to promote consistency in your code base.

Nevertheless, linters alone are not going to guarantee the quality of your code base, it heavily depends on the level of your team, you have to be aware of this before trying to push things too hard. Some recommendations to start increasing the quality of your codebase are:

Promote design patterns. (We have written about some of them, i.e Observer Pattern, Factory Pattern, Builder) you don't have to use these explicitly, remember, the idea is to use the right tool for the right job, design patterns are not always the best option, but they are for sure a way of adding consistency and security to your application.
Pairing Sessions / Brainstorming. Some hugely underestimated and yet powerful tools are communication and teamwork, make sure the team communicates their ideas before implementing them at least with one other person, this ensures that the knowledge spreads, more people gets involved and gives their opinion. Together you will find a more solid approach to solve a problem and you will avoid the fatigue of rejected pull requests, a couple of good ways to promote team communication are Katas and RFC's.
Your future self matters. When you write code or make a code review, think in your future self, what would happen tomorrow if you had to scale your module? I like to follow the DIRTFT (Do It Right The First Time) principle, this is certainly not easy to do, even today I don't get to write the best possible code I can when I do it the first time, but I iterate over it until I get to a place where I feel comfortable with it.
Think before you code. Create a model about what you have to do, understand what is needed and the alternatives you have, never start writing code right away before analyzing the implementation.
Care about data structures and time/space complexity. This point requires deeper knowledge on how algorithms work and why. I have personally noticed that the more experienced the team is the more they care about this, in the frontend world there is a miss-conception that data structures/time space complexity does not matter as much, but this is a mistake, these tools allow you to write scalable/performant modules, it is part of choosing the right tool for the right job.

There is not a fixed formula for code quality, this is a progressive and subjective topic, it highly depends on the requirements of the company you are working on and your team. One last recommendation I could give you is to cosider promoting declarative code, give attention to the readability.

Recommendations, tips and good practices to optimize your site (Performance):

One excellent way to measure your site's performance is through the RAIL model. Below I have a list of some common problems that websites confront and some possible tools that could help you solve them, this list is not meant to solve your problems directly but to point you in the right direction:

Unused code

Impact metric: Bytes / Download time
Helpful tools: webpack-bundle-analyzer, Chrome Coverage
possible solutions: Tree Shaking

Scroll Junk

Impact metric: Frames Per Second (FPS) / Page Interaction
Helpful tools: Chrome's FPS meter, Chrome's FPS Chart, Chrome's Frames Section
possible solutions: Intersection Observer, Throttling, Debouncing

Heavy/Slow Animations

Impact metric: Frames Per Second (FPS) / UI / UX
Helpful tools: Same as Scroll Junk
possible solutions: CSS will-change property, Use properties that are processed by the GPU

Elevated Number of Network Requests

Impact metric: Seconds/Milliseconds Load Time / Application Response Time
Helpful tools: Memoizer, Redis
possible solutions: Memoization, Caching

Memory Leaks

Impact metric: Bytes / Browsers Memory
Helpful tools: Chrome's Heap Snapshot
possible solutions: Closures, Remove dettached DOM nodes

Extra tools

There are many other metrics and important optimizations you can make, it is impossible to fit them all in a list but the tools below are a big help as far as web optimization is concerned:

This is just a starting point

The path to web performance and code quality is long, it is not straightforward in most of the cases, there are some things that you only learn from experience. This article is meant to be a starting point for those who are looking for directions but don't know where to start or how to start.

Hope you have enjoyed this article, see you in the next one!

Avoid recomputing heavy tasks by leveraging memoization in javascript

Enmanuel Durán — Mon, 22 Apr 2019 13:09:22 +0000

Originally posted in Enmascript

Javascript is an wonderful dynamic language; it allows us to do many things either on the backend layer with Node or the frontend of our application. One of the things that we do the most in javascript is endpoint calls that are later used to compute information and finally show it to the user in a friendly and polished way. We usually try to avoid at all cost additional requests and computations so that our application performs at its best. On this article, we're going to be exploring a technique that will help us improve on this matter, so without further ado let's get into it.

The premise

The idea is to take advantage of the browser's memory to store data that usually requires heavy computations to obtain it, and that's likely to be reused in the future, in this way we have the information ready to be accessed, and we don't have to re-run tasks to get it, this technique is known as memoization.

Understanding the dynamic behind it

The image below explains the basic flow behind memoization to understand better how it fits in our application:

Let's analyze this image:

We're trying to call a memoized function with arguments A and B. Before executing it the memoization layer checks if it was called in the past with the same arguments, but, since it's not the case, it passes the information over and executes it on the first request (Request #1). The function then makes the computations and returns the result to the memoization layer where it's stored for later use. Now, the next time we try to run the function with the same parameters, the memoization layer will check if the arguments are recurrent, and, since they'll be we'll get the information from memory (Request #2) and then return it to us directly.

When to apply

It's recommended that we employ this technique when our function meets the following requirements:

Performs heavy tasks, therefore storing the result might help us save some processing time in our application.
Consistently receives the same arguments, so that we can avoid re-computing repeated data.

What is required to memoize our functions?

Ideally, to memoize a function it should follow the principles of purity, meaning that it should not contain side effects, it should explicitly depend on its arguments and return the same output for the same arguments passed. In this way, we can guarantee a successful memoization layer that's automatic and argument-dependent; this is pivotal for the technique to work consistently.

A use case

As mentioned at the beginning, one good use case for memoization is to avoid making extra network requests when the data we need has been already fetched and the computations to clean and show these data were already executed.

If you have what we call a "robust" architecture, you probably have a caching layer in the backend like Redis to avoid receiving consecutive hits on the database every time a user asks for recurrent information. If we apply this technique to the function that executes the GET request, we can even avoid making the endpoint call meaning that the network won't get agglomerated with tasks. Let's see how we can interpret this:

Now, this being said, memoization is something you'll apply in your applications as you notice that your functions meet the requirements.

Implementing a simple memoizer

Ok, it's been enough drawing and theory, let's create our own custom memoizer.

For what we've learned we know that the memoizer should receive a function as argument, then, we need to store the results in some data structure to be able to retrieve them later based on the function and arguments passed, let's see:

/**
 * Receives a function which would be memoized
 */
function memoize(fn) {
    /* we'll use this object to store the results */
    let cache = {};

    /**
     * Returns a function that will receive the arguments
     * that will be passed to the memoized function (fn).
     */
    return (...args) => {
        /* We stringify the arguments in case they're non-primitive values */
        const cacheKey = JSON.stringify(args);

        /* were the arguments already passed? if no, then store the result */
        if (!(cacheKey in cache)) {
            cache[cacheKey] = fn(...args);
        }

        /* We then return the stored result */
        return cache[cacheKey];
    };
}

And then we would use it like this:

/* A simple add function that will be memoized */
function add(a,b) {
    console.log('Executing the sum');

    return a + b;
}

/* we pass the function definition to the memoizer */
const memoizedAdd = memoize(add);

/* we now run the memoized add function */
memoizedAdd(1,2); // logs "Executing the sum" and returns 3
memoizedAdd(1,2) // doesn't log anything, returns 3 directly.

In the implementation of the memoize function persistency works thanks to closures, The cache object is stored in memory thanks to the variable memoizedAdd, then, thanks to that variable we're able to execute the returned function and get the results as needed. If you have issues trying to understand this concept, I recommend you to read the article about Higher Order Functions.

A better implementation

If you analyze the previous implementation a little bit you will realize that we have to worry about a couple of things:

Memory consumption, if the results and keys we're storing are large sets of data and we store them multiple times this could cause memory issues in the future, this won't happen often but it's important to keep it in mind.

Knowing this, here a more complete implementation that will allow you to clear the cached elements.

function memoize(fn) {
    let cache = {};

    function clear() {
        cache = {};
    }

    function get() {
        return Object.freeze(Object.assign({}, cache));
    }

    function count() {
        return Object.keys(cache).length;
    }

    function process() {
        const cacheKey = JSON.stringify(arguments);

        if (cacheKey in cache) {
            return cache[cacheKey];
        }

        cache[cacheKey] = fn.apply(null, arguments);

        return cache[cacheKey];
    }

    return Object.freeze({
        process,
        clear,
        count,
        get
    });
}

With this we're able to clear the cache manually when we need it, and example of usage:

const memoizedAdd = memoize(add);

memoizedAdd.process(1,2); // Executes the function
memoizedAdd.process(1,2); // Hits the cache

memoizedAdd.get(); // returns the object with the memoized elements
memoizedAdd.count(); // returns the number of elements stored so far
memoizedAdd.clear(); // clears the cache

And just like that we have a more complete implementation. Also, thanks to the count and clear method we can clear the cache when we consider it relevant.

It's worth mentioning that this technique is widely used, if you have used selectors in redux in the past you'll find out that Reselect applies memoization; also libraries like lodash have their own implementation...

Important to know: you don't explicitly need a function called memoize or an isolated function for that matter to apply this technique, as long as your implementation respects the principle behind memoization, you can implement it in a custom way based on the functions you're working on, the examples on this article are just a reusable way to apply this principle.

Ok, guys, I think that's it for now, I hope you've enjoyed the article... If it was the case remember to share it with your friends and coworkers. If any questions remember you can catch me in twitter at @duranenmanuel.

See you in the next one!