Forem: Bhaveek Jain

const a = [ ] is not an array?! 😱

Bhaveek Jain — Sat, 24 Dec 2022 15:55:14 +0000

Introduction

As I delved into Primeagen's Algorithms course on Frontend Masters, I was struck by a revelation: the familiar const a = [ ] syntax we use to declare an array in JavaScript is not, in fact, an array in the traditional sense. This discovery came as a surprise to me, and I felt a desire to share this newfound knowledge with others through this blog.

What is an Array?

An array is an ordered collection of values. Each value is called an element, and each element has a numeric position in the array, known as its index. JavaScript arrays are untyped: an array element may be of any type, and different elements of the same array may be of different types. Array elements may even be objects or other arrays, which allows you to create complex data structures, such as arrays of objects and arrays of arrays. JavaScript arrays may be sparse: the elements need not have contiguous indexes, and there may be gaps. Every JavaScript array has a length property. For nonsparse arrays, this property specifies the number of elements in the array. For sparse arrays, length is larger than the highest index of any element. JavaScript arrays are a specialized form of JavaScript object, and array indexes are really little more than property names that happen to be integers. JavaScript arrays are dynamic: they grow or shrink as needed, and there is no need to declare a fixed size for the array when you create it or to reallocate it when the size changes.

The Proof!

Let's write some code for the empirical test and find out under the hood, what type of data structure is const a = [ ]

P.S: I'll be using TypeScript for this proof so I have type safety.

You can find the code in the github repo for reference or you can copy it from below and work it out on your own machine

const a: number[] = [];

function time(fn: () => void): number {
    const now = Date.now();
    fn();
    return Date.now() - now;
}

function unshift(number: number) {
    for (let i = 0; i < number; ++i) {
        a.unshift(Math.random());
    }
}

function shift(number: number) {
    for (let i = 0; i < number; ++i) {
        a.shift();
    }
}

function push(number: number) {
    for (let i = 0; i < number; ++i) {
        a.push(Math.random());
    }
}

function pop(number: number) {
    for (let i = 0; i < number; ++i) {
        a.pop();
    }
}

function get(idx: number) {
    return function() {
        return a[idx];
    };
}

function push_arr(count: number) {
    return function() {
        push(count);
    };
}

function pop_arr(count: number) {
    return function() {
        pop(count);
    };
}

function unshift_arr(count: number) {
    return function() {
        unshift(count);
    };
}

function shift_arr(count: number) {
    return function() {
        shift(count);
    };
}

Let's summarize:

Create an array
function time: to measure the time of function

We just want a gauge of how fast or slow things are.
function unshift : it will unshift " a " a certain amount of times

unshift in javascript means adding to a list
function shift will shift "a" a certain number of times

shift is used for removing from the beginning of the list
function push will push "a" a certain number amount of time.

push method is used to add one or more elements to the end of an array
function pop will pop "a" a certain number of times.

pop method is used to remove the last element from an array and returns that element.
function get based on index. Just in case it is a LinkedList under the hood, if we were to get progressively larger indices, we should see a linear slowdown.
functions push_arr, pop_arr, shift_arr, unshift_arr are higher-order functions that will call push, pop, shift and unshift functions repeatedly.
then comes the tests ...

Tests

Now we will test our functions and try to figure out what the results indicate

Pro-tip: Whenever we are doing a performance test, you should use a step ladder-type approach that way you can see how it grows so you can run a linear regression.

const tests = [10, 100, 1000, 10000, 100000, 1_000_000, 10_000_000];
console.log("Testing get");
tests.forEach(t => {
    a.length = 0;
    push(t);
    console.log(t, time(get(t - 1)));
});

console.log("push");
tests.forEach(t => {
    a.length = 0;
    push(t);

    console.log(t, time(push_arr(1000)));
});

console.log("pop");
tests.forEach(t => {
    a.length = 0;
    push(t);

    console.log(t, time(pop_arr(1000)));
});

console.log("unshift");
tests.forEach(t => {
    a.length = 0;
    push(t);

    console.log(t, time(unshift_arr(1000)));
});

