DEV Community: mayankav

Why can't you break out of the forEach loop?

mayankav — Wed, 29 Sep 2021 16:26:09 +0000

This is one of the many things I keep forgetting every now and then. Other things like taking out clothes from the washing machine, watering my plants, okay but this post is not about me being forgetful. I am sure lot many of you reading this post do know this but still its not until you try to break out of the "forEach" loop that you realize you made the same mistake once again. This post is just a reminder for most of us and maybe a short clarification for the rest of us.

Moving ahead with an example because examples are the quickest way to explain stuff. Lets say we have an array of flowers and we want to collect all the flowers unto my favorite "Tulip" starting from the first one. Yes, please dont make it complicated by throwing in scenarios like what if there are multiple "Tulips". We have an array of flowers, where each flower appears once like so:


    
const flowers = ["Rose", "Lily", "Marigold", "Jasmine", "Tulip", "Lotus", "Orchid", "Daffodil", "Sunflower", "Poppy"];

How would you do it? If I were you I'd rush to get the "forEach" loop down first but not this time. Lets use the conventional for loop and get this done first. Silly but helpful. Easy said, easy done! Then we shall also try that out with my favorite "forEach" loop. Take a look at the following snippets.


    
const flowers = ["Rose", "Lily", "Marigold", "Jasmine", "Tulip", "Lotus", "Orchid", "Daffodil", "Sunflower", "Poppy"];

let vase = [];
//collect all flowers unto "Tulip"
for(let i=0; i < flowers.length; i++) {
  vase.push(flowers[i]);
  if(flowers[i]==="Tulip") break;
}
console.log(vase); // ["Rose","Lily","Marigold","Jasmine","Tulip"]


    
const flowers = ["Rose", "Lily", "Marigold", "Jasmine", "Tulip", "Lotus", "Orchid", "Daffodil", "Sunflower", "Poppy"];

let vase = [];
//collect all flowers unto "Tulip"
flowers.forEach(flower => {
  vase.push(flower);
  if(flower==="Tulip") {
    break; //Illegal break statement
  }
});

Had you tried that on your own, you'd have come across this error that says "Illegal break statement". You can't break out of the forEach loop after you're done collecting "Tulip". You may have already figured out but don't worry if you haven't and let me tell you how does the forEach loop differ from all the conventional loops. "forEach" more than being a loop, is a function call and you know it right from the syntax. This function takes another callback function and mind it, the callback function has to be a synchronous function. The synchronous callback function essentially is then called in interation on the array on which you did call the "forEach" loop. I understand, that this may not sound very intuitive. So, let me try explaining this with a demo polyfill of the "forEach" function. You can easily make it go crazy throwing errors but for a quick example, it should suffice. For complete implementation you can see this.


    
// forEach polyfill
Array.prototype.customForEach = function(callback) {
  const arr = this;
  // internal loop
  for(let i=0; i<arr.length; i++) {
    const x = arr[i];
    callback.call(arr, x);
    // only if we could add a break here, but we can't reach this place
  }
}

const callback = function(x) {
  console.log(x);
  // break; // Illegal break statement
}

// using custom forEach
const flowers = ["Rose", "Lily", "Marigold", "Jasmine", "Tulip", "Lotus", "Orchid", "Daffodil", "Sunflower", "Poppy"];
flowers.customForEach(callback);

