DEV Community: Umashankar S

Common Beginners JavaScript Mistakes - 2.0

Umashankar S — Thu, 06 Oct 2022 21:02:54 +0000

1. Incorrect References to this

There’s no shortage of confusion among JavaScript developers regarding JavaScript’s this keyword.

As JavaScript coding techniques and design patterns have become increasingly sophisticated over the years, there’s been a corresponding increase in the proliferation of self-referencing scopes within callbacks and closures, which are a fairly common source of “this/that confusion” causing JavaScript issues.

Consider this example code snippet:

function getInformation() {
  setTimeout(function() {
    console.log(this.names); //undefined
    this.reset();            //type error reset is not a function
  }, 1000);
}

const obj1 = {
  names: 'Uma',
  reset: function() {
    console.log("reset")
  }
}

const data = getInformation.bind(obj1);
data();

Why? It’s all about context. The reason you get the above error is because, when you invoke setTimeout(), you are actually invoking window.setTimeout(). As a result, the anonymous function being passed to setTimeout() is being defined in the context of the window object, which has no reset() method.

A traditional, old-browser-compliant solution is to simply save your reference to this in a variable that can then be inherited by the closure; e.g.:

function getInformation() {
  var self = this;
  setTimeout(function() {
    console.log(self.names);
    self.reset();
  }, 1000)
}

const obj1 = {
  names: 'Uma',
  reset: function() {
    console.log("reset")
  }
}

const data = getInformation.bind(obj1);
data();

Alternatively, in newer browsers, you can use the bind() method to pass in the proper reference:

function getInformation() {
  setTimeout(this.reset.bind(this), 1000);
}

const obj1 = {
  names: 'Uma',
  reset: function() {
    console.log("reset")
  }
}

const data = getInformation.bind(obj1);
data();

2. Thinking There Is Block-level Scope

Consider, for example, the following code:

for (var i = 0; i < 10; i++) {
    /* ... */
}
console.log(i);  // What will this output?

If you guess that the console.log() call would either output undefined or throw an error, you guessed incorrectly. Believe it or not, it will output 10. Why?

In most other languages, the code above would lead to an error because the “life” (i.e., scope) of the variable i would be restricted to the for block. In JavaScript, though, this is not the case and the variable i remains in scope even after the for loop has completed, retaining its last value after exiting the loop. (This behavior is known, incidentally, as variable hoisting.)

Support for block-level scopes in JavaScript is available via the let keyword. The let keyword has been widely supported by browsers and back-end JavaScript engines like Node.js for years now..

If that’s news to you, it’s worth taking the time to read up on scopes, prototypes, and more.

3. Creating Memory Leaks

Now, consider this code (No Memory Leak):

var theThing = null;
var replaceThing = function () {
  var originalThing = theThing;
  theThing = {
    longStr: new Array(1000000).join('*')
  };
};
setInterval(replaceThing, 1000);

var originalThing = theThing (Referencing);
But everytime replaceThing() function finish the execution, JS Engine is clever enough to clear the memory. beacuse, we are not using that reference anywhere inside the closure functions.

Now, consider this code (Memory Leak):

var theThing = null;
var replaceThing = function () {
  var originalThing = theThing;
  var unused = function () {
    if (originalThing)
      console.log("hi");
  };
  theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log(someMessage);
    }
  };
};
setInterval(replaceThing, 1000);

Please Refer this article for more detail

4. Confusion About Equality
One of the conveniences in JavaScript is that it will automatically coerce any value being referenced in a boolean context to a boolean value. But there are cases where this can be as confusing as it is convenient. Some of the following, for example, have been known to be troublesome for many a JavaScript developer:

// All of these evaluate to 'true'!
console.log(false == '0');
console.log(null == undefined);
console.log(" \t\r\n" == 0);
console.log('' == 0);

// And these do too!
if ({}) // ...
if ([]) // ...

With regard to the last two, despite being empty (which might lead one to believe that they would evaluate to false), both {} and [] are in fact objects and any object will be coerced to a boolean value of true in JavaScript, consistent with the ECMA-262 specification.

As these examples demonstrate, the rules of type coercion can sometimes be clear as mud. Accordingly, unless type coercion is explicitly desired, it’s typically best to use === and !== (rather than == and !=), so as to avoid any unintended side effects of type coercion. (== and != automatically perform type conversion when comparing two things, whereas === and !== do the same comparison without type conversion.)