console.log("shift");
tests.forEach(t => {
    a.length = 0;
    push(t);

    console.log(t, time(shift_arr(1000)));
});

Let's summarize:

We are gonna test with 10, 100, 100 .... 10000000 elements.
In first test, "Testing get", we are going to push in the value and do a get for the last element

The thesis here is, if indexing is linear, we should see a slowdown as the array gets bigger
In the second test, "push", we are going to push a thousand items after growing to a certain length t.

If push is based on the number of items within the array, we should theoretically see a slowdown that happens. So it should be linearly getting slower at every single step.
The same thesis is for "pop", "shift" and "unshift" tests.

Results

Its time to run our code and check how the results pan out and in what direction are we going when we talk about arrays in javascript

As this is TypeScript, run npx ts-node {file-name}.ts

Testing Get

Doesn't matter the size of the array. It's super duper fast.

Testing push

Same case as get, it's quite fast.

Testing pop

Similar results as get and push, it's quite fast.

Testing unshift and shift

Here we observe that the test cases get horribly slow and is having a linear growth.

So what do we infer from these results:

Instant access
Instant pushing and popping at the end
Linear shifting and un-shfting

Hence it's an ArrayList

An array list is a data structure that is similar to an array, but it has a dynamic size and allows you to add and remove elements more efficiently. Array lists are commonly used in programming languages to store and manipulate a collection of items.

Conclusion

We can safely conclude that Javascript arrays are dynamic and it's actually ArrayLists under the hood.

Credits

ThePrimeAgen

Thank you for reading this blog. I hope that you have found this information helpful and if you liked it, consider sharing it with others also.

Bye!

Top 5 mistakes to avoid when using React with Typescript

Bhaveek Jain — Wed, 21 Dec 2022 18:43:18 +0000

Introduction

Are you looking for a comprehensive introduction to using React with TypeScript? Look no further! In this blog, we'll delve into the top 5 mistakes to avoid when combining these powerful tools. As a JavaScript library, React allows developers to build reusable UI components and create efficient, dynamic user interfaces. When paired with TypeScript, a typed superset of JavaScript, developers can take advantage of enhanced type checking and improved code reliability. However, it's important to be mindful of potential pitfalls and mistakes that can arise during the development process. By following best practices and avoiding common errors, you can ensure a smooth and successful experience when using React with TypeScript. In this blog, we'll follow practical tips and helpful examples to guide you on your journey.

1. Using Type "any"

Typescript allows you to assign types to variables. Usually, it's done in this way

let someNumber: number;

lets do some operations

let someNumber: number;
someNumber = 10; // ✅ All good
someNumber = "ten"; // ❌ Error
// Type 'string' is not assignable to type 'number'/. (2322)

Here when we assign our variable a number, it worked fine but gave an error when provided it with a string.

We can roughly describe types as a collection of possible things that are similar in some way. For example, type number contains numbers from 0.5,2,3 ... 1000 ... 122123 etc. You get the point that they are somewhat similar and have a specific behaviour like addition, subtraction etc. But there are also some operations that are not available for certain types, say for number in our case, we can't really get a member of a number or 2[3]

So if we write this in typescript

const someNumber: number = 10
const tuff = someNumber[3]

we'll receive this error

Let's modify our example a bit and see what impact it makes

const someNumber: any = 10
const tuff = someNumber[3]

Suddenly, the errors are gone!

Welcome to "any" land!
The biggest problem with any is that it's positive/permissive. It's similar to something if I say: "I drink something." You would assume I'm drinking something drinkable like lemonade or water. You wouldn't expect me drinking acid or petrol, in which case I'd need immediate medical attention(lol)

Using the any type can make your code less reliable and more prone to runtime errors, because the compiler is not able to catch type-related issues. It can also make your code less readable and maintainable, because it's not clear to other developers what the type of a value is.

Instead of using the any type, it's generally best to use explicit type annotations or type declarations to specify the types of values in your code. This will help ensure that your code is correctly typed and can be more easily understood by others.

2. Using Type Assertions

