Forem: Soumava Banerjee

Typescript as a javascript developer - I

Soumava Banerjee — Wed, 01 Mar 2023 15:27:30 +0000

Over the past decade, the adoption of Typescript has been a major breakthrough in web development. Employers are increasingly seeking developers with knowledge of Typescript to prevent technical debt. Unlike dynamically-typed languages that offer ease in development, Typescript helps prevent runtime errors and bugs. Therefore, learning Typescript has become essential for web developers looking to secure job opportunities.

That being said, making the transition from javascript to typescript is a daunting task. More so if one is not familiar with any statically typed language. In this article, I'm gonna share my experience in solving problems with typescript.

A Little Intro to Typescript

Typescript is a superset of javascript. This means that typescript incorporates everything javascript has to offer and has its own type system. This type system is largely what allows for more efficient and secure coding practices, reducing the likelihood of errors and improving the overall quality of the code. Throughout this article, there would be various code examples. If you wanna follow along (which I highly recommend you do) head over to official typescript playground.

The basics !

Let's start with the primitives first and look at some code.

const x: string = "hello"
const y: number = 3
const z: boolean = true

This part is rather intuitive. By applying types to variables, you can put restrictions over the type of data that variable holds. Deviating from the defined type will throw errors!

// Type 'number' is not assignable to type 'string'.
const x: string = 42

This is the very basics of typescript and everything that's gonna lie ahead, follows this core fundamental; albeit in much more complex ways.

Types and Interfaces

In real life project, we very often find the need to represent real world objects in terms of code. Types and interfaces help us represent exactly that. Let's take an example of a simple shopping cart. In our cart, we would be placing items and when our shopping would be over, we gotta do a checkout and pay the total amount!

Pro Tip: THINK about the properties and type before you write even a single line of code.

We will be defining exactly what our cart items look like. Let's say they have a name, price and quantity.