And completely as a sidepoint—but since we’re talking about type coercion and comparisons—it’s worth mentioning that comparing NaN with anything (even NaN!) will always return false. You therefore cannot use the equality operators (==, ===, !=, !==) to determine whether a value is NaN or not. Instead, use the built-in global isNaN() function:

console.log(NaN == NaN);    // False
console.log(NaN === NaN);   // False
console.log(isNaN(NaN));    // True

5. Incorrect Use of Function Definitions Inside for Loops

var elements = document.getElementsByTagName('input');
var n = elements.length;    // Assume we have 10 elements for this example
for (var i = 0; i < n; i++) {
    elements[i].onclick = function() {
        console.log("This is element #" + i);
    };
}

Based on the above code, if there were 10 input elements, clicking any of them would display “This is element #10”! This is because, by the time onclick is invoked for any of the elements, the above for loop will have completed and the value of i will already be 10 (for all of them).

Here’s how we can correct the aforementioned problems with JavaScript to achieve the desired behavior:

var elements = document.getElementsByTagName('input');
var n = elements.length;    // Assume we have 10 elements for this example
var makeHandler = function(num) {  // Outer function
     return function() {   // Inner function
         console.log("This is element #" + num);
     };
};
for (var i = 0; i < n; i++) {
    elements[i].onclick = makeHandler(i+1);
}

In this revised version of the code, makeHandler is immediately executed each time we pass through the loop, each time receiving the then-current value of i+1 and binding it to a scoped num variable. The outer function returns the inner function (which also uses this scoped num variable) and the element’s onclick is set to that inner function. This ensures that each onclick receives and uses the proper i value (via the scoped num variable).

6. Failure to Properly Leverage Prototypal Inheritance
A surprisingly high percentage of JavaScript developers fail to fully understand, and therefore to fully leverage, the features of prototypal inheritance.

Here’s a simple example. Consider this code:

BaseObject = function(name) {
    if (typeof name !== "undefined") {
        this.name = name;
    } else {
        this.name = 'default'
    }
};

Seems fairly straightforward. If you provide a name, use it, otherwise set the name to ‘default’. For instance:

var firstObj = new BaseObject();
var secondObj = new BaseObject('unique');

console.log(firstObj.name);  // -> Results in 'default'
console.log(secondObj.name); // -> Results in 'unique'

But what if we were to do this:

delete secondObj.name;
console.log(secondObj.name); // -> Results in 'undefined'

But wouldn’t it be nicer for this to revert to ‘default’? This can easily be done, if we modify the original code to leverage prototypal inheritance, as follows:

BaseObject = function (name) {
    if(typeof name !== "undefined") {
        this.name = name;
    }
};

BaseObject.prototype.name = 'default';

With this version, BaseObject inherits the name property from its prototype object, where it is set (by default) to 'default'. Thus, if the constructor is called without a name, the name will default to default. And similarly, if the name property is removed from an instance of BaseObject, the prototype chain will then be searched and the name property will be retrieved from the prototype object where its value is still 'default'. So now we get:

var thirdObj = new BaseObject('unique');
console.log(thirdObj.name);  // -> Results in 'unique'

delete thirdObj.name;
console.log(thirdObj.name);  // -> Results in 'default'

7. Creating Incorrect References to Instance Methods
Let’s define a simple object, and create an instance of it, as follows:

var MyObject = function() {}

MyObject.prototype.whoAmI = function() {
    console.log(this === window ? "window" : "MyObj");
};

var obj = new MyObject();

Now, for convenience, let’s create a reference to the whoAmI method, presumably so we can access it merely by whoAmI() rather than the longer obj.whoAmI():

var whoAmI = obj.whoAmI;

And just to be sure everything looks copacetic, let’s print out the value of our new whoAmI variable:

console.log(whoAmI);

Outputs:

function () {
    console.log(this === window ? "window" : "MyObj");
}

Okay, cool. Looks fine.

But now, look at the difference when we invoke obj.whoAmI() vs. our convenience reference whoAmI():

obj.whoAmI();  // Outputs "MyObj" (as expected)
whoAmI();      // Outputs "window" (uh-oh!)

What went wrong? When we did the assignment var whoAmI = obj.whoAmI;, the new variable whoAmI was being defined in the global namespace. As a result, its value of this is window, not the obj instance of MyObject!