Type assertions, also known as type casting, are a way to override the type of a value in TypeScript. While they can be useful in certain situations, it's generally recommended to avoid using type assertions in your code. This is because type assertions can mask type-related issues and hinder the effectiveness of the TypeScript compiler.

For example, if you use a type assertion to tell the compiler that a value has a certain type, the compiler will trust your assertion and will not perform any further type checking on that value. This means that if there is a type mismatch or error in your code, it may not be caught by the compiler and could lead to runtime errors.

Additionally, type assertions can make your code less readable and maintainable. They can obscure the actual type of a value and make it more difficult for other developers to understand your code.

In general, it's best to let the TypeScript compiler do its job and catch type-related issues as early as possible in the development process. Instead of using type assertions, you can use type annotations or type declarations to explicitly specify the types of variables and values in your code. This will help ensure that your code is correctly typed and can be more easily understood by others.

For example,

let someValue: any = 'this is a string';

let strLength: number = (someValue as string).length;

we have a variable someValue with the type any, which means it can hold any value. We then use a type assertion to tell the compiler that someValue is a string, and we access the length property of the string.

However, as mentioned earlier, it's generally recommended to avoid using type assertions like this. Instead, we could have explicitly declared the type of someValue as a string, like this:

let someValue: string = 'this is a string';

let strLength: number = someValue.length;

This approach is more type-safe and makes it clearer to other developers what the type of someValue is. It also allows the TypeScript compiler to catch any type-related issues that may arise.

3. Using @ts-ignore

The @ts-ignore directive is a way to tell the TypeScript compiler to ignore a specific piece of code. It can be used to suppress type-related errors or warnings that the compiler generates.

We declare @ts-node as a comment on the line we want to ignore to type check

if(false) {
// @ts-ignore // Unreachable code block
  console.log("Hello ts-ignore")
}

It's a good practise to provide a reason for why we are ignoring this.

After we discussed how important it is to not use type any and not use type assertions too much, it might be surprising that such option even exist.
It can be useful:

In tests, when you want to verify that invalid inputs will be handled correctly
When you are migrating to newer version of typescript
When you are migrating javascript code base to typescript

While @ts-ignore can be useful in certain situations, it's generally not recommended to use it excessively in your code. This is because @ts-ignore can mask type-related issues and hinder the effectiveness of the TypeScript compiler.

For example, if you use @ts-ignore to suppress a type error, the compiler will not report the error and the issue will not be addressed. This can lead to runtime errors or unexpected behavior in your code.

Additionally, using @ts-ignore can make your code less maintainable and harder to understand, because it's not clear why the compiler is being told to ignore a certain piece of code.

It's generally best to let the TypeScript compiler do its job and catch type-related issues as early as possible in the development process. Instead of using @ts-ignore, you can try to fix the underlying issue or use explicit type annotations or type declarations to specify the types of values in your code. This will help ensure that your code is correctly typed and can be more easily understood by others.

4. Using numeric enums

An enum (short for "enumeration") is a way to define a set of named constants. Enums can be either numeric or string-based.

Numeric enums are enums in which the values are numeric. In a numeric enum, the values are automatically assigned incrementing numbers starting from 0.

Here is an example of a numeric enum in TypeScript:

enum Days {
  Monday,
  Tuesday,
  Wednesday,
  Thursday,
  Friday,
  Saturday,
  Sunday
}
In this example, the enum `Days` has seven values: `Monday`, `Tuesday`, `Wednesday`, `Thursday`, `Friday`, `Saturday`, and `Sunday`. These values are automatically assigned the numbers 0 through 6, respectively.

While numeric enums can be useful in certain situations, it's generally recommended to avoid using them in your TypeScript code. This is because numeric enums can be prone to errors and can make your code less readable and maintainable.

One issue with numeric enums is that they can lead to runtime errors if you are not careful. For example, consider the following code:

enum Days {
  Monday,
  Tuesday,
  Wednesday,
  Thursday,
  Friday,
  Saturday,
  Sunday
}

let day = Days.Monday;

if (day === Days.Sunday) {
  console.log('Today is Sunday');
} else {
  console.log('Today is not Sunday');
}