// The id lets us uniquely identify our items!
type CartItem = {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

Now, shopping cart will be just an array of these cart items.

interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

type ShoppingCart = CartItem[];

Interfaces vs Types - which to use and when?

Both of them basically do the same thing. While starting out, it's more of a personal preference. However, it's important to be consistent in your codebase and choose a style that works best for you.

Personally, I use interfaces to describe shape of any real world object and only use types if I need to apply utilities on it like intersection and union. You don't need to worry about these stuff if you are new to typescript.

Functions and how to type them

Let's see an example of a simple sum function. Try to

function sumFn(a: number, b: number):number {
    return a + b
}

const sumArrowfn = (a: number, b: number):number =>  a + b

as you can see, we can type annotate the parameter a:number just like we have been doing before. We can also specify the return type of that function after the closing parenthesis.

Adding functionality to our cart

Now that we understand how to type a function, let's add some functionality to our cart. We will be implementing the following 2 features -

add items to the cart
delete items from the cart

Add items to cart

How can we add items to a cart ? We will provide a Cart and an Item. Our expectation from the function would be that it returns us a Cart array with the item. But what will happen if the item we are gonna add already exist in the cart ? In that case, we would simply increment the quantity. So, the simplified logic would be like this -

If the item does not exist previously in the Cart, push the item into the Cart.
If the item does exist, we simply increment the quantity of the item in the Cart.

Now that we have our logic defined, we can easily type annotate the parameters of the function and also specify it's return type.

Let's see the code in action:

interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

type ShoppingCart = CartItem[];

const addItem = (cart: ShoppingCart, item: CartItem): ShoppingCart => {
  const existingItem = cart.find((i) => i.id === item.id);
  if (existingItem) {
    existingItem.quantity += item.quantity;
  } else {
    cart.push(item);
  }
  return cart;
}

If you are in a typescript playground or your local editor, try hovering over the first existingItem. It will show you the type as CartItem | undefined. This is because the find method returns undefined if there are no matching elements and typescript understands this. Here, if instead of that if check, I write a buggy code cart.push(existingItem);, typescript will immediately throw an error:

Typescript throws this error cause existingItems may contain undefined but our type definition for the return type of the addItem function was ShoppingCart.

Typescript forces us to think about the corner cases and handle the code according to the type definitions we set up. This is one of the main pros of typescript.

Remove product from cart

This is straightforward. We pass the id of the item to be deleted and the cart. From the id we can get the index of the item to be deleted and then just remove it using splice.

Let's see that in action:

interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

type ShoppingCart = CartItem[];

const addItem = (cart: ShoppingCart, item: CartItem): ShoppingCart => {
  const existingItem = cart.find((i) => i.id === item.id);
  if (existingItem) {
    existingItem.quantity += item.quantity;
  } else {
    cart.push(item);
  }
  return cart;
}

const removeItem = (cart: ShoppingCart, id: number): ShoppingCart => {
  const itemIndex = cart.findIndex((i) => i.id === id);
  if (itemIndex >= 0) {
    cart.splice(itemIndex, 1);
  }
  return cart;
}

Full code in action

Here's the little shopping cart we have built. Can you implement a function that returns the all total price of the items in the cart ? Comment down the solution !

interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

type ShoppingCart = CartItem[];

const addItem = (cart: ShoppingCart, item: CartItem): ShoppingCart => {
  const existingItem = cart.find((i) => i.id === item.id);
  if (existingItem) {
    existingItem.quantity += item.quantity;
  } else {
    cart.push(item);
  }
  return cart;
}

const removeItem = (cart: ShoppingCart, id: number): ShoppingCart => {
  const itemIndex = cart.findIndex((i) => i.id === id);
  if (itemIndex >= 0) {
    cart.splice(itemIndex, 1);
  }
  return cart;
}

let cart: ShoppingCart = [];
cart = addItem(cart, { id: 1, name: "Cheese", price: 10, quantity: 2 });
cart = addItem(cart, { id: 2, name: "Chocolate", price: 20, quantity: 1 });

console.log(cart)

cart = removeItem(cart, 2)

console.log(cart)

Conclusion

The stuff mentioned in this blog just scratches the surface of what Typescript is capable of. There are more advanced features like Generics, type Utilities, type guards and type inferences, things like any, never and unknown types, etc. Further blog posts will illustrate how to use them and the mental models that helped me to apply these concepts to real world projects.

Function Currying: Javascript Questions

Soumava Banerjee — Sun, 11 Sep 2022 13:54:12 +0000

A Little Introduction

Currying happens when a function does not receive all of its parameters at once. It instead takes the first parameter and returns a different function. The returned function should be invoked with the second parameter, which should return another function.This continues until all the arguments have been presented. The function at the end of the chain will then be the one that returns the desired value.

// This is a normal function
sum(1,2,3)

// while this is a curried function
sum(1)(2)(3)

It is important to note that currying only alters the construct of a function and not it's functionality.

Question-1: sum(1)(2)

This is fairly straightforward. The syntax might be a bit weird to those who see it for the first time. Basically, we keep returning a function and pass it one argument. This continues after we have finished passing all the arguments. At the last stage, we have access to all the previously passed arguments due to the power of closures. It is at this stage, that we execute our logic.

function sum(a){
 return function(b){
   return a + b;
 }
}

// dry-run
// add(1)(2)
// step - 1: add(1) executes and returns a function

// (function(b){
//   return 1 + b;
// })(2)

// step - 2: returned function executes with 2 passed as parameter.

// (function(2){
//   return 1 + 2 //> it gets value of 1 from closure!
// })

// outputs 3

console.log(sum(1)(2)) //logs 6

Question-2: sum(1)(2)(3)(4)...(n)()

This question is a direct extension of the first one. Catch is, number of arguments can be infinite! This problem is commonly known as infinite currying and is a popular interview question.

Always solve for a smaller subproblem.

// with 2 arguments
function sum2(a){
 return function(b){
   return a + b;
 }
}

// with 3 arguments
function sum3(a){
 return function(b){
   return function(c){
     return a + b + c;
   }
 }
}

// notice the pattern here ? At every level,
// If there is another argument left, we return a new function
// else we execute the logic. Recursive thinking is required for // these pattern of problems.

//with n-arguments
function sum(a) {
  return function(b){
    if(b){
      return sum(a+b);
    }
    return a;
  }
}

// dry-run
// example -> sumN(1)(2)(3)(4)

// step-1 
//   sumN(1) executes

// step-2 
//   (function(b){
//     if(b){
//       return sumN(1+b);
//     }
//     return a;
//   })(2)(3)(4)

// step-3
//    (function(2){
//     if(2){
//       return sumN(1+2); // again call to sum
//     }
//     //> won't execute
//     return a;
//   })(3)(4)


// // Notice the recursive pattern ?
// step-4 
//    (function sumN(3) {
//     return function(b){
//       if(b){
//         return sumN(3+b);
//       }
//       return a;
//     }
// })(3)(4)

// step-5
//   (function sumN(3) {
//   return function(3){
//     if(b){
//       return sumN(3+3);
//     }
//     return a;
//   }
// })(4)

// step-6
//  (function sumN(6) {
//   return function(b){
//     if(b){
//       return sumN(6+b);
//     }
//     return a;
//   }
// })(4)

// step-7
//   (function(4){
//     if(4){
//       return sumN(6+4);
//     }
//     return a;
//   })

// step-8
//   sumN(10)

// step-9
//   (function(undefined){
//     if(undefined){
//       //> won't execute
//       return sum(a+b);
//     }
//     return 10;
//   })()

// step-10
//   logs 10

I'd highly recommend writing the code in any IDE and do a dry run yourself

Question-3 sum(1,2,...,n)(3,4,...,n)...(n)()

We are stepping up the game here. In this pattern, number of arguments in a single call can be infinite as well! We will use knowledge gained from the last problem to solve this.

hint: this problem can directly be reduced to the last problem

// we just reduce the arguments into a single argument for
// a single call! Now it's just like the previous problem!
function sum(...args) {
  let a = args.reduce((a, b) => a + b, 0)
  return function(...args){
    let b = args.reduce((a, b) => a + b, 0)
    if(b){
      return sum(a+b)
    }
    return a
  }
}

Question-4 implement function currify

Currify will be a function that takes in another function as argument and returns a currified version of the same function! Note that it does not modify the functionality of the passed function by any means. It only transforms the function.

Now, this one is a little tricky.

The general idea to solve the problem is like this:

Currify will take a function as argument.
Currify will return another function.
The use-case of that function will be to somehow store all the arguments that are being passed, until there are no more arguments to pass.
Once all the arguments are exhausted, we can simply call the passed function with all the accumulated arguments and our job will be done.

below is the above idea expressed in code.

function currify(fn) {
  return function saveCurryArgs() {
    const args = Array.prototype.slice.call(arguments); // a
    if (args.length >= fn.length) // b
      return fn.apply(null,args); //c
    else 
      return saveCurryArgs.bind(null, ...args); //d
  }
}

const multiply = function(a,b,c){
  return a + b + c 
}

const curryMultiply  = currify(multiply);

// logs 6
console.log(curryMultiply(1)(2)(3));

Let's understand exactly what it's doing and how it's doing it.
I've commented main logic points in the code with alphabets.

a) We construct our list of arguments from the array-like object arguments.