Thus, if we really need to create a reference to an existing method of an object, we need to be sure to do it within that object’s namespace, to preserve the value of this. One way of doing this would be as follows:

var MyObject = function() {}

MyObject.prototype.whoAmI = function() {
    console.log(this === window ? "window" : "MyObj");
};

var obj = new MyObject();
obj.w = obj.whoAmI;   // Still in the obj namespace

obj.whoAmI();  // Outputs "MyObj" (as expected)
obj.w();       // Outputs "MyObj" (as expected)

8. Failure to Use “Strict Mode”
“strict mode” (i.e., including 'use strict'; at the beginning of your JavaScript source files) is a way to voluntarily enforce stricter parsing and error handling on your JavaScript code at runtime, as well as making it more secure.

While, admittedly, failing to use strict mode is not a “mistake” per se, its use is increasingly being encouraged and its omission is increasingly becoming considered bad form.

Here are some key benefits of strict mode:

1. Makes debugging easier: Code errors that would otherwise have been ignored or would have failed silently will now generate errors or throw exceptions, alerting you sooner to problems with JavaScript in your codebase and directing you more quickly to their source.

2. Prevents accidental globals: Without strict mode, assigning a value to an undeclared variable automatically creates a global variable with that name. This is one of the most common JavaScript errors. In strict mode, attempting to do so throws an error.

3. Eliminates this coercion: Without strict mode, a reference to a this value of null or undefined is automatically coerced to the global. This can cause many frustrating bugs. In strict mode, referencing a this value of null or undefined throws an error.

4. Disallows duplicate property names or parameter values: Strict mode throws an error when it detects a duplicate named property in an object (e.g., var object = {foo: "bar", foo: "baz"};) or a duplicate named argument for a function (e.g., function foo(val1, val2, val1){}), thereby catching what is almost certainly a bug in your code that you might otherwise have wasted lots of time tracking down.

5. Makes eval() safe: There are some differences in the way eval() behaves in strict mode and in nonstrict mode. Most significantly, in strict mode, variables and functions declared inside an eval() statement are not created in the containing scope. (They are created in the containing scope in nonstrict mode, which can also be a common source of problems with JavaScript.)

6. Throws error on invalid use of delete: The delete operator (used to remove properties from objects) cannot be used on nonconfigurable properties of the object. Nonstrict code will fail silently when an attempt is made to delete a nonconfigurable property, whereas strict mode will throw an error in such a case.

Common Beginners JavaScript Mistakes

Umashankar S — Thu, 06 Oct 2022 15:50:05 +0000

Hi,
I'm not a pro candidates to identify the errors of others. this is just a common mistakes, personally i did it , when i was a intern!!

1. Not Returning From a Function

If you’ve ever called a function and gotten a response of undefined, you’ve probably already seen this mistake. Functions in JavaScript return a value of undefined by default, which means if you don’t explicitly return anything with the return keyword, undefined will be the result.

So instead of this.

const getAddedValue = (a, b) => {
  a + b;
};

Make sure you actually return the result.

const getAddedValue = (a, b) => {
  return a + b;
};

Or By default arrow function will return value, if we use this syntax

const getAddedValue = (a, b) => a + b;

2. Loading JavaScript Scripts in HTML Before the DOM Is Loaded

This is the only example that is going to touch a bit on how JavaScript interacts with HTML and the DOM. The key in how they interact is that the timing is important. If you want to reference a DOM element in your JavaScript, that DOM element must have already been loaded on the page. Let’s look at an example.

Let’s say you have a bit of HTML that also imports a JavaScript file called script.js. Notice the JavaScript file is imported before the h1 element with the id of header.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>JavaScript Mistake Demo</title>
  </head>
  <body>
    <script src="script.js"></script>
    <h1 id="header">Hello world</h1>
  </body>
</html>

Then, in your JavaScript, you want to get a reference to the header element and update its text.

const header = document.getElementById('header');
header.innerText = "James is cool!";

In this case, you’re going to get an error: Cannot set properties of null (setting 'innerText'). This is because the JavaScript is trying to get a reference to a DOM element that has not been loaded on the page yet.

To fix this, it’s common to import your JavaScript at the bottom of your HTML, after all of the HTML elements have been loaded.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>JavaScript Mistake Demo</title>
  </head>
  <body>
    <h1 id="header">Hello world</h1>
    <script src="script.js"></script>
  </body>
</html>

This way, the JavaScript file is being loaded after the header element has already been loaded.