In this example, we have an enum Days with seven values representing the days of the week. We then assign the value Days.Monday to the variable day.

However, because we are using a numeric enum, the values of the enum are automatically assigned incrementing numbers starting from 0. This means that the value of Days.Monday is actually 0, and the value of Days.Sunday is 6.

As a result, the condition in the if statement will evaluate to false, and the message "Today is not Sunday" will be logged to the console. This can be confusing and lead to unexpected behavior in your code.

Another issue with numeric enums is that they can make your code less readable and maintainable. It's often not immediately clear what a numeric value represents in an enum, and it can be easy to mix up the values or use them incorrectly.

For these reasons, it's generally recommended to use string-based enums instead of numeric enums in your TypeScript code. String-based enums provide better type safety and are easier to understand, which can make your code more reliable and maintainable.

5. Marking fields optional

In TypeScript, you can use the ? symbol to mark a field or parameter as optional. This means that the field or parameter is not required and does not need to be provided when the code is called.

While marking fields or parameters as optional can be useful in certain situations, it's generally not recommended to do so excessively. This is because optional fields and parameters can make your code less reliable and more prone to runtime errors.

For example, consider the following code:

function greet(name?: string) {
  console.log(`Hello, ${name}!`);
}

greet();

In this example, the name parameter of the greet function is marked as optional. This means that the function can be called without providing a value for name.

However, if the function is called without a value for name, the console.log statement will result in an error, because the name variable will be undefined. This can lead to unexpected behavior and runtime errors in your code.

To avoid this issue, it's generally best to make fields and parameters required by default, and only mark them as optional if there is a specific need to do so. This will help ensure that your code is more reliable and less prone to runtime errors.

Thank you for reading this blog. I hope that you have found this information helpful and that it will help you avoid common pitfalls and mistakes when working with these powerful tools.

Using React with TypeScript can greatly improve the reliability and maintainability of your code, but it's important to be aware of potential issues and mistakes that can arise. By following best practices and avoiding these common errors, you can ensure a smooth and successful development process.

If you have any further questions, comment it out and I'll try to answer in best possible way. Thanks for reading!

Let's "Git" it: Beginners guide to Git

Bhaveek Jain — Tue, 13 Dec 2022 16:08:22 +0000

Introduction

Are you new to Git and unsure of where to start? Look no further! Git is a popular version control system that allows you to track changes to your code and collaborate with others on your projects. In this blog, we will cover the basics of Git and provide a step-by-step guide on how to get started. You'll learn about the benefits of using Git, how to set up a repository, and how to commit and push changes to your code. By the end of this blog, you'll have a solid foundation in Git and be able to confidently incorporate it into your workflow. But first, let's answer this question...

Why use Git?

Git is a valuable tool for any developer, as it allows you to track changes to your code and collaborate with others on your projects. It also makes it easy to revert back to previous versions of your code if you make a mistake or want to experiment with different approaches. Additionally, Git provides a way to manage and organize your code, making it easier to keep track of your progress and share your work with others.

Installing Git

To install git, you will need to have access to a terminal or command prompt. If you are using a Mac or Linux, the terminal is already installed on your system. If you are running a Windows machine, you can download it for free from http://git-scm.com.

I'm currently using Ubuntu 22.0.4, so the steps for setting and installing git are performed according to linux but it is more or less the same steps if you own a Windows or a Mac machine.

Once you have access to a terminal or command prompt, follow these steps to install git:

Open the terminal or command prompt and type the following command:
```
sudo apt-get install git
```
This will download and install git on your system. You may be prompted to enter your password to continue.
After git has been installed, you can verify the installation by typing the following command:
```
git --version
```

Running our first Git command

So, we have Git up and running! Are you excited? Let's begin to type!

You might be daunted by the jargon used by devs while working with git like "git commit it bro", "pull it", "git merge it to the main branch" etc.

You can get an idea about these commands from git itself by typing

git --help

Setting up a new repository

