DEV Community: therealnrf

My Course: Boost Your Confidence in Vanilla JS

therealnrf — Tue, 01 Mar 2022 22:55:24 +0000

Although self-learning is great, it does come with its pitfalls. Going through the posts of budding developers, it soon becomes apparent that two issues are becoming increasingly common: being stuck in tutorial hell and impostor syndrome. Being a teacher, I started thinking about combating this problem and that basically became the premise of my ebook Boost Your Confidence: Vanilla JS.

The ebook (presented in a course format) is currently in its alpha release. The main reason behind this early release is to gauge how helpful people find my approach. Below is the introductory section of the ebook which details what it covers. I hope it proves beneficial to all the self-learners!

Please click here to see the course sales page (free preview available)

For future updates, you can follow me on twitter: Link to twitter profile

Boost Your Confidence: Vanilla JS is targeted towards beginner JavaScript developers who find themselves stuck in tutorial hell or are going through what is called impostor syndrome. These two problems often go hand-in-hand and are becoming increasingly frequent.

It is fairly common these days to see someone post that even after following a detailed tutorial (or a number of them), when they finally tried to do something on their own, they simply couldn't; as a result they just looked for and followed more tutorials. But, for some reason, even after completing courses and following various tutorials, they find themselves stuck in the same loop. This is called being stuck in tutorial hell.

Also common is when someone can actually build stuff on their own but feel like they don't really understand all the details or are missing crucial bits of information. As a result they think that they should still study/learn more before they take a serious step in this direction like applying for jobs or start looking for freelance work. This is the impostor syndrome.

Both of the problems described above can be tracked down to one, or all, of these:

By following random tutorials information was not acquired in a structured manner. Structured learning gives the learner clarity and confidence in what knowledge has been acquired. This clarity also results in increased confidence in oneself. This is not to say that one feels like they've learned everything (that never happens), but rather that one becomes confident in what has been learned and what remains to be learned.
Repetition wasn't done. Short-term memory can be very tricky. One follows a tutorial, even when typing along, understands it and feels like the material has been learned. But if the material is not repeated in some way the short-term memory soon fades and the tutorial cycle begins again. To counter this, repetition must be done (like a lot) and should be done on your own. Repetition will finally commit the material to memory.

The traditional educational institute actually combats both of the above points. Courses have a structured syllabus and tests/quizzes are given as an incentive to repeat the material covered in the class. At the end of the day, it is really up to the student to utilize the presented opportunity to its fullest.

If we look at the responses to the people going through the problems described above, we see that the most common response they receive is something along the lines of just build stuff. While this is good advice, the problem is that a beginner needs at least some hand-holding to get started. Again, the traditional institute does this inadvertently by scheduling TA sessions and grading tests.

In this book, I've tried to address the above mentioned issues.

Firstly, each section starts with a knowledge base chapter which is supposed to give a concise but organized introduction to the section's topic. This should serve as a solid foundation before moving towards the problem set.
After the knowledge base, comes the problem set. This is where the reader is supposed to exercise problem solving and, just as importantly, apply the knowledge gained previously so that it actually sticks. To avoid the trap of tutorial hell, an extra step, called prompts, is introduced between providing the problem and its solution.

The idea is that initially the reader is presented with only the problem. The reader should attempt to solve the problem just from the statement. But in case some guidance is needed, or the reader gets stuck, prompts should serve as a set of hints to guide the reader in the proper direction. Hopefully this provides just enough support without giving the whole solution away.

In the end, the solution is also provided but this is mostly to verify the results. Additionally, there are usually more than one way to solve the same problem so hopefully the provided solution serves as an alternate. Reading other people's code is an excellent exercise in and of itself.

What is covered?

Broadly, this book covers two topics:

DOM manipulation

This section is presented in two parts. The first part deals with the tools that deal with selecting, searching, styling, and traversing the DOM nodes. The second part adds to that knowledge by going over event processing. This would include responding to user's clicks, typing, form validations, etc.

Dealing with APIs

This section deals with talking to 3rd party APIs. This would include sending requests to an API server, receiving and processing the data, dealing with asynchronous techniques, and the standard Fetch API.

The above two topics are the bread and butter of any JavaScript developer. They collectively represent the foundational knowledge that every JavaScript developer must possess.

Who is this book for?

This book is not an introduction to JavaScript. It assumes that the reader has at least an introductory knowledge of HTML, CSS, and JavaScript and is looking to build on that foundation through repetition and exercise. This book is for you if you know:

how to create a basic HTML page
what tags are in HTML and what are their attributes
basic CSS
- how to select element(s) by tag name, id, classes
- styling selected element(s) using CSS properties (e.g. width, height, color, font-family, etc.).
basics of JavaScript
- variables (var, const, let)
- basic data structures (Arrays, Objects)
- conditional statements (if, else, switch)
- loops (while, do..while, for, for..of, for..in)

Basically if you've completed an introductory course on HTML, CSS, and JavaScript then this book should serve as an excellent next step.

Explicit is better than tricks

therealnrf — Sat, 15 Jan 2022 12:01:25 +0000

When writing code, it is always better to be as explicit as possible instead of going for tricks. This concept is best explained by examples so let's get right into it.

The double bang !! (logical NOT)

This one is by far the most common "trick" in the JavaScript world. So much so that it is actually taught to developers as they learn about logical operators in JavaScript and can be found in Mozilla's official documentation (MDN). If you wish to obtain a primitive boolean (true or false) from a non-boolean entity, you can use the logical NOT operator as follows:

const primitiveBoolean = !!notABoolean;

If notABoolean is truthy in the example above, primitiveBoolean will contain the value true and if it is falsy, primitiveBoolean will be false.

You can get the same results by using the Boolean() function and get a much more readable version of the code.

const primitiveBoolean = Boolean(notABoolean);

Does the double bang way provide any benefit? The correct answer is no, but it does carry the disadvantage of making your code less readable. This trick (like many others) works because of JavaScript's type coercion. Let's look at the spec to see how the logical NOT operator (!) works.

Specification for logical NOT operator

As can be seen, after the expression is evaluated and a final value is obtained, this final value is passed through an algorithm to get the final value's boolean equivalent. This algorithm is represented by ToBoolean() in the spec and is basically just a series of conditions to determine the boolean equivalent of a value (you can see the exact steps by clicking on ToBoolean on the spec's page). Once this is done, next step is what the NOT operator is supposed to do: return false if the evaluated value is true and true otherwise. The second NOT operator then inverts this value to finally give the correct result (and we end up with the double bang !!).

Now let's see how the Boolean() function works.

Specification for Boolean function

So when Boolean() is called as a function, as opposed to a constructor (i.e. with the new keyword), it performs a simple type conversion. This type conversion is done using the same algorithm, ToBoolean(), discussed above.

In both cases, your code is performing the same task behind the scenes. If anything, the double bang trick has an extra step of inverting the value obtained by the first operation. While using Boolean() results in a much more elegant and readable code.

The unary + operator

Wish to convert a string representation of a number to an actual number? Just precede it with a + like so:

const myData = +"123";
console.log(typeof myData); // output: "number"

This gives us even more obscure code than the double bang trick discussed above. Still, this might prove to be controversial as even the MDN docs say that this is the "preferred" method to convert a string to a number. Let's look at the alternative:

const myData = Number("123");
console.log(typeof myData); // output: "number"

Just as we had used Boolean() as a function to get a primitive boolean value, we have used Number() as a function here to convert the string to a number. The details behind the scenes here are exactly the same as before except the fact that instead of ToBoolean, the algorithm used for type conversion is called ToNumber in this case.

Specification for unary + operator

Specification for Number function

The MDN docs say that using the unary + operator is the fastest method but the specs tell us a different story. Both + and Number() use the exact same algorithm to do the type conversion but the latter results in a much more readable code.

The magic numbers

This one isn't related to type conversion but is seen relatively frequently. Magic numbers are the use of numbers directly in your code. It is more preferable to declare a well-named variable and assign it the desired value than to use the number directly.

if (password.length < 6) {
  throw new Error("Password must be more than 5 characters long");
}

Considering the code above, a much better approach would be:

const MIN_PASSWORD_LENGTH = 6;

if (password.length < MIN_PASSWORD_LENGTH) {
  throw new Error(`Password must be more than ${MIN_PASSWORD_LENGTH - 1} characters long`);
}

