DEV Community: Ankit Tanna

JavaScript: Avoid Run-Time Console Errors

Ankit Tanna — Sun, 12 Sep 2021 18:48:51 +0000

I HATE RUN-TIME CONSOLE ERRORS

Here, I have said it in big bold capital letters. Usually they arise because you try to access a property of undefined or null.

You must have been aware of this dreadful image:

This happens usually when we try to do something like this:

function printPersonDetails(person) {
   console.log(person.age);
}

printPersonDetails(undefined);

As soon as you pass person as undefined the clock of the doomsday starts ticking and at any moment when this function is triggered, you shall see the run-time error.

You might argue that you could write unit tests but since JavaScript provides all the fallback mechanisms in place then why wait for unit tests to be written.

Option 1 - Use default values for function parameters

This is the least a developer should do.

Before

function add(a, b, c) {
   return a + b + c;
}

add(1, undefined, 2); // Run-time error

After

function add(a=0, b=0, c=0) {
   return a + b + c;
}

add(1, undefined, 2); // Run-time error

Providing default values to parameters is a good practice.

Option 2 - Nullish coalescing operator (??)

This (??) new symbol is a life saver. This is a logical operator that returns RHS operator if LHS is null/undefined.
RHS/LHS - right/left hand side (duh!)

I 💗 this feature!

function add(a, b, c) {
 const valOfA = a ?? 0;
 const valOfB = b ?? 0;
 const valOfC = c ?? 0;
 return a + b + c;
}

add(null, undefined, null); // Run-time error

Option 3 - Logical Nullish assignment operator (??=)

This (??=) new symbol is another life saver. The logical nullish assignment (x ??= y) operator only assigns if x is nullish (null or undefined).

I 💗 this feature!

function printPersonDetails(person) {
   person.age ??= 0;
   console.log(person?.age); // 0 and no run-time error
}

printPersonDetails({age: undefined});

Option 4 - Destructuring and Rest defaults

This option is also pretty handy but can take some time to wrap your head around.

Before

var tmp = getSomeRecords();

var first = tmp[0];
var second = tmp[1];

var firstName = first.name;
var firstEmail = first.email !== undefined ? first.email : "nobody@none.tld";

var secondName = second.name;
var secondEmail =
  second.email !== undefined ? second.email : "nobody@none.tld";

function getSomeRecords() {
    return [
      {
        name: "a",
        email: "a@gmail.com",
      },
      {
        name: "b",
        email: "b@gmail.com",
      },
    ];
}

After

var [
  {
    name: firstName,
    email: firstEmail = "nobody@none.com"
  },
  {
    name: secondName,
    email: secondEmail = "nobody@none.com"
  }
] = getSomeRecords();

function getSomeRecords() {
  return [
    {
      name: "a"
    },
    {
      name: "b",
      email: "b@gmail.com",
    },
  ];
}

The same rest parameter concept can be applicable to function parameters as well.

Before

function printPersonDetails(person) {
   console.log(person.age);
   console.log(person.name);
}

printPersonDetails(undefined); // 💥 💥 Blast!!!

After

function printPersonDetails({
   age: age = 0,
   name: name = 'john doe'
}) {
   console.log(age);
   console.log(name);
}

printPersonDetails(undefined); // Works

// OR if you are lazy to repeat properties
function printPersonDetails({
   age = 0,
   name = 'john doe'
}) {
   console.log(age);
   console.log(name);
}

printPersonDetails(undefined); // Works

The above technique can also be useful if you have more than 3 parameters in your function and you don't like remembering the sequence of them (I don't). This feature is known as named-parameters.

Option 5 - Use Elvis(?) operator

I hate this option but I will still list it.

function printPersonDetails(person) {
   console.log(person?.age); // undefined and no run-time error
}

printPersonDetails(undefined);

But what if person is not undefined and you tried to access a property inside age but age turns out to be undefined/null?

Option 5.1 Use Elvis(?) operator AND Non-Null Assertions (TypeScript 3.9 onwards only)

function printPersonDetails(person) {
   console.log(person?.age!.unit); // undefined and no run-time error
// OR
console.log((person?.age).unit); // undefined and no run-time error
}

printPersonDetails({ age: undefined });

The (...) or ! provide the non-null assertions

These techniques are the ones that needs to be followed to avoid embarrassing production run-time errors on your console.

I have a small YouTube channel named EverydayJavaScript. Please do subscribe to the channel if you liked this post.

Happy error-free coding!

What's new in TypeScript v4.4?

Ankit Tanna — Sun, 12 Sep 2021 17:47:42 +0000

TypeScript 4.4 came out with a lot of performance update plus some improved type checking. As a developer, you may be excited about a few of the features that are listed below.

1. Control Flow Analysis of Aliased Conditions and Discriminants

Quite a bad-ass name for a feature 😄.

Its basically nothing but TypeScript becoming intelligent about the type of the variable if evaluated above.

Before