The first step is to set up a new repository (or repo, for short). A repo is a container for your entire project; every file or subfolder within it belongs to that repository, consistently. Physically, a repository is nothing other than a folder that contains a special .git folder, the folder where the magic happens.

Let's try to make our first repo. Choose a folder you like, and type the git init command, as shown here:

Whoa! What just happened? Git created a .git subfolder. At this point, it is not important for us to understand what is inside this folder. The only thing you have to know is that you do not have to touch it, ever! If you delete it or if you modify files inside by hand, you could get into trouble. Have I frightened you enough?

Now that we have a repo, we can start to put files inside it. Git can trace the history of any gender of files, text-based or binary, small or large, with the same efficiency (more or less, large files are always a problem).

Adding a File

Let's create a text file just to give it a try.

And now what? Is that all? No! We have to tell Git to put this file in your repo, explicitly. Git doesn't do anything that you don't want it to. If you have some spare files or temp ones in your repo, Git will not be compatible with them, but will only remind you that there are some files in your repo that are not under version control. You can also see the color of the **master\** branch changed from green to brown, which indicates that I have some uncommitted files in my current repo. It happened because I'm ayu theme of fish shell.

fish is a smart and user-friendly command line shell for macOS, Linux, and the rest of the family. fish includes features like syntax highlighting, autosuggest-as-you-type, and fancy tab completions that just work, with no configuration required.

Ok, back to the topic. I want git.txt under the control of Git, so let's add it, as shown here:

The git add <file> command tells Git that we want it to take care of that file and check it for future modifications. Has Git obeyed us? Let's see.

Using the git status command, we can check the status of the repo, as shown

As we can see, Git has accomplished its work as expected. In this image, we can read words such as branch, master, commit and unstage. We will look at them briefly, but for the moment, let's ignore them.

"Commit"-ing the added file

At this point, Git knows about git.txt, but we have to perform another step to fix the snapshot of its content. We have to commit it using the appropriate git commit command. This time, we will add some flavor to our command, using the --message (or -m) subcommand, as shown here:

Feel the magic—a new branch is born!

With the commit of git.txt, we have finally fired up our repo. You can see the color has also changed back to green which means that our git is up to date.

Modify a committed file

Let's try to make some changes to the file and see how to deal with it.

Here, the git status command informs us that there is a file with some modifications and that we need to commit it if we want to save this modification step in the repository history.

However, what do no changes added to commit mean? It is simple. Git makes you take a second look at what you want to include in the next commit.

If you have touched two files but you want to commit only one, you can add only that one. If you try to do a commit without skipping the add step, nothing will happen.

So, let's add the file again for the purpose of getting things ready for the next commit

Let's do another commit, this time, avoiding the --message subcommand. So, type git commit and hit the Enter key.

You have entered into a piece of code history! This is Vim (Vi Improved), an ancient and powerful text editor. You can configure Git to use your own preferred editor, but if you don't do it, this is what you have to deal with. Vim is powerful, but for newcomers, it can be a pain to use. It has a strange way of dealing with text, so to start typing, you have to press i for inserting text or

After writing the commit message press Ctrl + c or Escto get out of insert mode and press :wq to save and exit Vim.

Note that when you saved the commit message in Vim, Git automatically dispatches the commit work. Also see our master branch is green again :)

Well done! Now, let's recap!

Conclusion

In this article, you learned that Git is not so difficult to install.

Once you have chosen a directory to include in a Git repository, you can see that initializing a new Git repository is as easy as executing a git init command, and nothing more. Don't worry now about saving it on a remote server and so on. It's not mandatory to save it; you can do this when you need to, preserving the entire history of your repo. This is a killer feature of Git and DVCS in general. You can comfortably work offline and push your work to a remote location when the network is available, without hassle.

In the end, we discovered one of the most important character traits of Git: it will do nothing if you don't mention it explicitly. You also learned a little bit about the add command. We were obliged to perform a git add command for a file when we committed it to Git the very first time. Then, we used another command when we modified it. This is because if you modify a file, Git does not expect that you want it to be automatically added to the next commit.

If you liked this blog, consider following me here and on other social media platforms.

Github, Twitter, Linkedin

Bye!