The first and obvious advantage here is that the code is now much more readable. Another potential advantage would be in the case where the same constraint is utilized in multiple places (which happens fairly often). If the constraint later changes, you'll only have to update it at one location.

If there is a direct number in your code, strongly consider declaring a constant and using it instead. Most of the times this will be the correct approach. Although there are some edge cases where using the number directly might be the preferable.

if (transactions.length > 0) {
  // show transactions
} else {
  // show msg: "No transactions"
}

The above code is perfectly readable and there seems to be no reason to declare a separate variable for the value 0.

Conclusion

When writing code, readability should be a priority. The tricks/shortcuts usually add no benefit, performance or otherwise, and make the code considerably less readable. So, always go for a more explicit option.

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

React.memo() is your friend

therealnrf — Wed, 22 Dec 2021 21:44:32 +0000

React.memo() is one of those things that should be a part of every React developer's arsenal. It gives us the ability to memoize a React component. As with any tool, before we delve into how to use React.memo(), let's understand the problem first.

Why memoize?

Memoization is a general concept which basically means caching the results of some kind of computation for later use. It is an optimization technique which is used quite extensively in the programming world.

An important point to remember is that whenever memoization is used, there must be a criteria which would dictate when the cached results are no longer valid and the computation must be done again.

To understand the problem this solves, consider the following React component:

import { useState, Fragment } from "react";

function App() {
  const [count, setCount] = useState(0);

  function handleDecrement() {
    setCount((oldCount) => --oldCount);
  }

  function handleIncrement() {
    setCount((oldCount) => ++oldCount);
  }

  return (
    <Fragment>
      <p>Count is {count}</p>
      <button onClick={handleDecrement}>-</button>
      <button onClick={handleIncrement}>+</button>
    </Fragment>
  );
}

export default App;

A simple component that keeps a count which can be increased or decreased.

Now let's add another component to <App />. To keep it simple, we'll create a <Message /> component that returns some kind of message depending on the msgId that is passed to it as a prop.

function Message(props) {
  let msg = "hello, world";

  if (props.msgId === 1) {
    msg = "hey there!";
  } else if (props.msgId === 2) {
    msg = "hola!";
  }

  return <p>{msg}</p>;
}

We've kept it simple here but imagine this <Message /> component does some heavy computation or perhaps sends a request to an external API in order to get the final message. We'll simulate this situation by adding everyone's favorite console.log() in the mix.

function Message(props) {
  let msg = "hello, world";

  console.log("Just performed some seriously heavy computation");

  if (props.msgId === 1) {
    msg = "hey there!";
  } else if (props.msgId === 2) {
    msg = "hola!";
  }

  return <p>{msg}</p>;
}

Let's update the <App /> component to use <Message />.

import { useState, Fragment } from "react";

function Message(props) {
  let msg = "hello, world";

  console.log("Just performed some seriously heavy computation");

  if (props.msgId === 1) {
    msg = "hey there!";
  } else if (props.msgId === 2) {
    msg = "hola!";
  }

  return <p>{msg}</p>;
}

function App() {
  const [count, setCount] = useState(0);

  function handleDecrement() {
    setCount((oldCount) => --oldCount);
  }

  function handleIncrement() {
    setCount((oldCount) => ++oldCount);
  }

  return (
    <Fragment>
      <Message msgId={1} />
      <p>Count is {count}</p>
      <button onClick={handleDecrement}>-</button>
      <button onClick={handleIncrement}>+</button>
    </Fragment>
  );
}

export default App;

In the video below, take special note of the fact that every time count is changed, the heavy computation is done.

To understand why the heavy computation is done every time count changes, check out this post: Re-rendering in React

At this point, take a step back and think about how inefficient our UI is at this moment. count does not affect <Message /> in any way but still every time count is updated, the seriously heavy computation is performed. We only want the computation to occur if the msgId changes because a change in msgId should result in a different message.

React.memo() to the rescue

React.memo() is a higher-order component. It accepts a component as its argument and memoizes the result. The memoized result is updated only if the props of the original component are changed.

To use React.memo(), simply pass your component as an argument and save the result. Our <Message /> component will become:

import { useState, Fragment, memo } from "react";

const Message = memo(function (props) {
  let msg = "hello, world";

  console.log("Just performed some seriously heavy computation");

  if (props.msgId === 1) {
    msg = "hey there!";
  } else if (props.msgId === 2) {
    msg = "hola!";
  }

  return <p>{msg}</p>;
});

Note: I've only imported memo() here. If you have React imported, you can use React.memo() instead of just memo().

Now our code looks like this:

import { useState, Fragment, memo } from "react";

const Message = memo(function (props) {
  let msg = "hello, world";

  console.log("Just performed some seriously heavy computation");

  if (props.msgId === 1) {
    msg = "hey there!";
  } else if (props.msgId === 2) {
    msg = "hola!";
  }

  return <p>{msg}</p>;
});

function App() {
  const [count, setCount] = useState(0);

  function handleDecrement() {
    setCount((oldCount) => --oldCount);
  }

  function handleIncrement() {
    setCount((oldCount) => ++oldCount);
  }

  return (
    <Fragment>
      <Message msgId={1} />
      <p>Count is {count}</p>
      <button onClick={handleDecrement}>-</button>
      <button onClick={handleIncrement}>+</button>
    </Fragment>
  );
}

export default App;

This time, notice that the computation is done when the application is refreshed but the change in count no longer has that result.

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

Stop using arrow functions everywhere ...

therealnrf — Tue, 02 Nov 2021 04:29:52 +0000

Ever since their inclusion in JavaScript, arrow functions' usage has increased at a very rapid rate by JavaScript developers. Everyone seems to like arrow functions; perhaps more than they really should.

Firstly, there are situations where one absolutely should not use an arrow function.

Before going further, it is important to understand that arrow functions are not just a syntactical sugar for normal functions. Arrow functions, apart from having a different syntax for declaration, also behave differently than normal functions. One of the key differences is that they have no knowledge of the execution context. The execution context is dynamic (assuming your application has function calls) and is accessed through the this keyword in JavaScript. This is why it is often said that arrow functions do not have their own binding to this. They inherit this from their enclosing scope. This difference is at the heart of understanding when not to use arrow functions.
window.id = 107;

const obj = {
  id: 108,
  normalFunction: function () { console.log(this.id) },
  arrowFunction: () => { console.log(this.id) },
}

obj.normalFunction(); // output: 108
obj.arrowFunction(); // output: 107
The reason arrowFunction() logs 107 is that its declaration (as a method of obj) is in the global scope which, in the case of a browser environment, is the window object. So this resolves to window inside arrowFunction().

Do not use arrow functions ...

... when defining object methods

Using arrow functions to define object methods may result in unexpected (buggy?) behavior. Chances are that if you're defining an object method, you need access to to its properties from within that method.

const counter = {
  count: 0,
  currentCount: function () { return this.count },
  incrementCount: function () { ++this.count }
}

counter.incrementCount();
console.log(counter.currentCount()); // output: 1

Everything is good and works as expected. But, if we had used arrow functions here:

const counter = {
  count: 0,
  currentCount: () => { return this.count },
  incrementCount: () => { ++this.count }
}

counter.incrementCount(); // this does nothing unfortunately
console.log(counter.currentCount()); // output: NaN

this resolves to the window object in the above case and window.count doesn't exist. If it is conciseness you're after, you can use the new shorthand syntax for defining object methods. The code below is equivalent to the first example above:

const counter = {
  count: 0,
  currentCount() { return this.count },
  incrementCount() { ++this.count }
}

counter.incrementCount();
console.log(counter.currentCount()); // output: 1

... when defining prototype methods

This case is conceptually similar to the one discussed above. If you wish to access an instance property, you must not use an arrow function when defining the prototype method.

function Person(name) {
  this.firstName = name;
}

Person.prototype.normalGreet = function () {
  console.log(`Hi ${this.firstName}`);
}

Person.prototype.arrowGreet = () => {
  console.log(`Hi ${this.firstName}`)
}

const person1 = new Person("Jack");

person1.normalGreet(); // output: "Hi Jack"
person1.arrowGreet(); // output: "Hi undefined"

As you can see, this.firstName inside the normal function resolves successfully to "Jack" while in the case of the arrow function it returns undefined. This is because inside the arrow function this points to the function's enclosing scope which is the window object in this case. Since window.firstName is undefined, it returns undefined.