It’s important to note that there are also other options to explore in terms of importing your JavaScript files in your HTML.
Asyc and Defer.

3. Reassigning Const Variables

This is such a common mistake that it continues to happen to me almost on a daily basis, so don’t feel bad if it does to you. As of ES6 (JavaScript version released in 2015), there are two main ways to declare variables: const and let. These two have, for the most part, replaced the usage of var in modern JavaScript.

The difference between these two is that you cannot reassign const variables while you can with let. Here’s a piece of sample code.

const count = 0;
for (let i = 0; i < 10; i++) {
  count = count + i; // TypeError: Assignment to constant variable
}
console.log(count);

In this case you’ll get an error: Assignment to constant variable. If you’re going to need to reassign a variable, make sure to use let.

let count = 0;
for (let i = 0; i < 10; i++) {
  count = count + i;
}
console.log(count);

4. Misunderstanding Variable Scope

Variable scope is a tricky concept for new developers, especially in JavaScript. One common problem I see from learning developers is defining a variable inside of a function and expecting to be able to access that variable outside of the function it is defined in.

That’s a pretty generic problem I see. Let’s take a look at a more JavaScript specific example though. This goes back to the usage of const and let vs var. I mentioned that var is a more outdated way of declaring variables, but you will still come across it in documentation and source code. Because of that, it’s important to understand how scoping differs with it.

If you define a variable using var inside of a for loop, for example, that variable is also accessible after the for loop. Here’s a quick example.

for (let i = 0; i < 10; i++) {
  var count = 5;
}
console.log(count); //5

This code will actually work although it’s counter-intuitive to me. The value of count is accessible after the for loop it was defined in. However, this does not work for const and let variables. If defined inside of a for loop, they are only accessible inside of that for loop.

for (let i = 0; i < 10; i++) {
  const count = 5;
}
console.log(count); //error: count is not defined

5. Poorly Named Variables

Bad Practice

const arr = ['James', 'Jess', 'Lily', 'Sevi'];
let str = '';
for (let i = 0; i < arr.length; i++) {
  const tmp = arr[i];
  str += tmp[0];
}
console.log(str);

Good Practice

const names = ['James', 'Jess', 'Lily', 'Sevi'];
let retVal = '';
for (let i = 0; i < arr.length; i++) {
  const name = arr[i];
  retVal += name[0];
}
console.log(retVal);

6. Too Large of Functions
This is a pretty meta mistake, but it’s extremely common early on. When developers learn about functions in JavaScript, they often have the tendency to write one function and dump all the code they need into it. However, it’s better to start thinking about how to break functions into smaller pieces of code that are more readable, composable, etc.

7. Unnecessary Else Statements
What often gets misunderstood is that a return statement inside of a function actually stops the execution of that function. In other words, after you return inside of a function, no other code inside of that function gets run. Because of that, I often see unnecessary else statements. Here’s an example.

const isOdd = (num) => {
  if (num % 2 === 1) {
    return true;
  } else {
    return false;
  }
};

Because we already have a return in the if condition, the else is unnecessary. We simplify this code by removing the else condition.

const isOdd = (num) => {
  if (num % 2 === 1) {
    return true;
  }
  return false;
};

You can even take this one step further and return the evaluated expression directly since num%2 === 1 returns a boolean.

const isOdd = (num) => {
  return num % 2 === 1;
}

8. Not Short-circuiting Loops
Short-circuiting is another way to improve your for loops. Let’s say write a function where you need to determine whether an array of numbers includes an even number. Here’s an example of how you might solve that.

const hasEvenNumber = (numbersArr) => {
  let retVal;
  for(let i =0; i< numbersArr.length; i++){
    if(numbersArr[i] % 2 === 0){
      retVal = true;
    }else {
      retVal = false;
    }
  }
  return retVal;
}

In this case, we are iterating through each number and updating a boolean accordingly based on if the number is even. Unfortunately, there’s a problem. Let’s say the first number is even, but then the next number is odd. Well, the boolean is updated to true for even, then back to false for the odd number.

This would give the incorrect answer since you just want to know if the function has at least one even number (it should return true). In this case, after you see the first even number, you have your answer. You don’t need to look anymore. This is where short-circuiting comes into play. After you see one even number, return. If you never see one, return false at the end.

