Still using var ?
Ohh, Come on. You are still doing it? We are in the most formative years that the JS world is experiencing. With frameworks like React, Angular ruling the market, you are using something that was outdated 6 years back. Unless you are working on something very old, there is no excuse for this situation.
For a quick recap, let's see what var is and how let and const are helping us in a better way.
When you declare a var keyword its scope is not limited to the block it is inside. It is accessible anywhere outside the block as well. It is a function scoped keyword. You must have understood the situation where we can have problems. If not, here is an example.
var illustrated
Now in the situation, we will be getting no error, but instead, our value will be overridden. That might not be the situation that we desire. We would want to have an error regarding the same. We won't have such a situation with let and const. A Syntax Error will be thrown by the JS Engine.
Using un-descriptive names
It is fine to use const a = “value” when you are learning JS. But using such practices would pain for you and other fellow developers when you will be working on any project. Trust me on this. We at Groww, teach this as the very first training project. Let's say you have written the following code.
Contrary to the code above, we have a better one below.
It's clear what our variables mean. Hence, use descriptive variable names.
Using ‘==’ instead of ‘===’
If JavaScript is lenient on typecasting, it does mean we will misuse it.
For those who know the difference between undefined and null, the above situation might be magic. And as a matter of fact, the less magic you have in your code, the better it is.
‘==’ just compares the values keeping their types aside. This scenario can temporarily avoid errors but your code can perform worst if something unexpected is compared. Hence to be on the safe side always use ‘===’. It is kind of a strict comparison that compares values as well as their types. Our favorable result for the above statements is:-
Lacking knowledge of DRY principle in Coding
It's not something that is related to JavaScript itself. Just a standard Coding practice that you should follow in any language while programming. The DRY principle means Don't Repeat Yourself. I guess it is self-explanatory. We should try our best to write Clean Code in a minimum number of Words. A simple example is:-
Seems much better right? It works in a much better way as well. This is just an example. Try to figure out such instances in your code and find an innovative solution for that.
Not handling errors in API calls
If you are working on medium or large-scale projects, chances are you will be working with APIs. Whether you use Fetch, Axios, or even XHR, there are always chances of API failure due to any reason. That can be not authorized, not found, or a general server error.
Not just newbies, even some experienced fellows forget to consider these situations, which is not so good for User Experience. Handling Errors makes your app, less prone to unwanted situations or pages.
Not understanding Arrow vs Normal functions
I know most of you are aware of Arrow functions. But is your knowledge just limited to the fact they are syntactic sugar for normal functions? If that is the case, you are missing many things, my friend. There are some very significant differences between them which if ignored can lead to trouble.
Arrow functions don’t have their own context. This is especially important if they’re defined inside another function. For example, as a callback for a forEach execution. If inside the arrow function you use the keyword this you’re referencing the context of the parent function. This is a big difference because, before arrow functions, you’d have to save a reference to this before calling the callback function, and within the callback use the new reference, otherwise the this inside it would be a completely new context.
Arrow functions are not valid constructors. Believe it or not, regular functions are “constructible”. Meaning they can be called with the new keyword and return a new instance of that function. Why is this possible? Because back then, before ES6, we also had prototypal inheritance as our main way of working with objects, and functions (regular functions) were the constructor for them. However, now with classes, that is no longer the “way to go”, and arrow functions reflect that change in direction. Arrow functions while callable (just like regular ones) are not constructible, so you can’t really put a new before calling them, it won’t work.
They don't allow Duplicate Argument Names. This is acceptable for regular functions in a non-strict mode. However, this can’t happen with arrow functions, regardless of how strict you want to be.
Using Old Tricks
As we are building more and more complex use cases with JavaScript. This makes us as developers use tricks to keep our code working sometimes. A classic example is searching whether an array contains an item. I’ve never liked to use array.indexOf(item) !== -1 to check the presence of an item.
This would work fine but is not so good way to do the same. We should be updated with the latest ES6 and newer standards. They bring new features to solve our problems efficiently. For example, in the above situation, we can use the new ES6 Method array.includes(item). It's just one example. There can be countless others.
#viastudy
.gif)
0 Comments