... when defining any function that depends on the dynamic context

The recurring theme is that arrow functions have no knowledge of the (dynamic) execution context and, hence, should not be used when the execution context is a factor. Another example of this would be callbacks that depend on the dynamic context like event handlers.

someButton.addEventListener("click", () => {
  console.log(this.innerText);
})

In the code example above, clicking on someButton will log undefined since this does not refer to the currentTarget.

Furthermore, call, apply, and bind do not work with arrow functions.

... when defining a constructor function

Arrow functions can't be used as a constructor function (can't use new with them). It will simply raise an error.

const Person = (name) => {
  this.firstName = name;
}

const person1 = new Person(); // TypeError: Person is not a constructor

... if you wish to use the special `arguments` object

Just like with this, arrow functions do not have their own arguments object. Instead, arguments inside an arrow function refers to the arguments of the enclosing scope.

function greet(name) {
  const constructGreeting = (greeting) => {
    return `${greeting} ${arguments[0]}`;
  }

  return constructGreeting("hello");
}

console.log(greet("Jack")); // output: "hello Jack"

As you can see, arguments[0] inside the arrow function constructGreeting() actually resolves to the value of name which is the argument to greet() (the function that encloses constructGreeting()).

It's not all bad

There are scenarios where arrow functions provide benefit. Mostly by making the code cleaner/intuitive.

Async callbacks

Imagine you have async code but you still need access to the original context that called the async function (from within the async callback). Normal functions wouldn't work here (if you used this inside the async callback). This issue was previously solved by using bind or declaring a self variable where self = this. But since this is already lexically bound in an arrow function, the arrow function solves this problem elegantly. An example should clear things up.

const obj = {
  firstName: "Jack",
  useName: function () {
    setTimeout(function () {
      console.log(`Hi ${this.firstName}`);
    }, 1000);
  }
}

obj.useName(); // output after 1 second: "Hi undefined"

In the example above, I've used setTimeout() to simulate asynchrony. The callback function passed to setTimeout() is called after 1 second of calling obj.useName(). By the time the callback function is called, useName() has long been executed. In fact, the callback queue is executed in the global context (window in case of our browser environment). This means that this = window when the async callback is called. This is why this.firstName resolves to undefined.

As I stated above, before arrow functions, this problem was solved by:

using bind

  const obj = {
    firstName: "Jack",
    useName: function () {
      setTimeout(function () {
        console.log(`Hi ${this.firstName}`);
      }.bind(this), 1000);
    }
  }

  obj.useName(); // output after 1 second: "Hi Jack"

by declaring a referencing variable (traditionally called self)

  const obj = {
    firstName: "Jack",
    useName: function () {
      let self = this;
      setTimeout(function () {
        console.log(`Hi ${self.firstName}`);
      }, 1000);
    }
  }

  obj.useName(); // output after 1 second: "Hi Jack"

Now we can simply use an arrow function which gives us the expected results.

const obj = {
  firstName: "Jack",
  useName: function () {
    setTimeout(() => {
      console.log(`Hi ${this.firstName}`);
    }, 1000);
  }
}

obj.useName();

Callbacks for iterator functions

When I say iterator functions I mean functions like map(), reduce(), and forEach() that go through each item of an iterable and feed that item to a callback function. This is where arrow functions really shine. No need to worry about the dynamic context. Additionally, the compact syntax and the implicit return feature of arrow functions often result in code that is concise and more readable at the same time.

const myArray = [2, 4, 6, 8];

const newArray = myArray.map(number => number * 2);

console.log(newArray); // output: [4, 8, 12, 16]

In my humble opinion ...

Although arrow functions are a great addition to JavaScript, and in the proper context their concise syntax improves code readability, I still don't think that they should be the default for function declaration. If the situation doesn't specifically call for it, there is no need to use an arrow function.

Consider, for example, your globally-scoped or module-scoped functions (perhaps you have a helpers.js file that has a bunch of helper functions your application needs). The arrow function syntax in this case simply looks more cluttered than a normal function declaration. On top of it, the code becomes even more cluttered if you have async functions and need to export some of them.

export async function foo() {
  // function body
}

export const bar = async () => {
  // function body
}

Using arrow functions:

export const firestore = firebase.firestore();
export const auth = firebase.auth();
const provider = new firebase.auth.GoogleAuthProvider();

export const signInWithGoogle = () => auth.signInWithPopup(provider);

export const getUserDocument = async (uid) => {
  // body
}

export const createUserDocument = async (user, additionalData) => {
  // body
}

Using normal functions:

export const firestore = firebase.firestore();
export const auth = firebase.auth();
const provider = new firebase.auth.GoogleAuthProvider();

export function signInWithGoogle() {
  auth.signInWithPopup(provider);
}

export async function getUserDocument(uid) {
  // body
}

export async function createUserDocument(user, additionalData) {
  // body
}

The normal function syntax is just better. It reads better and it is actually less typing. Not that less typing should be a factor here but I've often observed that it is a factor behind using arrow functions.

Another example, which is slowly becoming a pet peeve of mine, is using arrow functions for declaring a React funtional component. There is just no need to do that! You can simply use a normal function declaration.

Using an arrow function:

export default const UserCard = (props) {
  // a ReactJS functional component -- arrow edition
}

Using a normal function:

export default function UserCard(props) {
  // a ReactJS functional component -- normal edition
}

Isn't a normal function delcaration much clearer?

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

Arrow Functions

therealnrf — Wed, 13 Oct 2021 03:04:18 +0000

This article is part of the first installment of a series I'm calling JavaScript You Must Know. The aim of this series is to go over various fundamentals of the JavaScript language that a developer must know/understand before moving forward with any of the modern JavaScript frameworks like React, Angular, and Vue. Learning these fundamentals in parallel with the frameworks would also be acceptable.

This first installment of the series focuses on syntax-related topics and is called JavaScript You Must Know -- Essential Syntax.

Arrow functions, or arrow function expressions, are another way of declaring functions in JavaScript. But, please note right from the outset, that the differences between regular functions and arrow functions don't end with just the syntax. In other words, arrow functions are not a syntactic sugar for regular functions rather they're treated differently by the compiler. In this section, we'll focus on the just the syntax of arrow functions.

Let's quickly see an example of an arrow function compared to an old-school function declaration.

function oldSchoolFunc(a, b, c) {
  console.log(a, b, c);

  return (a + b + c);
}

The same function above using the arrow function syntax would be:

const arrowFunc = (a, b, c) => {
  console.log(a, b, c);

  return (a + b + c);
}