const hasEvenNumber = (numbersArr) => {
  for(let i =0; i< numbersArr.length; i++){
    if(numbersArr[i] % 2 === 0){
      return true;
    }
  }
  return false;
}

This way, your logic is cleaner and you’re avoiding unnecessarily iterating through additional items in the array.

9. Double vs Triple Equals
This is a huge topic of confusion in JavaScript. To start, it’s important to know that the double equals compares two values without taking into account their data types. On the flip side, the triple equals compares two values while taking into account their data types.

Since the double equals doesn’t take into account the data types of the two values, JavaScript has to have some way to compare them. To do this, JavaScript secretly will cast (convert one data type to another) each value accordingly so they can be compared. This means that a number and string could be considered to be double equal but not triple equal since they are different data types.

const jamesAge = "31";
const jessAge = 31;

console.log(jamesAge == jessAge); //equal
console.log(jamesAge === jessAge); //not equal

General piece of advice: use triple equals by default unless you have a specific reason to use double equals. It’s typically safer and helps avoids unintended results.

Incorrect Object vs Primitive Comparisons Another similar problem that I see is trying to compare primitives and objects for equality. There are seven primitive values in JavaScript.

number
string
bigint
boolean
undefined
symbol
null

Everything else is represented as an object, and objects and primitives are referenced differently. In JavaScript, primitives are referenced directly by their value. On the other hand, objects more generically reference a space in memory where the value(s) is stored. This leads to some confusion when objects and primitives. Consider this example.

const name1 = "James";
const name2 = "James";
console.log(name1 === name2); //true

Since these two variables are primitives with the same value they are considered equal, but what if we compare two objects with the same name property like so?

const person1 = {
  name:"James"
}
const person2 = {
  name:"James"
}
console.log(person1 === person2); //false

In this case, these two objects are not considered equal. This is because the two variables are actually references to different “spaces in memory”. Although they look the same, they aren’t considered to be equal because of this. If you wanted to compare their equality more appropriately, you could compare their name properties directly.

const person1 = {
  name:"James"
}
const person2 = {
  name:"James"
}
console.log(person1.name === person2.name);

11. Cannot Read Property of Undefined
As I’m writing this, I’m realizing that I didn’t necessarily order this in terms of frequency. If I did, this one would rank much higher 🤣.

Anyways, one thing that beginner (and experienced) developers forget to do is validate input parameters to a function. Just because you expect to receive an object, doesn’t mean you actually will. Let’s look at this function that prints the name property of an object.

const printNamedGreeting = (person) => {
  console.log(person.name)
}

Seems simple enough, but what happens if someone calls this function and doesn’t pass anything? Well, you’ll get a cannot read property name of undefined error. So, how do you improve on this code?

Well, you’ll need to validate that the input you receive matches your expectations. In this case, one simple (although not complete) solution would be to check that the input parameter is not “falsy”.

const printNamedGreeting = (person) => {
  if(!person){
    return console.log("Invalid person object")
  }
  console.log(person.name)
}

In this case, if the person parameter is “falsy”, we log out an error. Otherwise, we continue to log out the name property.

Keep in mind, this is a quick and simple validation check, but in a real application you’d probably want something more in-depth. You’d want to validate that the input is actually an object (not a string for example) and that it also has a name property.

Lastly, before you say it, yes, you could use TypeScript for this…I know! 😃

12. Mutation with Arrays
Mutation is an interesting concept in JavaScript. In general, mutation occurs when you call a function on a variable that then changes the variable itself in some way. For example, when you call the sort function on an array, the array itself is mutated. However, if you call the map function on an array, the original array remains intact. It is not mutated.

const names = ["Jess", "James",  "Sevi", "Lily"];
const copiedNames = [...names];
const sortedNames = names.sort();
console.log(names); //["James", "Jess", "Lily", "Sevi"]
console.log(copiedNames); //["Jess", "James",  "Sevi", "Lily"]
console.log(sortedNames); //["James", "Jess", "Lily", "Sevi"]

In this example, calling names.sort() will mutate the original names array, meaning the names and sortedNames arrays will look the same. However, the copiedNames array is unaffected since it was a true copy of the original array.

However, if you were to call the map() function on the array, the original names array is unaffected.

const firstLettersArray = names.map( name => name[0]);

The main lesson here is to understand how the functions that you call mutate or not the data you’re working with. This should be listed in the documentation for whatever function you’re calling.