b) args.length represents arguments received so far. fn.length denotes the total number of arguments that are to be processed.

c) This logic executes after we have exhausted all our arguments. We simply use the apply method on fn.

d) Else, we save the current arguments with all the previous arguments by calling bind over the saveCurryArgs function.

With this, our logic for currify is complete!

Conclusion

If you've managed to come this far, congratulations! Currying is an extremely important topic from an interview point of view as well as real world use-cases. I'd again recommend coding out the examples over codepen or your local IDE. Hope you enjoyed the article! Thanks for the read!

Inversion of Control - Improve your abstractions

Soumava Banerjee — Sun, 04 Sep 2022 13:17:37 +0000

What problem does it solve?

The formulation of the problem is often more essential than its solution

If you have been writing code for a while, I'm sure you have written functionalities that are used in more than one place. It could be:

An utility function that does a certain task.
A React component that you have reused in multiple places.
A wrapper component that encapsulates some functionality.

Whatever it is, it's very likely that you've stumbled upon the following pattern of problems while you try to write good code:

You create a reusable piece of functionality.
Some use case arises that your reusable code does not support.
You add options in your code (through arguments / props) and clump together chains of if-else statements.
Consequently, the file continues to grow larger and the abstraction feels like a burden than a utility.

This whole scenario creates two major problems:

1. Unnecessary implementational overhead: All those branching if-else statements makes the component harder to test and decreases code readability. Also, each new if-else block compounds to the existing complexity of the code.

2.Complicated api overhead: With each new prop/argument arises the need for updating the documentation for end users (such as a future you). Also there are times when the specific functionality an end user requires is missing in the piece of code. In such cases, the developer might have to search an endless sea of documentation to verify if their use case is supported.

The Solution - Inversion of Control 🔥

Inversion of Control is a design principle. In simple terms, you define the abstractions that control the logic flow and let the developer provide their custom logic. So, your abstractions "does less work" while the "end user does more". This may seem counterintuitive but it's very powerful.

Enough talk, let's code!

In this exercise, we will be implementing a simple sorting function! Initial implementation would be a naive abstraction. Then we will refactor it and implement the inversion of control design principle.

const sortArray = (array) => array.sort();

Now, this generic sort function is not enough for all the use cases as it sorts on the basis of alphabetical order only. Let's add the feature to specify the order of sort - either ascending or descending!

const sortArray = (array, order="ascending") => {
  if(order === "ascending")
    return array.sort((a,b) => a - b);
  else if(order === "descending")
    return array.sort((a,b) => b - a);
  else
   throw new Error("sorting order not valid")
}

// logs [100,2,2,1,1]
console.log(sortArray([1,2,100,2,1], order="descending"));

And it's working. After some days, there comes another requirement: Support for Array of Objects. Sort them using their keys.

To support this new requirement, we again add a new flag, sortObject and implement our logic.

const sortArray = (array, sortObject, key, order="ascending") => {
  if(sortObject) {
    if(order === "ascending")
      return array.sort((a,b) => a[key] - b[key]);
    else if(order === "descending")
      return array.sort((a,b) => b[key] - a[key]);
    else
     throw new Error("sorting order not valid")
  } else {
    if(order === "ascending")
      return array.sort((a,b) => a - b);
    else if(order === "descending")
      return array.sort((a,b) => b - a);
    else
      throw new Error("sorting order not valid")
  }

}

//logs [{key: 2, name: "B"}, {key: 1, name: "A"}]
console.log(sortArray([{key: 1, name: "A"}, {key: 2, name: "B"}], true, "key", order="descending"));

As you can see, each new requirement compounds upon our existing pile of code, thereby creating an "if-else hell". Requirements will continue to grow in the future. So do we have a way out ? Of Course we do!

Let's refactor based on IOC principle.

We will leave "how the sorting will take place" upto the developer. Our job is to just declare the abstraction, direct the logical flow and return the desired output. With this, the code becomes something like this:

const sortArray = (array, sortFn) => {
  if (sortFn) {
    return array.sort(sortFn);
  }
  return array.sort();
}

// logs [4,3,2,1]
console.log(sortArray([1,2,3,4], sortFn = (a,b) => b - a))

//logs [{key: 2, name: "B"}, {key: 1, name: "A"}]
console.log(sortArray([{key: 1, name: "A"}, {key: 2, name: "B"}], sortFn = (a,b) => b["key"] - a["key"]));

And with that, you can see the difference! Our code is modular and we have delegated the responsibility of defining the sorting function to the end user. Testing this new piece of code is much more easier than before too!

Do you feel you've seen this pattern before ?

Sure you have. Many common inbuilt functions like map, filter, reduce, sort, forEach implement this design principle!

Not only that, React hooks, state-reducer pattern is based on IOC too. Many web frameworks are based on this principle. Dependency Injection, a common and important design pattern, is based on the principle of IOC as well.

Conclusion

Just like any other tool, we should understand the need to implement IOC. If we have an idea of conditions and branches in our logic, we can implement non-inverted abstractions. On the other hand, if we are dealing with unknown number of functionality extensions, inverting the control might be the ideal choice.

Extra bit!

Part 2 of this article would feature how to use Inversion of Control to implement role based protected routes using react and react-router-dom v6. Stay tuned!

Credits:

This article is heavily inspired from Kent C. Dodds 's article on the same. Here's the link to the article.