So, the function keyword was removed and an arrow => (equal sign followed by a 'greater than' sign) was introduced before the opening curly brace { to convert the old-school syntax to an arrow function syntax. Also please note that the part that constitutes an arrow function is to the right of the assignment. The identifier arrowFunc is just a variable that is being used to hold a reference to the arrow function so we can invoke it later.

When it comes to function definitions, we basically have two things to consider: the parameter list and the function body. We'll take these one by one and go through their different cases to see how an arrow function is written in each case. Remember, the starting point is always the same: remove the function keyword and introduce the arrow => before the opening curly brace {. Once you get used to the arrow function syntax though, you won't have to think in terms of the old-school syntax anymore.

Please note that I'm using the term "old-school" quite loosely here. This in no way implies that the arrow functions have "replaced" the original function declaration syntax. There are places where using an arrow function is better suited than a normal (non-arrow?) function and vice versa. There are situations where the use of arrow functions is even discouraged!

Cases for function's parameter list

Case 1: no parameters

function oldSchoolFunc() {
  /* function body */
}

const arrowFunc = () => {
  /* function body */
}

The empty parentheses are required in this case.

Case 2: Multiple parameters

function oldSchoolFunc(a, b, c) {
  /* function body */
}

const arrowFunc = (a, b, c) => {
  /* function body */
}

Case 3: Special case of exactly ONE parameter

If the function has exactly one parameter, we can let go of the parentheses () in the arrow function expression. Note that you can use the parentheses as well; your choice. In my opinion, using the parentheses makes for a more readable code.

function oldSchoolFunc(a) {
  /* function body */
}

const arrowFunc1 = a => {
  /* function body */
}

const arrowFunc2 = (a) => {
  /* function body */
}

Both arrowFunc1 and arrowFunc2 are equivalent.

Cases for function's body

Case 1: Multi-line body

If the body of a function has more than one lines, nothing changes:

function oldSchool(a, b, c) {
  // line 1
  // line 2
}

const arrowFunc = (a, b, c) => {
  // line 1
  // line 2
}

Case 2: Special case of SINGLE-LINE body

If the body of a function has exactly one line, then:

No need for the curly braces
No need for the return keyword (if any)

function oldSchoolSum(a, b) {
  return (a + b);
}

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

If an arrow function has exactly one line and the curly braces are left out, the line is executed and its final value is returned by the function (called implicit return). Note that you can still use the return keyword in this case but then curly braces are required. Taking the arrowSum function above as an example:

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

💡 just a tip

There is something to be said about the two special cases discussed above: exactly one parameter and single-line body. Go for the option that results in a more readable code. For example, even though we have the option, using parentheses even when there is only one parameter seems better because it feels more readable (in fact, the famous code formatter Prettier will enforce this as a rule). Similarly there are times when using the return keyword just looks more natural even if the function only has one line. Do not automatically go for the more concise option rather take a moment and decide which option will result in a more readable code.

More than just syntax

As mentioned at the start of this section, it isn't just the syntax that is affected when using the arrow functions. Arrow functions:

don't have this
don't have super
can't be used as constructors i.e. can't be called with new
have no arguments variable

💡 just a tip

Arrow functions fit very nicely as callbacks.

const randomNumbers = [1, 12, 30];
let randomNumbersDoubled = [];

setTimeout(() => {
  console.log("Doubling the array now...");

  randomNumbersDoubled = randomNumbers.map((number) => (number * 2));

  console.log(randomNumbersDoubled);
}, 500);

With arrow functions, at least initially, it is mostly the syntax that you have to get used to. I've prepared an Arrow Functions Cheat Sheet which has all the cases discussed in this article.

👉🏻 Get your FREE copy of the cheat sheet: click here

Destructuring

therealnrf — Tue, 05 Oct 2021 17:16:21 +0000

This first installment of the series focuses on syntax-related topics and is called JavaScript You Must Know -- Essential Syntax.

Destructuring, also called destructuring assignment, is when individual elements of an iterable are extracted and assigned to variables. By far the most common use cases for it are with Arrays and Objects.

Array Destructuring

Let's say we have an array, rgba, which defines the red, green, blue, and alpha values.

const rgba = [100, 100, 0, 0.2];

We wish to extract thsoe values and store them in individual variables called red, green, blue, and alpha. The old-school way to do this would be something like this:

const rgba = [100, 100, 0, 0.2];
const red = rgba[0];
const green = rgba[1];
const blue = rgba[2];
const alpha = rgba[3];

console.log(red, green, blue, alpha); // output: 100 100 0 0.2

With destructuring, it would be:

const rgba = [100, 100, 0, 0.2];
const [red, green, blue, alpha] = rgba;

console.log(red, green, blue, alpha); // output: 100 100 0 0.2

Note the square brackets on the left hand side of the assignment at line 2. These square brackets signify that a destructuring assignment is being requested. Once it is determined that a destructuring is required, the expected value on the right hand side of the assignment is an iterable; which in our case is an array.

With array destructuring, the values of an array are assigned to the variabes from left to right. This means that the value at index 0 will be assigned to the first variable, the value at index 1 will be assigned to the second variable, and so on. If a value is not required to be stored, we can simply skip naming it and move on.

const rgba = [100, 100, 0, 0.2];
const [red, green, , alpha] = rgba;

console.log(red, green, alpha); // output: 100 100 0.2

In the above example, we deleted the variable blue but didn't change the positions of any of the other variables. That's why at the end we only have red, green, and alpha declared with the correct values.

The right hand side of the assignment can be the array literal itself. The following is perfectly valid and would give the same results as our second-last example above.

const [red, green, blue, alpha] = [100, 100, 0, 0.2];

Left hand side has more variables

In case the left hand side of the assignment has more variables than the elements of the array:

The extra variables will be declared but will have no value assigned to them. Therefore they will be undefined. In the example below, since a 4th element doesn't exist in the array rgb, alpha is undefined.

  const rgb = [100, 100, 0];

  // left hand side of the assignment below has more variables than elements in the array
  const [red, green, blue, alpha] = rgb; 

  console.log(red, green, blue, alpha); // output: 100 100 0 undefined

The variables can be assigned a default value. If a corresponding element is available on the right hand side, the variable's value will be updated. Otherwise, the default value will be used. In the next example, green is set to 100 (even though a default value is present) via destructuring assignment and alpha retains its default value of 0.2 since it doesn't have a corresponding element in the array rgb.

  const rgb = [100, 100, 0];
  const [red, green=125, blue, alpha=0.2] = rgb;

  console.log(red, green, blue, alpha);

Right hand side has more variables

In case the right hand side of the assignment has more elements than the variables:

If there are more elements in the array than the variables being declared, then the assignment will be carried out normally and the extra elements of the arary will have no effect whatsoever. As an example, we'll again take the rgba array but only extract the red, green, and blue values and leave alpha alone.

  const rgba = [100, 100, 0, 0.2];
  const [red, green, blue] = rgba;

  console.log(red, green, blue); // output: 100 100 0

Finally, we can use the rest syntax to gather any and all remaining values neatly into an array. Notice, in the example below, that restOfThePlanets is an actual array with all the remaining elements of planetsInTheSolarSystem. This is the same as using rest parameters to gather all the arguments to a function into an array.

  const planetsInTheSolarSystem = ["Mercury", "Venus", "Earth", "Mars", "Jupiter", "Saturn", "Uranus", "Neptune"]; // is Pluto a planet?
  const [firstPlanet, secondPlanet, thirdPlanet, ...restOfThePlanets] = planetsInTheSolarSystem;

  console.log(firstPlanet, secondPlanet, thirdPlanet, restOfThePlanets);
  // output: "Mercury" "Venus" "Earth" ["Mars", "Jupiter", "Saturn", "Uranus", "Neptune"]

💡 just a tip

Array destructuring can be used to easily swap the values of two variables.
let a = 10;
let b = 20;
[a, b] = [b, a];

console.log(a, b); // output: 20 10

Object Destructuring

When it comes to objects, the destructuring assignment has one very important difference from array destructuring: with objects, the variables on the left hand side of the assignment are used to look-up the values from the object on the right hand side (the order doesn't matter). Also, curly braces {} are used instead of square brackets [] to signal an object destructuring.

const studentRecords = {
  id: 107,
  name: "Plump Sunny",
  physics: "A",
  chemistry: "B+",
  mathematics: "A+"
}

const { id, name } = studentRecords;

console.log(`${id}: ${name}`); // output: "107: Plump Sunny"

Let's go through the destructuring in detail. The curly braces {} on the left hand side of the assignment signal that an object destructuring is requested and, this automatically implies, that there should be an object on the right hand side of the assignment. Next, the first variable is called id, the JavaScript engine will look for a key called id in the studentRecords object. If id is found in studentRecords, its value will be assigned to the id variable. If id is not found, then the id variable will be undefined. The same process is followed for the name variable.

Object destructuring is very useful and is used by programmers extensively. And for good reason too as it makes the code very concise. Note that the order in which the variables appear is not important here (as opposed to array destructuring where the order is important).

const studentRecords = {
  id: 107,
  name: "Plump Sunny",
  physics: "A",
  chemistry: "B+",
  mathematics: "A+"
}

const { name, id } = studentRecords;

console.log(`${id}: ${name}`); // output: "107: Plump Sunny"

In the example above, even though we swapped the id and the name variables on the left hand side of the assignment, each variable still gets the correct value from the studentRecords object.

Since the variable names are used to look-up the values from an object, one might think if we can rename the variables when destructuring an object. The answer is that we can by using the following syntax:

const studentRecords = {
  id: 107,
  name: "Plump Sunny",
  physics: "A",
  chemistry: "B+",
  mathematics: "A+"
}

const { physics: phy, chemistry: chem, mathematics: maths } = studentRecords;

console.log(`Physics: ${phy}
Chemistry: ${chem}
Mathematics: ${maths}`);

Note that the variables that got declared in the end are called phy, chem, and maths.

[console output]:

Physics: A
Chemistry: B+
Mathematics: A+

An easy way to remember the syntax is to imagine talking to the JavaScript engine like: "Hey JS, get physics as phy, chemistry as chem, and mathematics as maths from the object studentRecords."

Just like with arrays, we can provide default values to the variables as well as use the rest syntax. The only difference is that using the rest syntax with object will return an object rather than an array (which makes sense).

const studentRecords = {
  id: 107,
  name: "Plump Sunny",
  physics: "A",
  chemistry: "B+",
  mathematics: "A+"
}

// using default value for 'age'
// using the rest syntax to initialize 'grades'
const { id, name, age="N/A", ...grades } = studentRecords;

console.log(`${id}: ${name} / Age: ${age}
Grades: ${JSON.stringify(grades)}`);

[console output]:

107: Plump Sunny / Age: N/A
Grades:
{'physics':'A','chemistry':'B+','mathematics':'A+'}

Here age was assigned "N/A" because no key called age was found in the studentRecords object so the default value of age was used. Moreover, notice that grades is an object that contains all the remaining key/value pairs from studentRecords. Got a bit fancy here by using JSON.stringify(). All this function does is take a valid JavaScript object and returns the same object as a string that can be printed.

Use in function parameters

One of the most useful uses of object destructuring is in function parameters. Let's first understand the problem. Imagine there is a function that expects, as its arguments, a student's id and that student's grades in all the different classes. The end result might look something like this:

function wantStudentDataForSomeReason(id, physics, chemistry, mathematics) {
  // todo: do something with all that data
}

const studentRecords = {
  id: 107,
  name: "Plump Sunny",
  physics: "A",
  chemistry: "B+",
  mathematics: "A+"
}

// time to call our function
wantStudentDataForSomeReason(studentRecords.id, studentRecords.physics, studentRecord.chemistry, studentRecord.mathematics);

It is easy to see that calling wantStudentDataForSomeReason() is a chore. Not only did we have to input each of the values individually, we also had to make sure that the values are in the same order as in the function's definition. Furthermore, what if one or more values was not available in the studentRecords object!

A nifty trick to avoid all of this trouble is to use object destructuring right in the parameters list of the function.

function wantStudentDataForSomeReason({ id, physics, chemistry, mathematics }) {
  // todo: do something with all that data
}

Notice that the parameters are not individual variables any more but are surrounded by curly braces. Now, if an object is passed as an argument to this function, object destructuring will take place and the variables will get the correct values if they exist.

function wantStudentDataForSomeReason({ id, physics, chemistry, mathematics }) {
  // todo: do something with all that data
}

const studentRecords = {
  id: 107,
  name: "Plump Sunny",
  physics: "A",
  chemistry: "B+",
  mathematics: "A+"
}

// time to call our function
wantStudentDataForSomeReason(studentRecords);

Once again, the function call in the last line of the code example above will basically resut in the following destructuring assignment to take place:

{ id, physics, chemistry, mathematics } = studentRecords

Truly an amazing use of destructuring. Now we don't have to refer to the list of parameters in the function's definition and the order doesn't matter as well. As for the missing values, any missing value will automatically be assigned undefined.

Use in APIs

APIs usually return a lot of data and, more often than not, the application does not need all of the data returned by the API. Instead of keeping the whole object returned by the API, we can used destructuring and keep only what we need.

As an example, let's consider the API of randomuser.me. The API returns a results array within a JavaScript object which looks like this:

{
  "results": [
    {
      "gender": "male",
      "name": {
        "title": "mr",
        "first": "brad",
        "last": "gibson"
      },
      "location": {
        "street": "9278 new road",
        "city": "kilcoole",
        "state": "waterford",
        "postcode": "93027",
        "coordinates": {
          "latitude": "20.9267",
          "longitude": "-7.9310"
        },
        "timezone": {
          "offset": "-3:30",
          "description": "Newfoundland"
        }
      },
      "email": "brad.gibson@example.com",
      "login": {
        "uuid": "155e77ee-ba6d-486f-95ce-0e0c0fb4b919",
        "username": "silverswan131",
        "password": "firewall",
        "salt": "TQA1Gz7x",
        "md5": "dc523cb313b63dfe5be2140b0c05b3bc",
        "sha1": "7a4aa07d1bedcc6bcf4b7f8856643492c191540d",
        "sha256": "74364e96174afa7d17ee52dd2c9c7a4651fe1254f471a78bda0190135dcd3480"
      },
      "dob": {
        "date": "1993-07-20T09:44:18.674Z",
        "age": 26
      },
      "registered": {
        "date": "2002-05-21T10:59:49.966Z",
        "age": 17
      },
      "phone": "011-962-7516",
      "cell": "081-454-0666",
      "id": {
        "name": "PPS",
        "value": "0390511T"
      },
      "picture": {
        "large": "https://randomuser.me/api/portraits/men/75.jpg",
        "medium": "https://randomuser.me/api/portraits/med/men/75.jpg",
        "thumbnail": "https://randomuser.me/api/portraits/thumb/men/75.jpg"
      },
      "nat": "IE"
    }
  ],
  "info": {
    "seed": "fea8be3e64777240",
    "results": 1,
    "page": 1,
    "version": "1.3"
  }
}

That is a lot of data. Let's say that we only need the gender, email, and the cell from the returned data. We can use object destructuring on the returned data and extract only what we need.

async function randomProfile() {
  const response = await fetch("https://randomuser.me/api/");
  const data = await response.json();
  const { cell, email, gender } = data.results[0];

  console.log(cell, email, gender);
}

randomProfile();

Let's take this a step further and extract the first and last name from the data. Take some time to look at how the data given to us by the API is structured. Note that there is another object inside of our results[0] object called name which in turn has the keys first and last for the first and last name. To extract data from a nested object like this, we have to tell the JavaScript engine that we're looking for a nested object.

async function randomProfile() {
  const response = await fetch("https://randomuser.me/api/");
  const data = await response.json();
  const { cell, email, gender, name: { first, last } } = data.results[0];

  console.log(cell, email, gender, first, last);
}

randomProfile();

We added this part to our destructuring assignment: name: { first, last }. By adding this, we're basically telling the JavaScript engine to look for an object within the current object called name and extract the values of the keys first and last. Notice that in the end the declared variables are first and last and not name.first and name.last.

async function randomProfile() {
  const response = await fetch("https://randomuser.me/api/");
  const data = await response.json();
  const { cell, email, gender, name: { first: firstName, last: lastName } } = data.results[0];

  console.log(cell, email, gender, firstName, lastName);
}

randomProfile();

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

Template Literals

therealnrf — Tue, 05 Oct 2021 17:12:52 +0000

This first installment of the series focuses on syntax-related topics and is called JavaScript You Must Know -- Essential Syntax.

JavaScript used to have two ways of writing a string: using single quotes or using double quotes. With template literals, we now have a third way: using backticks. Looks something like this:

let myBelovedString = `A dance under the moonlight.`;

Once again, those are backticks and not single quotes.

So why introduce another way of writing strings? Well, to give us, the programmers, access to the following features:

Easier string formatting
String interpolation
Tagged templates

Let's go over those features one by one.

Easier String Formatting

Writing multi-line strings in JavaScript, if you're using single or double quoted strings, requires the use of special characters such as \n (new line) or \t (tab). An example.

let myBelovedString = "'tis nothing...\nbut a scratch";

/**
 * can't do the following as it will generate an error
 *
 * let myBelovedString = "'tis nothing...
 * but a scratch";
 *
 **/

console.log(myBelovedString);

[console output]:
'tis nothing...
but a scratch

As the comment in the code example above says, if we'd simply pressed the enter key at the end of the first line (expecting a new line in the output) and had continued with our string, it would actually generate an error. The reason is that the newline character that is inserted by pressing the enter key is not interpreted as part of the string by the JavaScript engine. As a result, the engine thinks that the newline charater is part of the code instead of the string and assumes that it indicates the end of the JavaScript statement.

When using template literals on the other hand, the newline character is considered part of the string. In fact, all whitespace characters (spaces, tabs, newline) are interpreted as part of the string. As a result, multi-line strings become much easier to format. All this means is that string formatting just became a whole lot easier and can be done without the use of special escape characters such as \n. The example above would become:

let myBelovedString = `'tis nothing...
but a scratch`;

console.log(myBelovedString);

[console output]:
'tis nothing...
but a scratch
💡 just a tip

If we try to do something like this:
let myBelovedString = `
'tis nothing...
but a scratch`;
It will introduce a blank line at the start which isn't exactly desirable. But we can use the trim() function to get rid of the newline character at the beginning of the string:
let myBelovedString = `
'tis nothing...
but a scratch`.trim();

String Interpolation

Definitely one of the best features added to JavaScript. String interpolation allows us to put any valid JavaScript expression inside our template string and it will be evaluated during runtime. The concept itself is, of course, not new. It was just done differently before: using concatenation. Let's first look at the old-school way of doing things.

const myName = "Plump Sunny";
console.log("Hi, my name is " + myName + "."); // output: "Hi, my name is Plump Sunny."

Leveraging string interpolation when using template literals, the same result can be achieved as follows:

const myName = "Plump Sunny";
console.log(`Hi, my name is ${myName}.`); // output: "Hi, my name is Plump Sunny."

Simple, readable, elegant, with no +s all over the place. As you may have noticed, we have to tell the JavaScript engine which part of the string needs to be interpolated. This is done by using this syntax: ${your JS expression goes here}. Any valid JavaScript expression can be put inside the curly braces. The expression will be evaluated and the result will be part of the string. This includes arithmetic expressions and function calls.

function publicServiceMessage() {
  return "Exercise is good.";
}

const js = {
  fullName: "JavaScript",
  yearCreated: 1995
};

const message = `
Today's PSA: ${publicServiceMessage()}
Fun fact: ${js.fullName} was created in the year ${js.yearCreated}.`.trim();

console.log(message);

[console log]:

"Today's PSA: Exercise is good.
Fun fact: JavaScript was created in the year 1995."

Note how straightforward it was to format our final multi-line message using template literals.

Two final points to remember:

If you wish to output backticks in your string, just escape them with a backslash.
String interpolation expects a JavaScript expression inside the curly braces. This means that JavaScript statements, such as if, for, etc., will not work. And since the ternary operator defines a JavaScript expression, it can be used instead of an if statement.

Tagged Template Literals

Let's revisit a simple template literal.

let aSimpleTemplateLiteral = `A simple template literal, this is.`;

Another feature that is available to template literals (or template strings) is the ability to tag them. Resulting in tagged template literals. It looks like this:

let aTaggedTemplateLiteral = capitalize`A tagged template literal, this is.`;

A tag (capitalize) has been added just before the first backtick of our template literal resulting in a tagged template literal. By tagging it like this we're telling the JavaScript engine to do the following:

call a function named capitalize
pass the string between the backticks to this function (in a pre-defined way)

The value returned by capitalize() will be assigned to the variable aTaggedTemplateLiteral. So basically, we've introduced a pre-processing step where we can manipulate the string however we like before it is assigned to the variable.

I'd like to emphasize here that a tag is simply a function call and anything returned by that function is assigned to the variable.

function capitalize() {
  return "Sticks and stones my friend.";
}

let myFinalString = capitalize`This string doesn't really matter right now.`;

console.log(myFinalString); // output: "Sticks and stones my friend."

We didn't even bother to receive the arguments passed to capitalize() (because we haven't covered that topic yet). We have simply returned a string which was eventually assigned to myFinalString.

Now, before we discuss how the string is passed to the pre-processing function, we need to introduce some expressions in the string. As always, we will start with a simple example.

function capitalize(strings, name, age) {
  return "Not doing anything yet.";
}

const myName = "Plump Sunny";
const myAge = 32;

let myFinalString = capitalize`Hi, my name is ${myName} and I'm ${myAge}.`;

console.log(myFinalString); // output: "Not doing anything yet."

Now, finally, let's see how the string between the backticks is passed to the function (capitalize() in this case):

Before passing anything to capitalize(), the string will be broken down. It will be broken down into plain text tokens and expressions (as you might remember, the dollar and curly braces syntax can accept any JavaScript expression). For our example, this break down would look something like this:

text_token_1: "Hi, my name is "
expression_1: myName
text_token_2: " and I'm "
expression_2: myAge
text_token_3: "."

Next, an array will be created with just the plain text tokens, while maintaining the order that they appear in the original string. This array of plain text tokens will be passed as the first argument to capitalize(). In our example, looking at the function declaration of capitalize(), this array will be passed to strings and will look like this:

["Hi, my name is ", " and I'm ", "."]

Lastly, the expressions in the original string will be evaluated (in the order that they appear in the string) and passed to the function as individual arguments. In our example, name will receive the value of myName and age will receive the value of myAge.

We now have the ability to manipulate the string however we see fit. To keep it simple at first, we will simply return the same string but with the name in all caps.

function capitalize(strings, name, age) {
  return `${string[0]}${name.toUpperCase()}${strings[1]}${age}${strings[2]}`;
}

const myName = "Plump Sunny";
const myAge = 32;

let myFinalString = capitalize`Hi, my name is ${myName} and I'm ${myAge}.`;

console.log(myFinalString); // output: "Hi, my name is PLUMP SUNNY and I'm 32."

This doesn't feel right though (actually, it feels all kinds of wrong). Everything is hard coded inside capitalize(). A very common pattern is to use rest parameters combined with tagged templates. Since the expressions inside the original string are passed as individual arguments to the pre-processing function, using rest parameters gives us a convenient array of all the expressions of the original string. This allows us to build our final string programmatically instead of hard coding everything. An example should clear things up.

Let's redefine capitalize() using rest parameters and build our string programmatically.

function capitalize(strings, ...expressions) {
  let finalString = "";

  strings.forEach((token, index) => {
    finalString += `${token}${expressions[index]}`;
  });

  return finalString;
}

const myName = "Plump Sunny";
const myAge = 32;

let myFinalString = capitalize`Hi, my name is ${myName} and I'm ${myAge}.`;

console.log(myFinalString); // output: "Hi, my name is Plump Sunny and I'm 32.undefined"

Much better. But we're not doing anything to the string. We know that the first expression in the string is the name. This means that inside capitalize(), when the index is 0, we will call toUpperCase() to the expression and will return the expression as it is otherwise (we'll deal with the undefined at the end in the next step).