13. Not Understanding Asynchronous Code
The asynchronous nature of JavaScript is one of the most difficult things to grasp for beginner developers. This isn’t the place to go into a full tutorial of asynchronous JavaScript, so I’ll leave you with the most common beginner example there is to introduce the topic. In what order will these log statements print out?

console.log("1");
setTimeout(() => {
  console.log("2")
}, 0)
console.log("3");

14. Not Handling Errors
The problem with lots of beginner tutorials is that they rarely cover how to handle errors in JavaScript. You only see the best case scenarios for code samples, and not the “what if something goes wrong” code. It’s understandable because there’s only so much you can cover in a beginner tutorial. At some point, though, it’s important to spend some time learning how to appropriately handle errors.

Again, this might not be the spot for an in-depth tutorial on error handling, so I’ll leave you with one piece of advice. As you’re writing code, ask yourself ”what if something goes wrong here”. As long as you keep that thought in your head as you’re learning, you’ll be in a good spot!

15. Not Formatting Code
This is another meta example, but it makes such a big difference. Similar to the variable naming section above, poorly formatted code is incredibly difficult to read. Developers are used to reading code in a standardized and formatted way. Because of that, it becomes seemingly impossible to read code that isn’t formatted.

I’ve experienced this over and over again in teaching. To answer what seems like an easy question, I find myself backtracking through the code to try and decipher what is going on. The lesson
here is always spend a bit of time and energy on formatting your code correctly with indentation, spacing, etc. This will make it much easier for you to read as well as anyone else that might read your code.

Memoization in Recursion (JS)

Umashankar S — Wed, 29 Dec 2021 19:15:36 +0000

What is Memoization ?

In a non technical words: Assume, you want to watch one movie, and you downloaded that movie (2TB) and you watched.

After one day, again you want to watch that same movie because its quite interesting. so what you will do now?
Again you will download (2TB) ? or you will watch from your already downloaded file?

In a Technical Words:- It is an optimization technique that speeds up applications by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

Before get into the memoization deeply, lets understood the recursion first.so we will have a better understanding, where we can use our memoization.

Recursion: Recursion is a technique to iterate over the function repeatedly. untill we get a result or untill the condition satisfied.

fibonacci program with recursion:

function fib(n) {
  if(n<=2) {
    return 1;
  }
  else {
    return  fib(n-1)+fib(n-2)
  }
}
console.log(fib(40));

In the above code, we are using recursion concept to calculate fibonacci. so fib(n) will be repeated most of the times.
eg:- fib(40) = fib(40-1)+fib(40-2)
fib(39)+fib(38)

And this tree will go further. and lot of fib(4),fib(5), fib(6), fib(n),etc..... series need to calculate.
Assume fib(4), we calculate and we stored it in cache and again if fib(4) came in that tree. we don't need to calculate again. Just we need to return it from the cache. So this will improve the response time as well.

fibonacci program with recursion and memoization:

let previousValue = []
function fib(n) {
  if(previousValue[n] != null) { //memoization
    return previousValue[n];
  }
  if(n<=2) {
    return 1;
  }
  else {
    result =  fib(n-1)+fib(n-2)
  }
  previousValue[n] = result  //memoization
  return result
}
console.log(fib(40))

And you guys can take both the programs and you guys can check that, which one is having a better response time.

Thanks for your time!!
Cheers!!

Closures in JS

Umashankar S — Tue, 28 Dec 2021 15:26:31 +0000

What is Closure ?

Before get into the closure, lets have a small discussion on lexical scope.

Lexical Scope:- Lexical scope is the ability for a function scope to access variables from the parent scope. which parent ? (nearest parent).

function x() {
    var a = 1;
    function y() {
        var a=2;
        console.log(a) //2
      }
  y();
}
x();

function x() {
    var a = 1;
    function y() {
        console.log(a) //1
      }
  y();
}
x();

So now, hope we understood the basics of lexical scope.

Then what is closure?

A function along with its lexical scope formed a closure.

according to that sentence only, we will write a code. so we can understood it better.

below code is as same as above code with little modifications (logixal scope code)

function x() { //closure start
  var a = 1;
  function y() {
      console.log(a)
    }
  return y;
}             // closure end

let z = x();  // it will contain y function

so z will contain y function.so if we invoke z(). what will be the expected output??

function x() { //closure start
  var a = 1;
  function y() {
      console.log(a)
    }
  return y;
}             // closure end

let z = x();  // it will contain y function
z() //1