Now when you look at the poyfill (customForEach), you'll be able to comprehend the situation much clear. You'd also agree how placing a "break" statement inside a function (named callback) is inappropriate. Read what MDN docs say. Even if you assumed that something like a "break" statement was valid inside a function (which indeed isn't the case), you'd see that it would not be able to break out of the loop, since there's no way you can add a "break" statement inside the internal loop. Why? because you simply cannot access it from outside.

Accomplishing the task we took as an example here for this post, is not a tough job. There are numerous ways this can be done but apart from this example, for your use-case checkout the alternatives available at your disposal. Again, this is not an exhasutive list but then the purpose of this post is served and anything beyond this would only stretch the content unnecessarily I believe. Also since I have now written this post, I think I won't repeat this mistake or will I?

Originally Posted Here -

https://mayankav.webflow.io/blog/you-cant-break-the-foreach-loop

Array().fill is secretly broken

mayankav — Mon, 13 Sep 2021 23:48:18 +0000

There's something weird about Array().fill(). Well, some of you would say Array itself is weird and confusing depending on how its implemented. You say Array('5') to get an array with '5' as its only element and then when you say Array(5), you get an array with 5 empty slots waiting to be fed. If that's not confusing for you, let's not assume it to be the same for someone new to JavaScript. Anyway, cutting it short. Tell me when would you use the fill() method? You just created an empty array and you want to auto populate it with some data you already have. You want to overwrite your array from some index "x" to index "y" with a given value. I am sure a significant number of us would try and grab the fill() method to get this done. Nothing wrong, nothing bad! That's why we have "Array.prototype.fill()".

Before I tell you where can it go wrong, let us ensure that everyone reading this is on the same page. Try going through the naive snippet that follows and see if you can guess the ouput right. Its so naive that you dont even need to open an editor and test stuff out. If you already feel confident and know how it works feel free to skip to the last paragraph.


    
const myArray = Array(5); // empty array with 5 slots
myArray.fill(); // myArray = [undefined, undefined, ...5 times]
myArray.fill(0); // [0,0,0,0,0]
myArray.fill('zero', 1, 4); // [0,"zero","zero","zero",0]

Everything looks fine, right? Yes! it does. We tried creating an empty array. We filled it with some number and then we also tried overwriting the array from index 1 to index 3 (4 is not included). What we did not try yet is filling our array with non-primitives. Lets try doing that now.


    
const myArray = Array(5); // empty array with 5 slots
myArray.fill({x:1, y:2}); // [{x:1,y:2}, ...5 times]
myArray.fill([1,2]); // [[1,2], [1,2], ...5 times]

So far there's no problem but hey! I am here to introduce you to a problem. So if you didn't already smell what's burning, let me show you. Lets say we created an empty array and filled it with 5 empty arrays. Imagine an array 'myArray' with 5 empty arrays inside it. Now lets loop through 'myArray' and try populating all the internal arrays one by one. Take a look at the snippet below and without having it run somewhere tell yourself what do you expect the code to do.


    
const myArray = Array(5); // empty array with 5 slots
myArray.fill([]); // myArray = [[], [], ...5 times]

myArray.forEach(arr => {
  arr.push('x');
});
console.log(myArray); // check the output

You say, we'll get something like an array 'myArray' with 5 arrays inside it, each having one value 'x' inside it? Something like so [ [x], [x], [x], [x], [x] ] ? There lies the problem. Try running the snippet now and see what happens. Weird, right? You get something like so [ [x,x,x,x,x], [x,x,x,x,x], [x,x,x,x,x], [x,x,x,x,x], [x,x,x,x,x] ]. Can you guess what just happened? When you filled your empty 'myArray' with 5 empty arrays, you may have thought that they will be 5 different arrays but that was not the case. Its one array (one reference) that's distributed all across 'myArray'. This is gross. Why would someone want to fill an entire array with the same object? Anyway, this is clearly reflected in the MDN docs if you read the polyfill code to Array.prototype.fill (step 12). Generally, you wouldn't care doing so but then when you get stuck somewhere its always good to checkout what's hidden in the documentation. I was doing some random experiments with radix sort and I enountered this. Even though there are so many other ways you can get this done, let me just share a simple work-around if you really want to use fill to achieve what we tried to achieve in our example.


    
const yourArray = new Array(5).fill().map(()=> []); // yourArray = [[], [], ...5 times]

yourArray.forEach(arr => {
  arr.push('y');
});

console.log(yourArray); // check the output

Try on Codepen

Originally Posted Here -

https://mayankav.webflow.io/blog/array-fill-is-secretly-broken

Why care about Immutability ?

mayankav — Sun, 22 Aug 2021 20:37:23 +0000

We unavoidingly tap into function purity, point free syle, recursion, immutability etc.. when discussing functional programming. You may not necessarily practice all aspects of functional programming in your run-of-the-mill job but if you're someone who works extensively with JavaScript libraries like RxJs, Cycle or state management tools like Flux (Redux, Vuex), I am sure you'd come across immutable objects more often than anything else functional. Immutability infact is so crucial to the reactive world of programming that you can count it into the basics of it. We are not going to talk about strings and other primitives in JavaScript which by design are always immutable.

For a library that's reactive, it needs to preserve the state throughout the execution of the program, why? How else would you detect change in the state? Think of it like this, given that JS objects are ephemeral (non persistent), once you modify some property its value gets changed, the object being the same. If you compare the object before modifcation to the one after modification, well they are the same. Obviously you know why, modifying a property wont generate a new object! To understand this I expect you know that a variable holding an object in JavaScript actually holds the reference to the memory block where the object's properties are stored as key value pairs. Now you may say that you can detect a change by employing a recursive comparison on the data ? Not a performant idea when your state keeps changing every now and then! Immutability suggests shallow copying the object and making new modifications on the new copy of the object. Thinking of the copying step as a signal that something changed in the state, wont be wrong. Now that's a much faster and performance compliant way to tell whether or not the state changed. That may also trigger another doubt, how do you believe that making copies of your state is more performant than a recursive check on the property which changed? Well, that's a good question. I will try to catch up with this towards the end of this post, for now I'd say that there's something called structural sharing that makes this possible.


    
// hidden setup JavaScript code goes in this preamble area


    
const obj = {
    x: 1,
    y: 2
}

const copiedObj = obj;
copiedObj.x = 10;

console.log(obj.x); // 10
console.log(copiedObj.x); // 10 
// Referential equality check doesn't care about the contents, only the reference
console.log(obj === copiedObj); // true

const immutablyCopiedObj = {...obj};
console.log(obj === immutablyCopiedObj); //false

Try on Codepen

In essence immutability has the following benefits

1- Reactivity through change tracking - We already discussed this. Using immutable state can make identifying changes quick and effortless both for the machine and us developers. This is what tools like redux, vuex or even parts of react and vue themselves build their reactivity upon. As soon as something in the state changes, be it based on some asynchronous background activity or a result of user interaction with the UI, a reference equality check instantly signals that it may be the correct time to rerender.

2- Predictability and better debugging - Predictability is very frequently linked with function purity. Given a function which does not cause any side effect within itself, the ouput will always be the same for the same set of inputs no matter how many times you call the function. With this restriction that no function can modify the shared state, we now have tools like Vuex and Redux that let you modify the state but in a way that fulfils their criteria. For example, you can only make changes to the Vuex store through functions listed as mutations in the store. You also have access to methods like Vue.set() & Vue.delete() to register your changes immutably. This makes debugging more easy and outputs/errors more predictable.

3- Versioning - Isn't it obvious that if you can preserve states you can go back and look at the old ones whenever needed? Quite similar to how you still have access to your old piece of code in Git even after merging several times on top of that. Redux implements a feature they call "action replay", wherein you can see the state change and the user interaction side by side in the browser. You think its helpful? Ofcourse! cool and helpful. Now you know how important it is to preserve the state.

4- Performance - I took this as the last thing only because I did not talk about structural sharing when we were discussing performance. You may still be wondering how would creating new objects for every simple change be more performance complaiant than a deep equality check on the objects. While talking about immutability I also used the term shallow copy, that should have given out some hint. If not, its still nothing to worry about. As easy as it is, when making copies its important to be aware that the object you're copying may have nested objects as values to its properties. We shallow copy (just copy the reference without creating a new object) those objects which are not to be changed and only deep clone the nested object that actually needs to be changed. That's what we call structure sharing between 2 objects. You share the entire structure by internal references and only re create the node that needs modification. This may take an example for you to wrap your head around it.


    
// hidden setup JavaScript code goes in this preamble area


    
const tea = {
  tbspSugar: 1,
  type: 'beverage',
  manufacturer: {
    name: 'Assam Tea Company',
    licensed: true
  }
}

// making a copy of tea but with an extra tbsp of sugar
const sweetestTea = {
  ...tea,
  tbspSugar: 2
}

// making a copy of tea but with another manufacturer name
const chineseTea = {
  ...tea,
  manufacturer: {
   ...tea.manufacturer,
    name: 'Chinese Tea Company'
  }
}

console.log(sweetestTea);
console.log(chineseTea);

Try on Codepen

You see its not that difficult but only until it reaches like thousands of properties in an object and then when you need to modify some very very deeply nested object, it sure will break your fingers. If that wasn't enough trouble, a thought of mistakenly altering some other nested object may start bothering you. To avoid hassle when dealing with large chunks of objects, you may opt for libraries like immutable.js or immer. I would highly recommed this article by Yehonathan if you'd like to learn more about structural sharing. If you'd like to explore more on functional programming, give this a read to understand recursion from my point of view.‍

Originally Posted Here -

https://mayankav.webflow.io/blog/why-immutability

< template > vs < div >

mayankav — Sun, 15 Aug 2021 20:08:14 +0000

You'd relate to this if you've been working with likes of Vue and React. The <template> tag also finds use in web components development. You may have considered this trivial enough to let it go without trying to find out 'why use <template> and why not <div> or even <span> which we tend to throw in wherever'. If you fit in that unsubstantial description, probably you'll get to learn something.

Before we start I'd throw in a few points to remember

1- <template> is inert
2- <template> has only one property of its own i.e. 'content'
3- <template> accepts global attrbiutes ('class', 'id', etc..) available on almost anything in HTML.
4- A template's content is not a valid target for events

When I say <template> is inert. It simply means that if you put a template tag in your HTML code, it will sit there doing nothing by itself. The template tag along with its content/children won't be rendered as a part of the DOM, not even on the next reflow. Obvious question, how is that useful? To answer whys and hows, lets first get over the whats. So, the template tag won't reveal itself in the DOM tree unless you explicitly handle it in your JavaScript and make it do so. Its important to note that the DOMParser parses everything including the temlpate tag but in this case only to check syntax validity. Alright, to get the markup inside <template></template> you need to

1- Get the content from template. The content is an instance of DocumentFragment
2- Since DocumentFragment is an implementation of the Node interface, you can use cloneNode() to get a copy of the template's content to then append it somewhere in the DOM. Alternatively, you can select a part of the content using properties available on the DocumentFragment interface or even push the entire DocumentFragment into the DOM tree. If you choose not to clone the content, you'll notice that the part of the document fragment once appended to some node in the DOM tree, is not to be found in the fragment anymore.



---------------------------- HTML ----------------------------

<ul id="container">
  <b>Basket</b>
</ul>

<template id="inert">
  <li>Apples</li>
  <li>Oranges</li>
  <li>Milk</li>
</template>

------------------------- JavaScript -------------------------

const template = document.getElementById("inert");
const documentFragment = template.content;

console.log(documentFragment.childElementCount); // 3

// const deepClone = true;
// const nodeToAppend = documentFragment.cloneNode(deepClone);
const nodeToAppend = documentFragment.firstElementChild;
const container = document.getElementById("container");
container.appendChild(nodeToAppend);

console.log(documentFragment.childElementCount); // 2

[Try on Codepen](https://codepen.io/mayankav/pen/VwbNxjQ)

That said, what does it mean when I say a template's content is not a valid target for events? We now know that content of a template is an instance of DocumentFragment which inturn can be considered a light weight version of [Document](https://developer.mozilla.org/en-US/docs/Web/API/Document). DocumentFragment doesn't make it into the real DOM tree. If you know this you won't mistake it for a target of any sort of event or you may still end up doing something like so ```javascript const template = document.getElementById("inert"); const fragment = template.content; const nodeToAppend = fragment.cloneNode(true); // just another instance of DocumentFragment nodeToAppend.addEventListener("click", () => {...}) // Mistake ```

[Easy to make mistake](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template#avoiding_documentfragment_pitfall)

That alone clarifies how <template> differs from <div>, <span> or any other tag for that matter. Template does exactly what its name suggests, its meant to be used as a temporary case for your unfinished, yet to be processed markup. You may argue that you can use the hidden property on <div> and use it like a <template> but then your unfinished markup will still be a part of the DOM causing side effects (n/w requests for images, scripts etc..) which you may not want. The template element and its contents are inert i.e. not rendered in the DOM, until you grab a reference to it with JavaScript and then append its content to some node in the DOM. You can use a <template> tag when you want to load something into the DOM after processing it in JavaScript, which is what Vue does (processes the elements and makes them reactive). Try replacing <template> with <div> in one of your SFCs and see how Vue reacts with [Vue warn]: Failed to mount component: template or render function not defined.

You could have done well without reading this but I feel it never hurts to know a little more of everything you come across at work. This shall defnitely add value in some way or the other. If you like paying attention to details, I would recommend an old post I wrote on key to responsive websites. You may find it useful. If you want to read more on html templates, go ahead.

Originally Posted Here -

https://mayankav.webflow.io/blog/template-vs-div

Think Recursive

mayankav — Sun, 08 Aug 2021 18:29:38 +0000

I am not so good at cooking stuff but I am an all time admirer of the traditional Polish dish 'Pierogi'. I took a few days off from work last week, all determined not to let the days fly by without getting my hands on the polish delicacy. Now I do realize that I don't even know where to start from. Well, what are friends for? Now read this with patience! I made a call to "Darek" back in Warsaw and asked him if he could give me some direction. Darek, being just another geek, told me that he knows how to do the veggies (the filling) but then he shall ask another friend, how to prepare the wrap. He put me on hold and went ahead to call his friend, Marek. Marek tells Darek that he does indeed know how to do the wrap but then he shall call Alek, who lives nearby to find out how to do the dressing. 'Sauce', my friends, is important. He puts Darek on hold as well. Silly! Alright so Alek, the neighbor finally does't call another friend but gives away the recipe of the sauce. Marek combines his recipe of the wrap with what Alek told him about the sauce and conveys it back to Darek, who was simply waiting to combine this information with the recipe of the filling only to deliver the complete information back to me. Long day but I finally have what I needed.

Lets switch the context now. Did you already visualise the call stack? Only if you don't know, JavaScript runtime uses a call stack to track the execution of functions. Its nothing but a stack that orderly arranges the execution contexts of functions in memory making sure that the currently executing function stays on the top. Going by my example, look how it can actually be portrayed. Think of it as a recurring call to the function getRecipeHelp().

let alek = { name: 'Alek', friend: null, ingr: 'sauce', done: true };

let marek = { name: 'Marek', friend: alek, ingr: 'wrap' };

let darek = { name: 'Darek', friend: marek, ingr: 'filling' };

function getRecipeHelp(friend) {
  if(friend.done) {
    // bail out condition
    return friend.ingr;
  }
  return friend.ingr + ' + ' + getRecipeHelp(friend.friend);
}

// Here we call Darek to get help with the recipe who then calls his friend Marek and Marek finally calls his friend Alek
console.log(getRecipeHelp(darek)); // "filling + wrap + sauce"

Try on Codepen

Assuming you digested the example really well, let me now ask you, how do you think you'd define 'recursion'? The academic definition says 'A non leaf function calling itself'. On a personal note, I understand recursion as a quest to meet the bail out condition so that the return values can sequentially be resolved into the final output. This may confuse you a little unless you understand that every recursive function you define has to have a bail out condition. Broadly, I'd recommend you to remember three things about any recursive function. What are those three things?

You should start with thinking of the bail out condition

Understand that the values start resolving in LIFO fashion to finally render the output

Recursively call the function itself but with a different argument ofcourse ( Make sure you'e moving towards the bail out condition)

Though the bail out condition is quite visible in the example, to make it even more clear, if you do not have this check to stop your recursive calls, you may end up with a stack overflow where functions keep piling up on the stack without returning. By value resolution in LIFO fashion, all I mean is that the functions lower in the stack keep waiting until the final function (that satisfies the bail out condition) returns some decreed value, post which the return values start getting resolved top to bottom in the stack. With so much of this information at hand, go ahead and try implementing the classic factorial function.

function factorial(n) {
  if(n<2) {
    // bail out condition
    return 1;
  } 
  // make sure you're moving towards the bail out condition and not away from it
  return n * factorial(n-1);
}

Try on Codepen

An illustration borrowed from Codeacademy

I think the illustration is self explanatory. If not, lets cover another example. Lets get the fibonacci series in. Hardly anyone in the wild, would be unaware of the fibinacci series but still it goes like this 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.. Every other number starting from the third in series is the sum of the previous two. Fibonacci is magical, go ahead and read this.

// 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ... starts with 0 and 1 and then each number is the sum of previous two numbers in the series

function fib(n) {
  return n <= 1 
  ? n // bail out condition
  : fib(n-1) + fib(n-2); // make sure you're moving towards the bail out condition and not away from it
}
console.log(fib(10)); // 55

Try on Codepen

Conceptually, not much different from what we did for factorials. Think of every recursive function as a mathematical function. Perhaps then it shall become more obvious. We've got our bail out condition at (n <= 1) , where we simply return any argument that's less than 1. Otherwise we go ahead and make recursive calls to the fib function for n-1 and n-2. Well, that only gives me the nth fibonacci member. How'd you print the entire series? Try not to use loops and create a recursive function showFib(n) {..} that prints the series all at once. Here's the code.

Alright! now try calling the fib(n) function like fib(999999) or fib(9999999). Do you see the result already? As you could say just by looking at it, its going to be a huge huge number, your browser may give up on this and start crawling or you may even get a stack overflow exception depending on the content in the call stack. Switch back to the illustration that shows the stack for the factorial program. Can you imagine 999999 functions being piled up all waiting for their successor to return some value? How do you get around this? There's actually a way out but that's kind of a trade off. We call it Proper Tail Calls (PTC). Checkout the last line in the function. For the factorial function its a return statement. The return statement has two parts if you see

a multiplier i.e. n

a recursive call i.e. factorial(n-1)

Since we have the multiplier waiting for the recursive call to return some value, the function cannot be offboarded from the stack. It has this pending work (multiply by n) to finish after the recursive call returns. What if we pass the product to the recursive call instead of waiting with the multiplier? Well, since the pending work will get delegated to the recursive call everytime , the engine won't need to keep the execution stack crowded with functions in stand by.

function factorial(n, product = 1) {
  return n < 1
  ? product
  : factorial(n-1, n * product);
}

console.log(factorial(99)); // 9.332621544394415e+155
console.log(factorial(999)); // Infinity
console.log(factorial(999999)); // Error- Maximum call stack size exceeded

Try on Codepen

You see it works better now. Unlimited frames and you can call a function recursively as many times as you want? Before mentioning PTC, I said it was a tradeoff. A tradeoff with the stack trace. You no longer have easy debugging for your function. Since the function frame is lost to create space in the execution stack, they won't show up even while tracing your error. Read more here. So hold your horses and think before you opt for an optimized recursive solution. Now you're thinking, won't it misfire everytime you place a function call in the tail of a function? You don't want to lose the stack trace. Good news and Bad news, all that I told you about Proper Tail Calls simply won't work with JS engines other than JavaScriptCore (by Apple). Apple likes to call it Tail Call Optimization (TCO). TCO goes one step ahead of PTC to actually optimize your function execution.V8 did infact support this for a while but then for the same reason and possibly some bugs, took it down. If you are on chrome, you can test this out in your debugger. Alternatively you can go through this. V8 creates frames for all function calls and keeps them in the stack regardless of the way you write your code. So you still get the stack overflow exception if you take your recursions off limit. An explicit version of PTC is under discusstion (seems abandoned though). They call it Syntactic Tail Calls (STC).

V8 stacking up function calls

Originally Posted Here -

https://mayankav.webflow.io/blog/think-recursive

The "new" blunder in JavaScript

mayankav — Fri, 30 Jul 2021 16:00:37 +0000

No, I am not even talking about why JavaScript tries to replicate classical inheritance. As much as that is an easy target on JavaScript, lets leave that upto anti evangelists. Just pondering over the "new" keyword in isolation is what I aim for right now. Do we know all the possible ways of creating objects in JavaScript? Assuming that we do, two of the four ways available to us, make use of the "new" operator. The first one being constructor functions and yes you guessed it, ES6 classes.

When I talk of classes, I am somehow driven by my conscience to talk about all the problems classical inheritance brings along but for now I will hold on to the "new" keyword. The question you should ask is, why did we feel the need to have "new", when we could actually use object literals in the first place? I mean, there must be some benefit of saying new SomeFunction() over your old pal { }. Make a guess. Did someone say "creating similar objects"? So when you have a class "YourClass" with class fields "x" and "y" and then when you say "new YourClass(1,2)", you're assured that everytime you do a "new" object creation you will get a similar object, right? We can do that using object concatenation or factory functions but alright, not bad. What else? Maybe it also feels way simpler, no? So far so good. Smart people probably won't even talk about classes and constuctor functions, leave alone the "new" operator. Smart people will do whatever they want. I personally don't favor using classes but that only makes sense when everything is under my control. Being a part of some team, that's not always the case. We need to deal with code whether we like it or not. Assuming that the "new" operator makes it intuitive for you specially when you're coming from OOP, can you figure out the difference here?

new Date(); // Fri Jul 30 2021 20:08:55 GMT+0530 (India Standard Time)
new Date; // Fri Jul 30 2021 20:08:55 GMT+0530 (India Standard Time)
Date(); // "Fri Jul 30 2021 20:08:55 GMT+0530 (India Standard Time)"

Is Date a class, a constructor function or a factory function? If you don't know what a factory function is, its just another normal function that returns an object. So, if a function explicitly returns an object and is apparently not a constructor function, you can call it an object factory function. So what do you think Date in JavaScript is? I'll leave that on you to experiment with. If you can't reckon, think of how "new String()" & "String()" behave. The former gives you a new object whereas simply calling String(..) over some primitive does cast the value's type to string. The question is how do you define a function that can be safely called with and without the "new" operator? A factory function returns you the same object irrespective of whether you call it with or without a "new" operator. A constructor function on the other hand unless and until called with a "new" prefix returns undefined.

function factoryFn(x, y) {
  const obj = {};
  obj.x = x;
  obj.y = y;
  return obj;
}

function ConstructorFn(x, y) {
  this.x = x;
  this.y = y;
}

console.log(factoryFn(1, 2)); // {x:1, y:2}
console.log(new factoryFn(1, 2)); // {x:1, y:2}

console.log(ConstructorFn(1, 2)); // undefined
console.log(new ConstructorFn(1, 2)); // {x:1, y:2}

Try on Codepen

Now, I am kind of more interested in the constructor function. Notice that when you simply call your constructor function without the "new" keyword, it returns undefined? Visibly so because there's nothing to return. Interestingly, unless you're in strict mode, you've now also created properties "x" and "y" on the global object. I understand, there's hardly someone in the wild who'd instantiate a constructor function without "new". Anyway, we know how a constructor function otherwise implicitly returns "this" (an anonymous object created using the "new" keyword). What if I put a blunt return statement right inside the constuctor function? Take a look.

function ConstructorFn(x, y) {
  this.x = x;
  this.y = y;
  return new String('a blunder');
}

function AnotherConstructorFn(x, y) {
  this.x = x;
  this.y = y;
  return "not a blunder";
}

console.log(new ConstructorFn(1,2)); // "a blunder"
console.log(new AnotherConstructorFn(1,2)); // {x:1, y:2}

Try on Codepen

Uncannily, if you return an object or an array, it seems to block the implicit nature of the constructor function that returns the "this" object, upon being instantiated with the "new" operator whereas returning an atomic string makes no difference as such. How do you think it is possible to make a constructor function work safe without the "new" operator? Why would you even want to do that? Well, you may have your own reasons, I just want to prevent the users of my constructor function from mistakenly trying to invoke it without the "new" operator. I know you can simply use an ES6 class but for some reason I want to stick to the old functions style and yes I am not using the strict mode as well. Strict mode inside the function can alert you from creating implicit globals.

function StrictConstructor() {
  if(this.constructor === StrictConstructor) {
    this.x = 1;
    this.y = 2;
  } else {
    throw new Error("StrictConstructor should only be instantiated with 'new' operator")
  }
}

console.log(new StrictConstructor()); // {x:1, y:2}
StrictConstructor(); // Error

Try on Codepen

So the conditional filter we used to throw the error depends on how the "new" operator creates a new object and assigns it a constructor under the hood. If you want to get deep into this you should definitely go check out the MDN reference and then my last blog post. As a matter of fact, instead of throwing an error you can even return an object to eliminate the need of calling the function using "new" like so:

function StrictConstructor() {
  if(this.constructor === StrictConstructor) {
    this.x = 1;
    this.y = 2;
  } else {
    return new StrictConstructor();
  }
}
console.log(new StrictConstructor()); // {x:1, y:2}
console.log(StrictConstructor()); // {x:1, y:2}

Conclusion

For a while, if you forget about JavaScript, its not very intuitive to instantiate functions with the "new" operator. Probably that's why we name our constructor functions in PascalCase. Due to the fact that the "new" operator and constructor functions may behave eerie at times (specially when you forget the "new" operator), you can choose a combination of options from the available list to keep your code safe from surprises.

An ES6 class shall help you spot when someone forgets the "new" keyword, by throwing an error
Following the convention of naming constructor functions in Pascal.
Placing a check within your constructor function to either throw an error on skipping the "new" operator or to silently fix the implicit behavior of the constructor function.

Originally Posted Here -

https://mayankav.webflow.io/blog/the-new-blunder-in-javascript

JavaScript Inside Story : More about Prototypes and Inheritance

mayankav — Sat, 17 Jul 2021 23:39:10 +0000

I almost picked the title "JavaScript's Factory for Everything", but then I changed my mind after reading my older post. Just trying to push my last post here. I don't feel very comfortable writing this, not because I don't understand the stuff but because its something that pretends to be something it really is not. Protesting that prototypal inheritance is not inheritance at all does not change anything. Perhaps if it were not for the comfort of OOPers, it could have been better called prototypal wiring or maybe prototypal delegation. If you're coming from Java, how would you answer the question, "Why does Java not suppport multiple class inheritance?". Well, you'd point out the Diamond Problem, won't you? Given that JavaScript doesn't know this problem how would you explain it not being able to support such a thing? PS: It can be done but it has its own issues. Despite its appearance resembling to that of classical inheritance, JavaScript has its own reasons for (not) being able to do certain things. Not asking you to unlearn the classical inheritance take but then to understand JavaScript's way of handling prototypal inheritance you need to drop those intuitive assumptions atleast for the time being. ‍‍

I dont want to recall the time when I started logging objects in the console only to check what's really inside of them. I mean I knew objects had their properties but I also found stuff like __proto__, constructor, prototype, __proto__ again. It would not stop. I kept on digging and it kept on throwing more and then I realized I was willingly stuck in a loop of references. Let me take help of an analogy to explain this to you. Lets assume that any function you create in JavaScript is a House to be put on rent. The House then comes with a bunch of keys ( prototype ). The bunch of keys has another bunch of small master keys ( __proto__ ) inside it and has a label ( constructor ) with the name of the house on it. This bunch of keys is given to the tenants ( objects created from the function ) and the tenants then keep it with them and they like to call it guess what ? __proto__. Heck! confusing. Its not that easy to build analogies here. Just take a look at the diagram I came up with.

Check out the Ppt

What you see is what I am going to pen down now. Consider a class A or simply a function A. The function when created, gets two properties by default namely prototype and __proto__. __proto__ is a property that is available on everything in JS be it a primitive or an object. Go ahead! try that in your console. It contains some information from the function that was responsible for creating the primitive/object in the first place. Since a function is nothing more than a Function object, the __proto__ property on each and every function takes its value from Function.prototype. What about the prototype property? In contrast with __proto__ which is available on anything and everything in JS, prototype is only available on JavaScript functions. The prototype property is an object ( only exception being Function.prototype which is a native function ) with two default properties namely constructor ( refers to the Function/Class itself to which prototype belongs ) and __proto__ . The purpose of __proto__ on A.prototype is nothing different from that on the function A itself. A.prototype.__proto__ contains information about the function that was responsible for the creation of A.prototype. Since this object (A.prototype) was automatically created, the function/class responsible for its creation was Object. No wonder why every SomeFunction.prototype.__proto__ gets a default value of Object.prototype. To verify this, try creating an object using the object lietral syntax like so. ‍

let randomObj = {};
console.log(randomObj.__proto__ === Object.prototype); // true

Try on Codepen

Moving on to instantiating the constructor function, lets do let objA = new A(); to create an object from the function A. objA gets a __proto__ . We just discussed how everything in JS gets this default property with a value of SomeFunction.prototype, SomeFunction being the function/class responsible for its creation. No points for guessing its value in this case. Its A.prototype. ‍

let objA = new A();
console.log(objA.__proto__ === A.prototype); // true 
console.log(objA.prototype); // undefined

.prototype only exists on functions. Try on Codepen.

Prototypal Inheritance‍

All this while what I've been trying to tell you is that __proto__ is just the pen name of prototype. A constructor's prototype becomes it's object's __proto__ . How does this help? Well since its not the copy but the reference to a function's prototype which is shared amongst objects created using the function, any new function/property on the prototype of a function is readily available on the object's __proto__ as well. Though its not a good practice to monkey patch properties on the protoype of a constructor function. Read more about that here. Interestingly you dont even need to access the patched property via __proto__ . You just access it on the object like objA.somePatchedFunction() and it gets resolved from __proto__ in the chain. This sounds fun but can very quickly get on the nerves when some object starts patching functions/properties on its __proto__ property causing a prototype namespace pollution.

Anyway, did you think of this? What happens when you manually alter the __proto__ property on objA like objA.__proto__ = { random : 10 } ? Apparently, the link from the function A breaks and you can no more access the functions patched on A.prototype and then you get access to properties of the newly set object ({ random : 10 }) like objA.random. Apart of assigning a value directly to objA.__proto__ there exist lawful functions (Object.setPrototypeOf, Object.create) in JavaScript to help you do this some of which are on the verge of being deprecated but that's not my concern for this blog post. This does not even seem very helpful. Why don't we try altering the __proto__ property on A.prototype? Well, that sounds like a plan.

function Parent() {
  this.p = 50;
}
Parent.prototype.patchedP = 100;

function Child() {
  Parent.call(this);
  this.c = 200;
}

//  Object.create sets (Child.prototype).__proto__ = Parent.prototype
Child.prototype = Object.create(Parent.prototype);
// Resetting the child constructor may/may not be needed
Child.prototype.constructor = Child;

Child.prototype.patchedC = 400;
console.log(new Child().p); // 50  //undefined if no Parent.call(this)
console.log(new Child().patchedP); //100

Try on Codepen

For the ease of understanding lets try to alter Child.prototype. Let me tell you what am I trying to do. When I create a new object using the Child constructor function, I can say something like new Child().c and get the expected value i.e. 200. What I want is to get a valid value on doing so new Child().patchedP ie. 100. Do you think I should simply make an assignment like so Child.prototype = Parent.prototype ? Well , no because then when you want to patch some functions on Child.prototype, you will end up patching the orignal Parent.prototype. Changes on Child should not impact Parent or you can't call it inheritance. I better use an intermediary object to set the prototype of child. That's why we do this Child.prototype = Object.create(Parent.prototype). Now when you patch the Child's prototype, it won't impact the Parent (you only patch the intermediary object).

Did you notice the call to Parent function within the Child function (kind of super if you're coming from Java) ? Try commenting it out in the pen. That shall leave you with no access to Parent's instance properties i.e. p here. When you call the Parent with 'this' (this refers to the newly created object when you say new Child()), the Parent function executes to add the property p on new Child(). Now in every new instance you create from the Child function, you get access to instance properties of Parent & Child both along with patched properties of both Parent.prototype & Child.prototype. Additionally, now patching Child.prototype will not impact Parent. Now that's something we can kind of call inheritance. Just to touch upon the concept of prototype chaining, it goes without saying that if you try to access aChild.randomProperty given aChild = new Child(); , it shall be first looked up in the property list of aChild itself, if not found it should be searched for in aChild.__proto__ (the intermediary object we discussed earlier), next in aChild.__proto__.__proto__ until the search reaches Object.prototype which is the last man standing in the prototype chain.

A look at new Child()‍

Take Away

Every function's .prototype property is of type - object except function Function. (It's .prototype property is of type - function)
Every function's .__proto__ property is always equal to Function.prototype and hence of the type - Function.
Objects don't have .prototype property.
Every object's .__proto__ property is of type object.
An object's .__proto__ property takes its value from the .prototype property of the Function from which it was created.
If an object was not created using any particular function (created using object literal or using Object.create(Object.prototype)), the value of it's .__proto__ property will be Object.prototype.
Create an object from a class A or a function A : let objA = Object.create(A.prototype); or let objA = new A();
In ES5, inheritance looks like so : let anObjectFromParent = Object.create(Parent.prototype); Child.prototype = anObjectFromParent;
In ES6, the extends keyword plays the role of Object.create(Parent.prototype) and the super keyword invokes the constructor of the parent.‍‍
Accessing __proto__ directly on an object is not as optimal as using the new keyword, Object.create (to set) and Object.getPrototypeOf (to get).
__proto__ is just a way to programmatically access an object's [[Prototype]] internal slot which is otherwise not accessible in code.

Originally Posted Here -

https://mayankav.webflow.io/blog/javascript-prototypal-inheritance

Is everything in JavaScript an Object?

mayankav — Sat, 10 Jul 2021 19:59:53 +0000

Well well! The motivation for this post comes from my last post where I had a comment from one of my readers that I couldn't agree with. I was talking about functions and closures (also how closures work internally) and how every function in JavaScript is indeed a closure on its surrouding scope but then somebody said, aren't all entities in JavaScript objects? I didn't see that coming but this wasn't the first time somebody put this up. So you will find me trying to break this down practically in this post.

If you can, bring up your browser's console and try creating a simple variable and give it a string value. How did you do it? Did you write something like

var myString = "That's my string";

or did you choose to go with

var myString = new String("That's my string");

For a fact, I know you didn't choose the last method. I mean no body does and if you want to prove me wrong and say that you did infact choose the second one, well somebody will then probably ask you, why? MDN says "String primitives and string objects can be used interchangeably in most situations". MDN then also says "A Primitive is data that is not an Object". The second statement makes the answer clear "Not everything in JavaScript is an Object" and this can easily be verified by using the "typeof operator". We still need to clarify the pin size difference. With an example?

let myString = "That's my string";
let yourString = new String("That's your string");

console.log(typeof myString); // outputs "string"
console.log(typeof yourString); // outputs "object"

//MDN says primitives and objects can SOMETIMES be interchangeably used
let yourBigString = yourString.toUpperCase();
console.log(yourBigString); // outputs "THAT'S YOUR STRING"
let myBigString = myString.toUpperCase();
console.log(myBigString); // outputs "THAT'S MY STRING"

Try this on codepen

Does that ring a bell? We do often use primitives and objects interchangeably because JavaScript makes it possible for primitives to somehow use the methods designed into real Objects. Using a primitve value shall give you the benefit of writing concise without losing on the comfort of using easy methods to manipulate and process the values. When you call a String object's method on a primitive string value, to make this work your primitve is first wrapped into an appropriate Wrapper class (String in this case). The method you want to call is called on the transient object which is discarded as soon as the result is returned. Read on MDN. The following codepen shall present a demo.

You may have two question now:

If this is taken care of internally, what may go wrong if we assume that everything in JavaScript is an Object?
If the JS engine does this autoboxing internally everytime we use a primitive, isn't this more expensive than simply using String Objects?

To answer the first question, let me throw another example which is an extension to the very first example. The example shows a case where someone would try assigning a property to some primitive expecting it to be retrievable. If you assign some property to a string primitive with an intention of getting the value back at some point, you will only be returned 'undefined' because the temporary String Object was discarded then and there. Similarly such assumptions can misfire when using eval (which indeed should not be used). These examples may not be very relatable but I guess they are enough to warn us from assumptions.

I believe the second question is no less important. Even though this seems like a tedious process of coercing a primitive into an Object and then calling the method on the temporary object, the JavaScript engine highly optimizes this process. It may even skip the creation of the extra object altogether. If you still wonder why do we even have primitives, you better ask Brendan Eich as T.J Crowder says in this answer.

Conclusion

To conclude I'd just highlight that MDN says "String primitives and string objects can be used interchangeably in most situations". We probably know why they say "most situations" and not "always".

Originally Posted Here -

https://mayankav.webflow.io/blog/is-everything-in-javascript-an-object

Are all JavaScript functions Closures ?

mayankav — Sun, 04 Jul 2021 18:43:59 +0000

Probably this is one of the most dreaded topics to talk about. Quite a few readers won't even bother to read on but hey! hang in there and we will keep things simple. To explain what closures are, I won't begin with the classic ubiquitous example of a silly function within another function (keeping it for later though). Well, closures also play a very obvious role when implementing event handlers (DOM Level 2). Lets talk with an example, shall we?

Try this out on codepen

There's nothing much to the code shown above, its as simple as a function that takes in an integer and sets event listeners on two different buttons. The first event listener calls a function (callback) when the first button is clicked. The callback function in turn increments the counter and shows it in an alert box. The second event handler does nothing different apart from the fact that its callback function decrements the same counter. Do we understand that even after the function setClickHandler has finished execution (offboarded from the execution stack with all its variables and arguments), the two event listeners are actively listening for a click on their respective buttons? Well, that's how event listeners work, right? You set them up once and they stay there for you unless you call "removeEventListener" on the node. There's another interesting thing to observe in the small code snippet. When the function "setClickHandler" has already left the call stack (no arguments and local variables in memory anymore), why do the callback functions not throw a "ReferenceError" when trying to access the argument "counter" which effectively lies in the lexical scope of "setClickHandler" ? Well, if you want to attribute this to the scope chain, you won't be completely wrong but then when I ask you how does something up in the scope chain remain active in memory after the owner function has offboarded the execution stack? That's when you need to say CLOSURES.

What is a closure?

Lets try to gain some clarity on stuff we discussed so far. The MDN says a function along with references to its surrounding scopes is a closure for that function. Well, won't you then protest that literally every function in JavaScript by default gets access to everything in its respective lexical (surrounding) scope? If that's true then every function has to have a closure as soon as its created. Bingo! guess who is correct again? Exception being functions created with the Function constructor. We usually tend to ignore a function's ability to fom closures when the function finishes its execution well within its lexical scope. What if the same function gets returned from its lexical scope and is refrenced somewhere else later in time? The function will still have access to the references (memory location of variables and functions) in its lexical scope as it would even if it were not returned. Wait! how? Didn't the scope chain die when the outer function finished execution? Infact, it did! but before it died, right when the inner function was being returned, the scope chain was saved as a property ( or an internal slot as ECMAScript quotes ) of the inner function itself. The specification calls it [[Environent]], however Google Chrome uses something like ( [[Scopes]]: { closure } ). It seems chrome did this back in time following the old specification from 2011. Just to mention, Firefox and IE don't even show a function's inner slot like chrome does. Alright, so this saved scope chain is nothing but Closure. That's how an inner function closes over the references in its surrounding scope.

If you try to inspect such a function's execution in devtools, you shall notice that as soon as the function is pushed on the top of the execution stack, its closure shows up in the scope chain as if the function carried it throughout. If you're 5, a closure is a function who took notes ( [[Environent]] ) to remember what has been taught in the school, outside the school.

‍

Detect a Closure

If you really want to visualize this, the easiest way is to use an online visualizer. I will keep it simple and use chrome devtools instead.

Inner function returned from the Outer funtion

It's not necessary that the inner function be returned to form a closure

Chrome does not show the inner function in the Local scope?

Conclusion

Well, now you know how closures are formed. The last example can be a bit confusing. So to clarify, since Chrome does not show the inner function in the outer function's local scope, it does not mean that it doesn't exist (You can see that on Firebox). Chrome probably lists the function only when it has been invoked, stored or returned. Similarly, every function when created forms a closure with its surrounding scope but we only care about closures when the function escapes its lexical scope to execute at some point later in time after its surrounding function is dead. In the end, it shouldn't matter much whether you say all JavaScript functions are closures or all JavaScript functions have closures. You get the gist of it. Here's an interesting codepen that demonstrates function currying, a good practical use-case of closures. I would also recommend reading the performance considerations on MDN.

Originally Posted Here -

https://mayankav.webflow.io/blog/all-functions-are-closures

JavaScript's Broken Mathematics ? 💔💔

mayankav — Sun, 27 Jun 2021 20:49:57 +0000

Does mathematics already scare you? Well, if it does take a deep breath and read on and by any chance if it does not, I will try my best to scare you now but ofcourse with a promise that we shall fill all the gaps before ending this post. Doesn't matter what programming langauge you code in, you shall still be able to relate to this post. For my convenience I will kill it with JavaScript.

So long back, I was working on a game that added 1 point to the user's score for every correct answer and deducted 0.1 points for a wrong one. The game starts with 1 point in your balance and then the score gets calculated based on your choices. Prima facie it worked fine (kind of) but then something caught me by dismay. I started the game (score = 1) and submitted three wrong answers back to back. What do you expect? A score of 1 - 0.1 - 0.1 - 0.1 = 0.7 ? Got you! Try that right away in your browser's console. It works alright you say? I bet you did 1 - 0.3, that indeed shall give you 0.7 but when you do it incrementally like I did, you shall see that

✔️ 1 - 0.1 = 0.9

✔️ 0.9 - 0.1 = 0.8

❌ 0.8 - 0.1 = 0.7000000000000001

Confused? Check out this codepen

Why is 0.8 - 0.1 not 0.7? Well, it is so in real world mathematics. So, is JavaScript's mathematics broken? Co-readers who also code in python would now tell you that even Python failed in its maths class. What's happening? Well, if you want a short blunt answer its the binary system making floating point calculations unpredictable. So yes its not your favorite programming language. We shall ofcourse discuss how to get around with this limitation but I cannot hold myself from digging a little more into the root cause.

Do we all understand that our computers store all and any kind of information in binary? Assuming you said 'YES', how is a decimal number (which we input) converted into binary before it gets stored? Do you know that after the number is converted into binary, to get stored in the register (memory), the binary should be first arranged in some appropriate format? "Binary Floating Point Representation" is the term we use for those formats. Call it FPR for simplicity.

Floating Point Representation

Binary Floating Point Representation can be of 3 types :

Half Precision Format
- available memory for a given number = 16 bits
- microFloat
- least precise & least wasteful
Single Precision Format
- available memory for a given number = 32 bits
- float data-type in Java
Double Precision Format
- available memory for a given number = 64 bits
- double data-type in Java
- most accurate representation of bigger numbers‍‍

Taking you back to school? No, please take a quick look (1.5x speed) at this video if you're not sure what did I just say. Now that you know we have limited space in the memory to store the binary representation, what if the binary of some number you input doesn't fit in 64 bits? Well, we round it up and make it fit in 64 bits somehow and hence we introduce the famous Rounding Error. This rounding error is the characteristic feature of floating-point computation and obviously when you input some number X, it may or may not stay exactly X after binary round off.

So what could be the examples of numbers whose binary won't fit even in 64 bits? A very obvious case can be of a number whose binary representation is non-terminating. 0.1 ? Seriously? Yes, lets see how this simple small decimal number has got a binary equivalent that never terminates (like the value of π in decimal).

‍

Not my best handwriting though

That's how the decimal 0.1 looks in binary

There's a simple rule to find out if the given decimal number will have a non terminating binary or not. A decimal has an equivalent terminating binary if and only if the decimal, written as a proper fraction in lowest terms, has a denominator that is a power of two. Example : 0.1 has an infinite binary : 0.1 = 1/10, and 10 is not a power of two. Also 0.5, on the other hand, terminates: 0.5 = 5/10 = 1/2.

Apart from such numbers with non terminating binaries there can also be numbers with terminating but too big to fit in 64 bits binaries. Such numbers can also result in rounding errors. Now when I ask you to debug my game, you shall be able to atleast say (after looking at the output) that 0.8 - 0.1 is not 0.7 because somewhere in the binary round-off 0.8, 0.1 or 0.7 or maybe all of them got introduced to the rounding error. So what do we learn from this? We learn that FPR of the decimal numbers we input can make calculations unpredictable. How do we deal with this? Well, I shall tell you how, atleast how in JavaScript.

‍

Solution to the round-off error in JavaScript

Math.round((0.8-0.1)*factor)/factor shall give 0.7, where factor = 10 for rounding to single digit, 100 for rounding the result to 2 digits after decimal and so on.
(0.8-0.1).toFixed(1) shall give "0.7" but in string format. Mostly irrelevant now but "toFixed" may show inconsistencies amongst older versions of some browsers. Read more .
There can be many more solutions. For example the "floor" and "ceil" functions of the Math object depending on the use-case or even custom functions like so.

Conclusion

Most decimals have infinite representations in binary. Due to limitation of memory, rounding errors may get introduced in numbers whose binary equivalent does not fit even the Double Precision Format. So do not be surprised the next time you see an anomaly in floating point calculations. Its good to use one of the above mentioned solutions or a custom tailored solution that fits your requirement.

‍

Originally posted here -

https://mayankav.webflow.io/blog/javascripts-broken-mathematics

JavaScript's Broken Mathematics ? 💔

mayankav — Sun, 27 Jun 2021 19:30:38 +0000

✔️ 1 - 0.1 = 0.9

✔️ 0.9 - 0.1 = 0.8

❌ 0.8 - 0.1 = 0.7000000000000001

Confused? Check out this codepen

Floating Point Representation

Binary Floating Point Representation can be of 3 types :

Half Precision Format
- available memory for a given number = 16 bits
- microFloat
- least precise & least wasteful
Single Precision Format
- available memory for a given number = 32 bits
- float data-type in Java
Double Precision Format
- available memory for a given number = 64 bits
- double data-type in Java
- most accurate representation of bigger numbers‍‍

‍

Not my best handwriting though

That's how the decimal 0.1 looks in binary

‍

Solution to the round-off error in JavaScript

Math.round((0.8-0.1)*factor)/factor shall give 0.7, where factor = 10 for rounding to single digit, 100 for rounding the result to 2 digits after decimal and so on.
(0.8-0.1).toFixed(1) shall give "0.7" but in string format. Mostly irrelevant now but "toFixed" may show inconsistencies amongst older versions of some browsers. Read more .
There can be many more solutions. For example the "floor" and "ceil" functions of the Math object depending on the use-case or even custom functions like so.

Conclusion

‍

Originally posted here -

https://mayankav.webflow.io/blog/javascripts-broken-mathematics

The Key Element to Responsive Websites

mayankav — Sun, 20 Jun 2021 18:56:37 +0000

What is the first thing you think of when someone says responsive websites? What comes rushing to your mind when you think of the most important piece of code related to responsive websites? CSS? relative units (%)? Media queries? Well, we won't talk about that here. This post aims to pin point the most essential stuff without which none of your responsive techniques would ever work the way you expect them to. We are talking about the html tag. Well, but you know meta tags have got nothing to do with what's being rendered, right? They just carry information regarding the page content. They do not even appear on the page themselves. How do they matter when it comes to making our web page responsive?

There's a special meta tag called the meta viewport, which actually has a lot to do with how well your page adapts to the screen it is rendered on. Lets dig deep.

<head>
    <title>Meta Viewport Example</title>
    <meta name="viewport" content="width=80, initial-scale=1.0">
</head>

Look at the code snippet that shows a meta tag enclosed within the Head section. The name attribute says viewport. That should be enough to indicate that this tag is supposed to add some kind of information related to the viewport - the space on the screen on which your web page is being rendered. Lets not confuse the viewport width with screen width. They may be the same when the rendering device is a mobile phone (we shall talk about this later in the same post) but on desktops and PCs, you can play with the size of your browser. Check out the following piece of code. Paste it in your browser console and resize your window to see how the viewport width changes.

window.addEventListener("resize", () => { 
 console.log(document.documentElement.clientWidth); 
});

Now that we hopefully understand the difference between the physical screen width and the viewport width, let me break it to you that mobile phones generally (if not all of them) do not map the viewport to the exact dimensions of the screen (width). You can check out some real examples here. So for example if a mobile phone's screen is say 320px wide, it may consider a virtual viewport that is 800px, 900px wide or whatever and then minimize (zoom out) the rendered output to fit the screen size. Why would they do so you ask? This comes from back in time when responsive websites were not that common maybe. Even today not all websites are made mobile friendly (which indeed isn't what we want to do). If the mobile browser vendors mapped the viewport width of the browser to the screen width, the elements in the real website (big images/big buttons etc..) would break when rendered on such a small viewport. So they render it on a bigger viewport and then scale down the result to show it to you on a smaller screen. You can then zoom in on the part you want. You want an example? Checkout YouTube but do it on your desktop and then resize your window to make sure you do not go to m.youtube.com which is another version meant specifically for mobile phones.

YouTube Desktop (not optimized for mobile experience)

This however, is not an ideal experience for websites which are made mobile friendly. Can you guess what sort of issues can this virtual viewport cause? You guessed it, didn't you? The media queries will start breaking. If you put in place a media query that should fire at 320px, it simply won't get triggered because factually the screen width is 900px which was just zoomed out to show it to you on a 320px wide mobile screen. What do such mobile browser vendors do for developers like us who write media queries to make our websites look good on all screen sizes? Well, they gave us this meta viewport tag which we can now use on our web page and tell the browser, to set the virtual viewport's width in accordance with our needs. So now when you say

html <meta name="viewport" content="width=device-width" />

, the mobile browser knows that you want to render your page with a virtual viewport that is as wide as the device's screen. Of course, you can set this "width" value to random pixels but that does not bring us joy. You can see the examples on w3school.

Interestingly, if you use boilerplate builder tools like create-react-app, vue create etc.. you may or may not have bothered to go through the index.html file completely. If you do a cross check, you shall definitely find the meta viewport tag included in the head section. Get rid of it for a while and see how your web app behaves on different screen sizes. Hopefully now, everyone can relate to the virtual viewport of mobile browsers.

Learn more about Virtual Viewports here

Originally posted here -

https://mayankav.webflow.io/blog/key-to-responsive-websites