function capitalize(strings, ...expressions) {
  let finalString = "";

  strings.forEach((token, index) => {
    finalString += `${token}${(index == 0) ? expressions[index].toUpperCase() : expression[index]}`;
  });

  return finalString;
}

const myName = "Plump Sunny";
const myAge = 32;

let myFinalString = capitalize`Hi, my name is ${myName} and I'm ${myAge}.`;

console.log(myFinalString); // output: "Hi, my name is PLUMP SUNNY and I'm 32.undefined"

Now let's deal with the undefined at the end of the string. This is because the length of the strings and expressions arrays don't match and when we try to access an index on expressions that doesn't exist it returns undefined. To solve this, consider the following nifty trick:

(expression[index] || "")

The expression above will return expression[index] if it exists and will return an empty string otherwise. Let's plug this is in our capitalize() function.

function capitalize(strings, ...expressions) {
  let finalString = "";

  strings.forEach((token, index) => {
    finalString += `${token}${(index == 0) ? expressions[index].toUpperCase() : (expression[index] || "")}`;
  });

  return finalString;
}

const myName = "Plump Sunny";
const myAge = 32;

let myFinalString = capitalize`Hi, my name is ${myName} and I'm ${myAge}.`;

console.log(myFinalString); // output: "Hi, my name is PLUMP SUNNY and I'm 32."