Yes the output is 1, in z, not only function will store. along with a function. its lexical scope will also come into the picture.

So, what is closure?
A function along with its lexical scope formed a closure. (Sentence concluded).

That's it, thanks for reading!
Cheers!

This Keyword Scenarios in JS

Umashankar S — Mon, 27 Dec 2021 12:57:30 +0000

This Keyword:-
It is an Object, that is executing the current function.
But, this keyword behaviour is different in different situations.

1. Global Space :- this keyword will always point to the global window object in global space.

console.log(this); //global window object

2. Normal Function:- If we wrote the normal function in global space, that function will always point to the window object, so if we print "this" inside a function. that will always be widow object.

function User() {
    console.log(this) //global window object
}
User();

3. Objects:- If we consider an object, functions inside the object will always have the parent. so "this" will not point to the global object. instead of that, it will point the particular object.

const data = {
  name: 'uma',
  age: 22,
  address: function() {
    console.log(this.age) //22
  }
}

data.address()

Note:- But Arrow Function will always point to the window object.

const data = {
  name: 'uma',
  age: 22,
  address: () => {
    console.log(this.age) //undefined
  } 
}
data.address()

4. Constructor:- Constructor also have the same behaviour as Objects. it will also point to the particular object.

function User(name) {
  this.name = name,
  console.log(this.name)  //uma
}

const user1 = new User('uma')

Thanks for reading!

Higher Order Functions in JS

Umashankar S — Mon, 27 Dec 2021 09:23:46 +0000

Write a snippet of functions to calculate area, circumference and diameter of the circle.

without higher order function (repetitive code):

const radius = [2,3,4,5,6,7];
let output = [];

const area = function(radius) {
  output = [];
  for(i=0;i<radius.length;i++){
    output.push(Math.PI*radius[i]*radius[i]); //Area = PI*radius*radius
  }
  return output;
}
const circumference = function(radius) {
  output = [];
  for(i=0;i<radius.length;i++){
    output.push(2*Math.PI*radius[i]);
  }
  return output;
}
const diameter = function(radius) {
  output = [];
  for(i=0;i<radius.length;i++){
    output.push(2*radius[i]);
  }
  return output;
}
console.log(area(radius));
console.log(circumference(radius));
console.log(diameter(radius));

If we saw the above code, area, circumference and diameter functions are almost same except that maths formula. so we make that as a generalized function using higher order functions.

with higher order function (function that takes another functions as an argument or returns a function)

const radius = [2,3,4,5,6,7];
let output = [];

const area = function(value) {
    return Math.PI*value*value;
}

const circumference = function(value) {
    return 2*Math.PI*value;
}

const diameter = function(value) {
    return 2*value;
}

const calculate = function(radius, logic) {
    output = [];
  for(i=0;i<radius.length;i++){
    output.push(logic(radius[i]));
  }
  return output;
}

console.log(calculate(radius, area));
console.log(calculate(radius, circumference));
console.log(calculate(radius, diameter));

Here we are creating one generalized function , that will accept another function as a input parameter (Higher Order function).

with ES6 feature Map. In the Above section , we created higher order function to perform the operation, and we can achieve the same thing by using the exisiting javascript function called "Map".

const radius = [2,3,4,5,6,7];

const area = function(value) {
    return Math.PI*value*value;
}

const circumference = function(value) {
    return 2*Math.PI*value;
}

const diameter = function(value) {
    return 2*value;
}

console.log(radius.map(diameter))

Cloning of Map function using higher order function. (Map Polyfill). Like Map, we can also create our own prototypes and operations using higher order functions like below.

const radius = [2,3,4,5,6,7];
let output = [];

const area = function(value) {
    return Math.PI*value*value;
}

const circumference = function(value) {
    return 2*Math.PI*value;
}

const diameter = function(value) {
    return 2*value;
}

Array.prototype.calculate = function(logic) {
    output = [];
  for(i=0;i<this.length;i++){
    output.push(logic(this[i]));
  }
  return output;
}

console.log(radius.map(area))  //default js function
console.log(radius.calculate(area)); //cloned the map function

CSS Cheat Codes

Umashankar S — Fri, 24 Dec 2021 08:12:20 +0000

Few of the cheat sheets on CSS positioning

css #javascript #reactjs #webdevelopment #programming #coding

Credits: https://www.linkedin.com/in/pratham-abb051175/.