function foo(arg: unknown) {
  if (typeof arg === "string") {
    console.log(arg.toUpperCase());
}

Now

function foo(arg: unknown) {
  const argIsString = typeof arg === "string";
  if (argIsString) {
    console.log(arg.toUpperCase());
  }
}

TypeScript remembers that arg is evaluated and it's type is string. You dont need to perform the evaluation again and again.

2. Defaulting to unknown type in catch blocks

We use try-catch blocks to handle the mess that we create. But since the mess(dirty stuff needed to be done in catch block) can be generated from the different sources, the Error parameter in the catch block has to be kept loosely typed OR an implictly-any defined parameter.

Before

try {
  // Who knows what this might throw...
  executeSomeThirdPartyCode();
} catch (err) {
  // err: any
  console.error(err.message); // Allowed, because 'any'
  err.thisWillProbablyFail(); // Allowed, because 'any' :(
}

Once you enable useUnknownInCatchVariables in your TSConfig file, the Error parameter in the catch block becomes of type any. And you will start seeing below errors:

Property 'message' does not exist on type 'unknown'.
Property 'name' does not exist on type 'unknown'.
Property 'stack' does not exist on type 'unknown'.

After

try {
  // Who knows what this might throw...
  executeSomeThirdPartyCode();
} catch (err) {
  if (err instanceof Error) {
     console.error(err.message);
  }
}

If you have a CustomError, you can create a class and make them extend with Error.

3. Exact Optional Property Types

This feature needs to be enabled in your TSConfig using the flag exactOptionalPropertyTypes. In JavaScript, reading a missing property in an object returns undefined.

Currently, if you define an interface like below:

interface Person {
  name: string;
  age?: number;
}

The equivalent of the above interface was:

interface Person {
  name: string;
  age?: number | undefined;
}

which meant that an object with a property age and it's value undefined were totally fine.

const p: Person = {
  name: "Daniel",
  age: undefined, // This is okay by default.
};

but actually it is supposed to be interpreted as an object of type Person must contain name and another property age is optional but if it is present, age must be of type number.

With the exactOptionalPropertyTypes flag on, you can get be rest assured that if optional properties are a part of your object, they are assigned a correct type value.

PS - such things are good for type-geek devs like me! and you must enable it as well!

4. static blocks in classes

Static blocks in classes are a new feature of ECMAScript features that can help you write complex initialization logic for static members

class Foo {
    static count = 0;

    // This is a static block:
    static {
        if (someCondition()) {
            Foo.count++;
        }
    }
}

Think of them as constructor for static properties 😄.

5. Inlay hints

This is kind of a good feature when you have a lengthy list of parameters in a function and you have a tough time remembering the sequence of it. Inlay hints display useful information like parameter names and return types in your code. You can think of it as a sort of friendly “ghost text”.

6. No initializers for Abstract properties

Abstract properties cannot have initializers.

abstract class C {
  abstract prop = 1;
  //       ~~~~
  // Property 'prop' cannot have an initializer because it is marked abstract.
}

7. Performance improvements and other goodies

There have been many behind the scenes improvement like below:

Faster declaration emits (symbols of classes that are accessible)
Faster path normalization (basically translating ../../ --> to a proper path)
Faster incremental builds if --strict flag is on. This will certainly give you nightmares in your initial days and if your project is big, it will take some amount of time to clear up this mess!
Faster source map generation (Do leave in the comments, do we need source maps now?)
Better spelling suggestions
Auto-imports showing true/complete path

I hope you enjoyed this brief read about TypeScript and it's new features. If you are geeky and are not able to sleep, you can go and read the TypeScript Release Notes.

I run a small YouTube channel named EverydayJavaScript. Please do subscribe to it if you haven't fallen asleep reading the release notes!

Happy TypeScript-ing!

TypeScript - Build Types from Interfaces

Ankit Tanna — Fri, 10 Sep 2021 05:51:09 +0000

We definitely need to be more vigilant when creating interfaces and types in TypeScript. If we define loosely typed interface then it is no different from any.

for example:

interface Folder {
   id?: string;
   name: string;
   description: string;
   isMarkedFavorite?: boolean;
}

With the above interface, we can create 4 different interfaces:

name, description
name, description, id
name, description, isMarkedFavorite
name, description, id, isMarkedFavorite

These kind of scenarios often come when we use an interface for Payload and Response of an API. For example:

Create folder would need only 2 properties: name and description
Once the folder is created, you would get id of the folder and also user's preferences like if the user has marked the folder as favorite or not

Typically for Payload and Response, the developer would typically use the same interface. Instead, we can use TypeScript's Pick and Omit utils to create new interfaces.

interface BaseFolder {
   id: string;
   name: string;
   description: string;
   isMarkedFavorite: boolean;
}

type FolderPayloadV1 = Omit<BaseFolder, "id" | "isMarkedFavorite">;
type FolderPayloadV2 = Pick<BaseFolder, "name" | "description">;

You can also use Partial to make all the properties of BaseFolder optional.

interface BaseFolder {
   id: string;
   name: string;
   description: string;
   isMarkedFavorite: boolean;
}

type FolderPayloadV3 = Partial<BaseFolder>

// Equivalent would be
{
   id?: string;
   name?: string;
   description?: string;
   isMarkedFavorite?: boolean;
}

As a developer, if we put enough time in designing interfaces then it shapes our development pattern as well. Type in TypeScript allows us to mitigate development bugs in many unseen ways. Like if the developers knew that the API is expected to return 4 properties and out of the for properties one of the property is expected to come from another API source, hence the developer can avoid unwanted bugs.

Happy Coding!

I run a small YouTube channel named EverydayJavaScript. My target is to reach 10000 subscribers by end of year. Please subscribe my channel.
Subscribe: https://www.youtube.com/EverydayJavaScript

How to create a type for complex JSON object in TypeScript?

Ankit Tanna — Tue, 07 Sep 2021 10:00:15 +0000

Imagine having to deal with a complex JSON object and still having TypeScript typecheck in place. The complex objects cause us to use any in the code in order to navigate around the Typecheck of TypeScript.

Sometimes, we may also have to turn off the linter rules in order to make this work.

// eslint-disable-next-line @typescript-eslint/no-explicit-any

private modifyRecord(record: any) {...}

We can define our custom types like below:

type JSONValue =
    | string
    | number
    | boolean
    | JSONObject
    | JSONArray;

interface JSONObject {
    [x: string]: JSONValue;
}

interface JSONArray extends Array<JSONValue> { }

These kind of type is known as Recursive Type Aliases. After TypeScript 3.7 we can also define it in a confined way:

type JSONValue =
    | string
    | number
    | boolean
    | { [x: string]: JSONValue }
    | Array<JSONValue>;

JSONValue circularly references itself.

Happy coding!

PS: Don't use any in the TypeScript.

JavaScript: Quiz Time

Ankit Tanna — Sun, 14 Jun 2020 15:05:26 +0000

Question 1

Question 2

Question 3

Question 4

Question 5

Question 6

Question 7

Question 8

Question 9

Question 10

Question 11

Question 12

Question 13

Question 14
![Alt text of image]((https://dev-to-uploads.s3.amazonaws.com/i/la309bxrgszppqit00qc.jpeg)

Question 15

Question 16

Question 17

Question 18

Question 19

Question 20

Question 21

Question 22

Question 23

Question 24

Question 25

Question 26

Question 27

Question 28

Question 29

Question 30

Question 31

Question 32

Question 33

Question 34

Question 35

Use below template for your answers (if possible, add description). Paste your answers in the comments section:
Answer 1:
Answer 2:
Answer 3:
Answer 4:
Answer 5:
Answer 6:
Answer 7:
Answer 8:
Answer 9:
Answer 10:
Answer 11:
Answer 12:
Answer 13:
Answer 14:
Answer 15:
Answer 16:
Answer 17:
Answer 18:
Answer 19:
Answer 20:
Answer 21:
Answer 22:
Answer 23:
Answer 24:
Answer 25:
Answer 26:
Answer 27:
Answer 28:
Answer 29:
Answer 30:
Answer 31:
Answer 32:
Answer 33:
Answer 34:
Answer 35:

This quiz is brought to you by EverydayJavaScript. Do check out the channel on YouTube

CSS3: Pseudo-Elements

Ankit Tanna — Sun, 14 Jun 2020 14:32:47 +0000

What is CSS Pseudo-Elements?
Are Pseudo-Elements and Pseudo-Classes the same?

We as UI developers tend to confuse between Pseudo-Elements (::) and Pseudo-Classes (:).

Pseudo-elements represent physical element which is not visible in your DOM where as Pseudo-classes represent a state of an HTML element. Both of these features of CSS3 help us write clean HTML code and ultimately simplified DOM.

Check out this small 10 minutes tutorial to know more about CSS3 Pseudo-Elements.

I am a content creator at EverydayJavaScript. You can checkout the growing YouTube channel and provide your feedback.

Async Await Keywords in JavaScript - Make Asynchronous Code Look Synchronous

Ankit Tanna — Fri, 02 Aug 2019 04:01:42 +0000

What is Anync Await Keyword?
In JavaScript, we have used promises and the code of promise looks like an asynchronous code.

We can make asynchronous code look like a synchronous code by using async await keywords.

Definition:
Inside a function marked as async, you are allowed to place the await keyword in front of an expression that returns a promise. When you place await keyword, the execution of async function is paused until the promise is resolved/rejected.

Have a look at this tutorial which shows how to transform an asynchronous fetch api call to a synchronous looking(yet asynchronous) code.

It will also show you the difference between Promises and Async/Await and which one's better.

JavaScript: 3 key differences between Arrow Functions and Normal Functions

Ankit Tanna — Tue, 30 Jul 2019 10:23:30 +0000

Hello Everyone,

This is my first post and I wish to write something about "Arrow Functions". I wanted to show the difference between The Arrow Functions and The Normal Functions!

Often, when asked during a client interview or a job interview, people tend to give maximum ONE difference. But in actual, there are 3 Major differences:

"this" - Arrow Functions do not have their own context
"arguments" - Unable to access "arguments" inside function to know what arguments are passed to the function
"Class" - Cannot used Arrow Functions as a class as arrow functions do not have a constructor/don't behave like a constructor

If you want to see the hands-on on this, have a look at this short video:

Please leave your feedback on what do you think. Thank you.