💡 just a tip

In our example above, the template literal ended on a plain text token (the full stop). But let's say our template literal didn't have that full stop at the end and ended on an expression as a result.
let myFinalString = capitalize`Hi, my name is ${myName} and I'm ${myAge}`;
In this case, when we break the template literal down into plain text tokens and expressions, it comes out to two of each. So one might think that the strings array in this case will be: ["Hi, my name is ", " and I'm "].

In reality, if a template literal ends on an expression, then the last element in the array of plain text tokens will be an empty string. In our case, the strings array will look like this: `["Hi, my name is ", " and I'm ", ""].

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

Rest and Spread

therealnrf — Tue, 05 Oct 2021 17:10:22 +0000

This first installment of the series focuses on syntax-related topics and is called JavaScript You Must Know -- Essential Syntax.

Among the useful features that have been added to JavaScript is this: ...

That's right, three dots one after the other. These three dots can be used in two ways:

spread operator
rest parameters

Spread Operator

The spread operator, as the name suggests, "spreads out" the items of an iterable (like an array) into individual elements.

const randomNumbers = [2, 9, 17];

console.log(randomNumbers); // output: [2, 9, 17]
console.log(...randomNumbers); // output: 2 9 17

Notice that, when using the spread operator, the output is no longer an array but rather the individual elements of the array.

There is more to be discussed regarding the spread operator and arrays (and objects). But before that, let me just mention here that the spread operator can also be used on strings as well. In the case of a string, using the spread operator will simply return the individual characters of the string.

const randomString = "defiance";

console.log(...randomString); // output: "d" "e" "f" "i" "a" "n" "c" "e"

Now back to arrays (and objects). First things first, the spread operator can't be used on objects without a surrounding context. For example, the following code will generate an error:

const myObj = { a: "hello", b: "world" };

console.log(...myObj); // this will generate an error

The cool thing about the spread operator is that when it is used within the context of an array/object (meaning used inside square brackets or curly braces), it results in a new array/object containing the elements of the original. Examples are in order.

In the code example below, the spread operator is being used within the context of an array (inside square brackets). First a copy of the array randomNumbers is created using the spread operator and then a new array is created using randomNumbers.

const randomNumbers = [2, 9, 17];
const randomNumbersCopy = [...randomNumbers];
const randomNumbersExtended = [-1, ...randomNumbers];

console.log(randomNumbersCopy); // output: [2, 9, 17]
console.log(randomNumbersExtended); // output: [-1, 2, 9, 17]

The spread operator can also be used to combine multiple arrays to create a new array.

const upperBody = ["head", "shoulders"];
const lowerBody = ["knees", "toes"];
const poem = [...upperBody, ...lowerBody];

console.log(poem); // output: ["head", "shoulder", "knees", "toes"]

The same techniques we just saw in the two examples above can also be used for objects.

const obj1 = { a: 1, b: 2 };
const obj2 = { c: 3, d: 4 };

const obj1Copy = {...obj1};
const objCombined = {...obj1, ...obj2};
const obj2Extended = {...obj2, e: 5};

console.log(obj1Copy); // output: { a: 1, b: 2}
console.log(objCombined); // output: { a: 1, b: 2, c: 3, d: 4 }
console.log(obj2Extended); // output: { c: 3, d: 4, e: 5 }

Now considering the example above, what would happen if I did something like this const obj3 = { ...obj1, b: 31415 }? The catch here is that obj1 already has a key called b and duplicates are not allowed. In this case, the resulting object will have the updated value of b.

const obj1 = { a: 1, b: 2 };
const obj3 = { ...obj1, b: 31415 };

console.log(obj3); // output: { a: 1, b: 31415 }

This is a nifty trick to have in your arsenal if you ever wish to update just one of the properties of an object while keeping the rest untouched.

Let's do a relatively practical example. Say we have a function that takes exactly three arguments and returns their average. Also, say we have an array of three numbers and wish to know their average.

function average(a, b, c) {
  return (a + b + c) / 3;
}

const randomNumbers = [3, 5, 7];
/**
 * Instead of this:
 * const avg = average(randomNumbers[0], randomNumbers[1], randomNumbers[2]);
 * we can simply use the spread operator here
 **/
const avg = average(...randomNumbers);

console.log(avg); // output: 5

Another practical example would be the Math.max() method. Math.max() returns the largest number in a list of numbers but does not accept an array as its argument. Rather it expects a list of numbers.

const epicListOfNumbers = [1, 2002, 4, 91, 104, 7];

console.log(Math.max(...epicListOfNumbers)); // output: 2002

Rest Parameters

Rest parameters does the exact opposite of the spread operator i.e. it expects a list of numbers and creates an array out of those numbers.

function uselessFunction(a, b, ...rest) {
  console.log(a);
  console.log(b);
  console.log(rest);
}

uselessFunction("first argument", "second argument", "third", "fourth", "and", "sixth argument");

[console output]:

"first argument"
"second argument"
["third", "fourth", "and", "sixth argument"]

So the parameter a of uselessFunction() receives "first argument" and the parameter b receives "second argument"; nothing new here. But, as can be seen in the console output, all the remaining arguments are received by rest as an array. That only happened because of the ... that precedes the parameter rest (the three dots would be called the rest syntax in this case). If the rest syntax had not been there, then the argument "third" would've been received by the parameter rest and the remaining arguments would've simply been ignored.

function uselessFunction(a, b, rest) {
  console.log(a);
  console.log(b);
  console.log(rest);
}

uselessFunction("first argument", "second argument", "third", "fourth", "and", "sixth argument");

[console output]

"first argument"
"second argument"
"third"

In this way, rest parameters allow us to have an indefinite number of arguments. One point to note here is that the rest parameters give us an actual array. So all the Array methods (like map() and reduce()) are available to us.

❗️important

The rest parameters must be the last in the list of parameters. Both of the following function declarations will raise an error:

function restMustBeLast(a, ...rest, b) { // -- } // error

function restMustBeLast(...rest, a, b) { // == } // error

The correct way to declare this function would be:

function restMustBeLast(a, b, ...rest) { // -- }

Let's revisit the average() function we wrote near the end of the spread operator section and improve it. As we programmed it before, average() took exactly three numbers and gave us their average. That is quite limited. Ideally we should be able to give an arbitrary long list of numbers and be able to get their average.

function average(...numbers) {
  const sumOfNumbers = numbers.reduce((accumulator, currentValue) => (accumulator + currentValue));
  const avgOfNumbers = sumOfNumbers / numbers.length;

  return avgOfNumbers;
}

console.log(average(1, 2, 3, 4, 5)); // output: 3
console.log(average(1, 2, 3, 4, 5, 6)); // output: 3.5
console.log(average(1, 2, 3, 4, 5, 6, 7, 8, 9)); // output: 5

💡just a tip

There is an array-like object called arguments which gives us access to all of the arguments passed to a function (except arrow functions which do not have arguments). An indefinite argument list was handled using this arguments variable before the rest parameters were made available in JavaScript. An important point to remember, though, is that arguments is not an actual array, so the Array methods are not available on it.

In this section we looked at the rest syntax in the context of a function's parameter list. In this context, the correct term to use would be rest parameters. The same syntax can also be used in destructuring too as we will see when we discuss destructuring insha'Allah.

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

The Ternary Operator

therealnrf — Tue, 05 Oct 2021 15:05:37 +0000

This first installment of the series focuses on syntax-related topics and is called JavaScript You Must Know -- Essential Syntax.

The ternary operator is simply a shorthand for an if...else statement. It is used very liberally by JavaScript developers (and developers of other languages that have this operator). These days it is especially common to see the ternary operator being used in React code.

Syntax

The ternary operator is the only operator in JavaScript that takes three operands. Its syntax may take some getting used to but it is actually quite straightforward. Let's take a look. Please note that the parentheses and the angle brackets are not part of the syntax; I'm just using them for readability.

(condition) ? <expression A> : <expression B>

condition: an expression that evaluates to a truthy or a falsey value
expression A: this expression is evaluated/executed if the condition is true
expression B: this expression is evaluated/executed if the condition is false

The equivalent if...else statement for the example above would be:

if (condition) {
  <expression A>
} else {
  <expression B>
}

Let's consider a more realistic(-ish) example. Assume we need a function that takes the current temperature value as its argument and returns a string saying if it is hot outside or not. Using an if...else statement, one might code the function like this:

function tellMeIfItsHotOutside(outsideTempInCelsius) {
  if (outsideTempInCelsius > 30) {
    return "It is kinda hot";
  } else {
    return "Na, not really hot";
  }
}

console.log(tellMeIfItsHotOutside(25)); // output: "Na, not really hot"
console.log(tellMeIfItsHotOutside(31)); // output: "It is kinda hot"

Now, if we use the ternary operator instead of the if...else statement inside the tellMeIfItsHotOutside() function, it would look like this:

function tellMeIfItsHotOutside(outsideTempInCelsius) {
  return (outsideTempInCelsius > 30) ? "It is kinda hot" : "Not really hot";
}

console.log(tellMeIfItsHotOutside(25)); // output: "Na, not really hot"
console.log(tellMeIfItsHotOutside(31)); // output: "It is kinda hot"

Looking at the examples above, I'd say that both are equally readable but the ternary operator is much more concise.

Nested Ternary Operator

The ternary operator can also be nested. For example, if you have an if...else statement like this:

if (firstCondition) {
  <expression A>
} else if (secondCondition) {
  <expression B>
} else {
  <expression C>
}

You can replace it using the ternary operator:

(firstCondition) ? <expression A> :
  ((secondCondition) ? <expression B> : <expression C>);

We've basically just replaced <expression B> with another conditional statement that uses the ternary operator. The same can be done with <expression A> as well. Remember, <expression A> and <expression B> (considering the first ternary example) can be any valid JavaScript expressions. This includes arithmetic and logical expressions, function calls, and more ternary expressions.

Let's apply all of this to our outside temperature example and say that our tellMeIfItsHotOutside() function is a tad more specific and follows the following logic:

If the outside temperature is more than 40 degrees, return "Very hot; stay in"
If the outside temperature is between 30 and 40 degrees, return "Yeah, it is hot"
If the outside temperature is between 25 and 30 degrees, return "Kinda hot, but not too much"
If the outside temperature is 25 degrees or less, return "It's actually really nice out"

First, let's do the if...else version.

function tellMeIfItsHotOutside(outsideTempInCelsius) {
  if (outsideTempInCelsius > 40) {
    return "Very hot; stay in";
  } else if (outsideTempInCelsius > 30) {
    return "Yeah, it is hot";
  } else if (outsideTempInCelsius > 25) {
    return "Kinda hot, but not too much";
  } else {
    return "It's actually really nice out";
  }
}

console.log(tellMeIfItsHotOutside(41)); // output: Very hot, stay in
console.log(tellMeIfItsHotOutside(32)); // output: Yeah, it is hot
console.log(tellMeIfItsHotOutside(26)); // output: Kinda hot, but not too much
console.log(tellMeIfItsHotOutside(22)); // output: It's actually really nice out

Now let's see what the same function would look like if we had used the ternary operator.

function tellMeIfItsHotOutside(outsideTempInCelsius) {
  return (
    (outsideTempInCelsius > 40) ? "Very hot; stay in" :
      (outsideTempInCelsius > 30) ? "Yeah, it is hot" :
        (outsideTempInCelsius > 25) ? "Kinda hot, but not too much" : "It's actually really nice out"
  );
}

console.log(tellMeIfItsHotOutside(41)); // output: Very hot, stay in
console.log(tellMeIfItsHotOutside(32)); // output: Yeah, it is hot
console.log(tellMeIfItsHotOutside(26)); // output: Kinda hot, but not too much
console.log(tellMeIfItsHotOutside(22)); // output: It's actually really nice out

If you're not already used to the syntax of the ternary operator then I'd highly recommend doing this example on your own so the syntax sinks in nicely. Note that I've used indents and line breaks to make the syntax more readable. In my opinion the ternary version is much more readable in this case. Some of you may find the if...else version more readable. The important thing is to have code-readability as a priority. Always take some time to think which version will be easier to read and follow. Because that is the version that will be easier to debug, refactor, expand, and all that jazz.

👉🏻 Subscribe to my newsletter: click here

👉🏻 Follow me on twitter: click here

Re-rendering in React

therealnrf — Sat, 02 Oct 2021 23:15:06 +0000

I recently saw the following tweet from @_georgemoller which posed an interesting question related to component re-rendering in React:

// Detect dark theme var iframe = document.getElementById('tweet-1443556666792988672-847'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1443556666792988672&theme=dark" }

The problem is interesting because, while <SomeComponent /> is a child component of <App />, <SomeComponent /> does not depend on count in any way. It does not receive count as a prop (in fact, <SomeComponent /> doesn't receive any props) and, as a result, is not affected by count's change in value.

So will <SomeComponent /> be re-rendered every time the value of count is updated?

Testing environment

For testing, I simply created a new project using create-react-app. After that I proceeded to delete all the extra stuff not needed for this exercise and put the code in App.js.

App.js

Verifying a re-render

To get to our answer we need a way to verify whether a component was re-rendered or not. The easiest way to do this would be to use the React Developer Tools. These developer tools are available for all major browsers as an extension (except Safari I think).

After installing the developer tools, right-click anywhere on the page and click Inspect.

Look for Components and open it.

This tool shows us all the components in our React application and their relation to each other (children are indented under their parent component). Clicking on a component shows more detail like the values of its state and props.

Click on the settings icon and enable the setting called Highlight updates when components render.

As the name suggests, enabling this setting means that any component that is rendered/re-rendered will be highlighted.

Time to test

This is it. Time to press the button. If <SomeComponent /> is highlighted, it means that <SomeComponent /> is being re-rendered every time count is being updated.

Interesting! Not only <SomeComponent /> is re-rendered every time the state changes but the text displaying count's value and and the <button /> are also re-rendered.

Every time the state of a component changes, that component and all of its children are re-rendered.

Just to drive this point home, and emphasize the fact that it does not matter where the value of count is actually displayed, let's consider some additional scenarios.

Scenario-1

In this scenario, we will pass the value of count to <SomeComponent /> and display it from within <SomeComponent />. If count is then updated, the only changing entity is being displayed from within <SomeComponent />.

App.js

I had to introduce a couple of <p> tags just to keep everything neat.

Now, practically speaking, the only thing updating the display every time the increment button is pressed is inside <SomeComponent /> on line 20. So how will React handle the re-render?

Once again all components are being re-rendered. We basically have two child components of <App /> (<SomeComponent /> and <button />) and both of them are clearly being re-rendered. This reinforces the point that:

Every time the state of a component changes, that component and all of its children are re-rendered.

Since the state of count belongs to <App />, every time count changes, <App /> and all of its child components are re-rendered (and the children of those child components as well; I hope that was clear!).

This brings us to the second scenario.

Scenario-2

Since we now know that it makes no difference, let's display the value of count from within <App /> instead of <SomeComponent /> (just like in the original code). Additionally, I've created a bunch of components just to create a hierarchy.

App.js

By now it should be crystal clear as to what will happen when we change count.

Scenario-3

For our last scenario, we'll take the code from scenario-2 and move the state from <App /> to <AnotherChildOfSomeComponent />. And since the data flow in React is from parent to child, and not the other way around, we will display (and update) the value of count from within <AnotherChildOfSomeComponent /> as well (this makes sense since the whole goal of this exercise is to make count a part of <AnotherChildOfSomeComponent />'s state).

Time to change count and see React's rendering in action.

As can be seen, React only re-renders <AnotherChildOfSomeComponent /> and leaves the rest alone.

Conclusion

Kindly allow me to say it again...

Every time the state of a component changes, that component and all of its children are re-rendered.

Be very mindful of which component handles the state in a React application. If you put it in the root component (like in the original problem), your whole application will re-render every time that state changes. This can have a serious impact on your application's performance.

For example, imagine a bunch of data-driven child components that query various APIs. Every time those components are rendered they'll hit those APIs. Now that might be something you intend, but it just might be a side-effect of keeping state in the wrong component.

DEV Community: therealnrf

My Course: Boost Your Confidence in Vanilla JS

What is covered?

Who is this book for?

Explicit is better than tricks

The double bang !! (logical NOT)

The unary + operator

The magic numbers

Conclusion

React.memo() is your friend

Why memoize?

React.memo() to the rescue

Stop using arrow functions everywhere ...

Do not use arrow functions ...

... when defining object methods

... when defining prototype methods

... when defining any function that depends on the dynamic context

... when defining a constructor function

... if you wish to use the special arguments object

It's not all bad

Async callbacks

Callbacks for iterator functions

In my humble opinion ...

Arrow Functions

Cases for function's parameter list

Case 1: no parameters

Case 2: Multiple parameters

Case 3: Special case of exactly ONE parameter

Cases for function's body

Case 1: Multi-line body

Case 2: Special case of SINGLE-LINE body

More than just syntax

Destructuring

Array Destructuring

Left hand side has more variables

Right hand side has more variables

Object Destructuring

Use in function parameters

Use in APIs

Template Literals

Easier String Formatting

String Interpolation

Tagged Template Literals

Rest and Spread

Spread Operator

Rest Parameters

The Ternary Operator

Syntax

Nested Ternary Operator

Re-rendering in React

Testing environment

Verifying a re-render

Time to test

Scenario-1

Scenario-2

Scenario-3

Conclusion

Follow me on twitter: @therealnrf

... if you wish to use the special `arguments` object