DEV Community: Ioana Tiplea

Core JavaScript: Scope

Ioana Tiplea — Thu, 12 Jan 2023 08:04:13 +0000

About the series

Core JavaScript is a series I'm writing that covers, as the name suggests, some of the core principles of JavaScript. It originally started as a study or reference material for myself, but I decided to share it with the community in the hopes that it will prove useful for others.

This series is intended for beginner JavaScript developers or more experienced developers in need of a refresher. I have a few topics planned out already, but I would love to hear from you if there are any topics, in particular, you would be interested to read about!

You might recall that in a previous article, we came across the concept of scope in JavaScript. In short, scope represents the section of code in which a variable is accessible. There are a few different types of scope in JavaScript:

Global scope
Module scope
Function scope
Block scope

Let's go through each of them to see how they work.

Global scope

The global scope exists outside of any functions. Variables declared in the global scope are called global variables, and they can be accessed anywhere in the code.

const name = 'Jane'; // Global variable, in global scope

function greet() {
    console.log(`Hello, ${name}!`); // Hello, Jane!
}

Note: If you assign a value to a variable that has not yet been declared, it automatically becomes a global variable, unless you are using strict mode.

function greet() {
    name = 'Jane';
    console.log(`Hello, ${name}!`); // Hello, Jane!
}

Module scope

With the introduction of modules in ES2015 also came the concept of module scope. Consider the following module, greeting:

// greeting.js

const name = 'John';

console.log(`Hello, ${name}!`);

Let's import the module into a different file and try to access name:

import '../greeting.js'

console.log(name);

This will throw an error, because name is not accessible outside its module, greeting, unless it is exported.

Function scope

In JavaScript, each function creates its own scope. Variables declared within a function scope are called local variables, and they can only be accessed within the function they have been declared in.

function greet() {
    const name = 'John'; // Local variable, in function scope

    console.log(`Hello, ${name}!`);
}

greet(); // Hello, John!
console.log(name); // ReferenceError: name is not defined

Block scope

Block scope is the scope that exists within a pair of curly brackets { }. Variables declared within a block scope are only accessible within that scope.

if (true) {
    const name = 'John'; // Block-scoped variable

    console.log(`Hello, ${name}!`); // Hello, John!
}

console.log(name); // ReferenceError: name is not defined

Note: var variables behave differently in this scenario - they are not block scoped! var variables can be accessed outside of the block scope (but not outside of the function scope!).

if (true) {
    var name = 'John'; // Block-scoped variable

    console.log(`Hello, ${name}!`); // Hello, John!
}

console.log(name); // John

Scope nesting

In JavaScript, scopes can be nested, meaning that a scope can exist inside another scope.

function greet() {
    // Function scope of the greet function
    const name = 'John';

    if (name === 'John') {
        // Block scope of the if-statement
        const greeting = 'Hello';
        console.log(`${greeting}, ${name}!`); // Hello, John!
    }

    console.log(greeting); // ReferenceError: greeting is not defined
}

The scope of the greet function is called the outer scope, and the scope of the if statement is called the inner scope. The important takeaway here is that variables declared in the outer scope can be accessed in the inner scope, but variables declared in the inner scope cannot be accessed in the outer scope.

Scope chain

Whenever you try to access a variable within your code, the search process begins from the local scope of the function you are calling. If the variable does not exist in the local scope, the search moves on to the outer scope (e.g. the scope of a parent function) until it reaches the outermost scope of the code - the global scope. This path that the code goes down in order to find the variable is known as the scope chain. If the variable is not found anywhere along the way, you will get a ReferenceError.

Practice

What are the outputs of these code snippets?

   function greet() {
       let name = 'John';
       console.log(`Hello, ${name}!`)
   }

   name = 'Jane';
   greet();
   console.log(`Hello, ${name}!`);

Answer:

   Hello, John!
   Hello, Jane!

Reason: The name inside of the greet function is a local variable, so it cannot be changed from outside of the function. name = 'Jane'; essentially creates a new global variable.

   let name = 'John';

   if (true) {
     let name = 'Jane';
   }

   console.log(name);

Answer:

   John

Reason: The name variable with the value Jane is created within the block scope of the if statement. Therefore, it cannot be accessed from the global scope. Instead, name will have the value given to it in the global scope, which is John.

   let name = 'John';

   if (true) {
     var name = 'Jane';
   }

   console.log(name);

Answer:

   SyntaxError: Identifier 'name' has already been declared

Reason: var does not follow the same rules as let and const - its declaration will be global despite being placed inside of the if block. Therefore, the code will throw an error as name has already been declared in the global scope.

Thank you for reading this article in my Core JavaScript series! If you found this useful, if you have anything to add, or if I made any mistakes - I would love to hear from you! I'm also very open to suggestions for future topics for the series. 😊

Expect to see the next part soon. Thanks and see you there!

Core JavaScript: Hoisting

Ioana Tiplea — Wed, 28 Dec 2022 10:55:21 +0000

About the series

You might recall that in a previous article we came across the concept of hoisting in JavaScript. Essentially, hoisting is the process through which the declaration of a variable or function is moved to the top of its scope. It allows us to use variables and call functions before they appear in our code.

Declaration vs Assignment / Initialization

It is important to note that only declarations are hoisted, and initializations and assignments are not. Below is the difference, in case you need a refresher.

let number; // Declaration
number = 5; // Assignment
const name = 'John'; // Initialization

Consider the following examples:

var first = 1;
var second = 2;

console.log(first + " " + second); // Output: 1 2

var first = 1;

console.log(first + " " + second) // Output: 1 undefined

var second = 2;

Because declarations are hoisted to the top of the scope but initializations are not, the second example essentially gets translated to the following:

var first = 1;
var second; // This is currently undefined

console.log(first + " " + second) // Output: 1 undefined

second = 2;

Var vs Let vs Const

If you've read my previous article about variable types, you know that var variables are hoisted to the top of their scope and initialized with the value of undefined. Some consider let and const to be non-hoisted, which is not entirely correct. In reality, let and const variables are indeed hoisted to the top of their scope, but they are not initialized.

This means that with var we can do something like this:

console.log(number); // undefined
var number = 5;

However, trying to do the same thing with let or const will throw an error:

console.log(number); // ReferenceError: number is not defined
let number = 5;

Functions

Hoisting works the same for functions as it does for variables - function declarations are hoisted, but function expressions are not.

hoistedFunction(); 

function hoistedFunction() { // Function declaration
  console.log('This will work!');
}

// Output: This will work!

nonHoistedFunction();

let nonHoistedFunction = () => { // Function expression
    console.log('This will not work...');
}

// Output: ReferenceError: nonHoistedFunction is not defined

If we use var instead of let, we still get an error, but of a different kind.

nonHoistedFunction();

var nonHoistedFunction = () => { // Function expression
    console.log('This will still not work...');
}

// Output: TypeError: nonHoistedFunction is not a function

Tip - Declare variables at the top

Hoisting is easy to forget about or overlook, which tends to lead to bugs and confusion. Declaring variables at the top of their scope helps you avoid errors and it keeps your code clean.

Practice

What are the outputs of these code snippets?

   example();

   function example() {
     let name = 'Bon Jovi';
     console.log(name);
   }

Answer:

   Bon Jovi

Reason: example() is a function declaration, which is hoisted - therefore, it can be called before it appears in our code and everything will work as intended.

   example();

   function example() {
     console.log(name);
     let name = 'Bon Jovi';
   }

Answer:

   ReferenceError: Cannot access 'name' before initialization

Reason: let variables, despite being hoisted to the top of their scope, are not initialized. Therefore, we are warned that we cannot use name before it is initialized.

   example();

   let example = () => {
     let name;
     console.log(name);
     name = 'Bon Jovi';
   }

Answer:

   ReferenceError: example is not defined

Reason: Function expressions are not hoisted, therefore we cannot use them before they appear in the code. Because we are using let here, we get a ReferenceError.

Thank you for reading the third article in my Core JavaScript series! If you found this useful, if you have anything to add, or if I made any mistakes - I would love to hear from you! I'm also very open to suggestions for future topics for the series. 😊

Expect to see the next part soon. Thanks and see you there!

Core JavaScript: Var vs. Let vs. Const

Ioana Tiplea — Wed, 07 Sep 2022 11:24:29 +0000

About the series

Core JavaScript is a series I'm writing that covers, as the name suggests, some of the core principles of JavaScript. It originally started as study or reference material for myself, but I decided to share it with the community in the hopes that it will prove useful for others.

This series is intended for beginner JavaScript developers, or more experienced developers in need of a refresher. I have a few topics planned out already, but I would love to hear from you if there are any topics in particular you would be interested to read about!

In this article, I will go over the different ways of declaring variables in JavaScript, their characteristics (redeclarability, reassignability, scope and hoisting), and when to use which. At the end there will be a few exercises to practice the concepts I talked about.

Below is a quick summary of the main characteristics of each variable declaration:

	Redeclarable	Reassignable	Scope	Hoisting
var	✔	✔	global / function	hoisted, initialized
let	❌	✔	block	hoisted, not initialized
const	❌	❌	block	hoisted, not initialized

Var

Before ES6, var was the only option for declaring variables in JavaScript, but it came with a few problems. For example, var variables can be redeclared, which means that doing something like this is perfectly valid:

var name = 'Steve';
var name = 'Chris';

This is not an issue if you're doing it intentionally. The problem arises when you may not be aware that a certain variable has been declared already. This can lead to unexpected outputs, errors, bugs and headaches.

Another characteristic of var variables is that they can be reassigned, which means you can freely change their value after they've been declared.

var age = 28;
age = 30;

In terms of scope, var variables are either in the global scope (if they have been declared outside of a function) or in the function scope (if they have been declared inside of a function). We will talk more about scope in a future article, but if you would like to learn more about it now, check out this article on MDN.

var yellowFruit = 'banana'; // outside of function -> global scope

function f() {
  var redFruit = 'strawberry'; // inside of function -> function scope
}

console.log(redFruit); // ReferenceError: redFruit is not defined, because redFruit is not in the global scope

In terms of hoisting, var variables are hoisted to the top of their scope and initialized with the value of undefined. We will talk more about hoisting in a future article, but if you would like to learn more about it now, check out this article on MDN.

// What we write
console.log(favoriteSeason);
var favoriteSeason = 'spring';

// How it's interpreted
var favoriteSeason;
console.log(favoriteSeason);
favoriteSeason = 'spring';

Let

let solves one of the major issues that come with var: let variables are not redeclarable in the same scope (more on this later). You don't have to worry about accidentally creating bugs in your code by redeclaring a variable that has already been declared. Doing this for example is not allowed:

let name = 'Steve';
let name = 'Chris'; // SyntaxError: Identifier 'name' has already been declared

Just like var, let variables can also be reassigned.

let age = 28;
age = 30;

In terms of scope, let variables are block scoped. A block is any code written between a pair of curly brackets { }. Remember how let variables are not redeclarable in the same scope ? They are, however, redeclarable if they are in different scopes, as illustrated below.

let yellowFruit = 'banana';

if (true) {
  let yellowFruit = 'lemon';
  console.log(yellowFruit); // lemon
}

console.log(yellowFruit); // banana

In terms of hoisting, let variables are hoisted to the top of their scope, but they are not initialized. This means that you cannot use let variables before declaring them.

console.log(favoriteSeason);
let favoriteSeason = 'spring';  // ReferenceError: favoriteSeason is not defined

Const

Just like let, const variables can also not be redeclared.

const name = 'Steve';
const name = 'Chris';  // SyntaxError: Identifier 'name' has already been declared

Unlike both var and let, const variables can not be reassigned.

const age = 28;
age = 30;  // TypeError: Assignment to constant variable.

When it comes to Objects declared with const - the Object itself cannot be reassigned, but the individual properties within the Object can be.

const student = {
  name: 'Alice',
  age: 16
}

student.name = 'Kelly';  // works fine

student = {
  name: 'Susan',  // TypeError: Assignment to constant variable.
  age: 15
}

Just like let, const variables are block scoped.

const yellowFruit = 'banana';

if (true) {
  const yellowFruit = 'lemon';
  console.log(yellowFruit); // lemon
}

console.log(yellowFruit); // banana

Just like let, const variables are hoisted to the top of their scope, but they are not initialized.

console.log(favoriteSeason);
const favoriteSeason = 'spring'; // ReferenceError: favoriteSeason is not defined

When to Use Which?

For let and const, there are two main approaches regarding when to use which:

Use let by default, switch to const when you need a variable to remain constant.
Use const by default, switch to let when you need a variable to be reassignable.

What about var? The general consensus among JavaScript developers is that in modern JavaScript YOU SHOULD NEVER USE VAR, under any circumstances. var is simply worse compared to let and const, and there is no good reason to ever use it. Also, there's a chance your tech lead will hunt you down if they see var in your pull requests. 😄

Practice

What are the outputs of these code snippets?

   if (true) {
     var year = 2022;
     let model = 'Golf';
   }

   console.log(year)
   console.log(model)

Answer:

   2022
   ReferenceError: model is not defined

Reason: model is declared using let, which means its scope is restricted to the code block of the if statement. Trying to access it outside of its scope will cause an error. year is declared using var, which is not block scoped and therefore can be accessed outside of the if statement.

   for (var i = 0; i < 3; i++) {
     console.log('Looping...')
   }

   console.log(i);

Answer:

   Looping...
   Looping...
   Looping...
   3

Reason: In this case var is declared globally, therefore i is accessible outside of the for loop.

   for (let i = 0; i < 3; i++) {
     console.log('Looping...')
   }

   console.log(i);

Answer:

   Looping...
   Looping...
   Looping...
   Uncaught ReferenceError: i is not defined

Reason: Because let is block scoped, i is restricted to the for loop and cannot be accessed outside of it.

Thank you for reading the second article in my Core JavaScript series! If you found this useful, if you have anything to add, or if I made any mistakes - I would love to hear from you! I'm also very open to suggestions for future topics for the series. 😊

Expect to see the next part soon. Thanks and see you there!

Core JavaScript: Primitive vs. Non-primitive Data Types

Ioana Tiplea — Thu, 25 Aug 2022 13:00:01 +0000

About the series

In this article I will first go over the data types in JavaScript, after which I will talk about the differences between them, and I will end with a few exercises to practice the concepts I talked about.

Data Types in JavaScript

Currently there are eight data types in JavaScript, which are divided into two categories: primitive and non-primitive.

Primitive	Non-primitive
Number BigInt String Boolean Null Undefined Symbol	Object

Number

The number data type represents a positive or negative numeric value, which can be an integer or a float containing a decimal point or written using exponential notation. Read more.

const integer = 2;
const float = 2.25;
const positiveExponent = 2.25e+7; // 22,500,000
const negativeExponent = 2.25e-7; // 0.000000225

BigInt

Number is "limited" to storing numeric values between -(2^53 − 1) and 2^53 − 1. If we need to use values that are outside of this range, we can use BigInt. They are declared by adding an "n" at the end of the numeric value. Read more.

const reallyHighValue = 18014398509481982n;
const reallyLowValue = -18014398509481982n;

String

Strings are used to store text. They are declared between quotation marks, which can be single quotes (' '), double quotes (" "), or backticks (` `). Single and double quotes are mostly interchangeable, whereas backticks allow you to insert variables into your strings. Read more.

const singleQuotes = 'Hello';
const doubleQuotes = "World";

const name = 'John Doe';
const greeting = `Hello, ${name}!` // 'Hello, John Doe!'

Boolean

Booleans allow you to add logic to your application. Their value can be either true or false. Read more.

const isOpen = true;
const hasValue = false;

Null

Null expresses a lack of value. In other words, if a variable that is null, we know that it exists, but it is an empty variable. Read more.

const value = null;

Undefined

Undefined represents a variable that has been declared but not assigned a value. Read more.

const value;
console.log(value); // undefined

Symbol

A symbol is a unique and immutable value. It can be used as the key of an Object property. Read more.

const mySymbol = Symbol('Some Value');

const name = Symbol();
const age = Symbol();
const student = {
  [name]: 'Mark Twain',
  [age]: 21
}

Object

Objects allow us to store more complex data in the form of key-value pairs called properties. If a property of an Object is a function, it is called a method. Arrays and functions are also Objects in JavaScript. Read more.

const apple = {
  count: 5,
  color: ['red', 'green'],
  taste: 'sweet',
  fresh: true,
  describe : function() {
  return 'I\'ve got ' + this.count + ' ' + this.taste + ' apples.'; // I've got 5 sweet apples.
  }
}

Differences Between Primitive and Non-Primitive Data Types

There are three main differences between primitive and non-primitive data types, and they are all rather closely related.

Stored as Value vs. Stored as Reference

The core difference between primitive and non-primitive data types in JavaScript is the way they are stored in memory: primitives are stored as a value in memory, whereas non-primitives are stored as a reference to an address in memory. This will become relevant shortly.

const a = 'John';       // a refers to a *value* in memory.
const b = {             // b refers to an *address* in memory.
  firstName: 'John',
  lastName: 'Doe'
}

Compared by Value vs. Compared by Reference

Much like the way they are stored in memory, primitives are compared by value, whereas non-primitives are compared by reference. To understand the difference, consider these examples:

let a = 1;
let b = a; 
a === b;  // true

let a = 1;
let b = 1;
a === b;  // true

At first glance, this behavior seems obvious. But compare it to the behavior of non-primitives:

// Case 1
let a = { x: 1, y: 2 };
let b = a;
a === b;  // true

// Case 2
let a = { x: 1, y: 2 };
let b = { x: 1, y: 2 };
a === b;  // false

In the first case, a and b share the same values and they point to location in memory, therefore === will return true. In the second example, === returns false because even though a and b have the same values, they point to different locations in memory.

Mutable vs. Immutable

Primitive values are immutable. They can be reassigned to a new value, but you can't modify an already existing value. For example, you can't directly change a letter of a string.

let string = 'Modify me!';
string = 'Modified string.'; // works fine
string[0] = 'Z';  // does nothing

Non-primitive values are mutable - we can modify already existing values as we please.

let students = ['Alex', 'Stacy', 'Angela'];
students[0] = 'John';  // works fine

Practice

What are the outputs of these code snippets?

   let a = 1;
   let b = 2;
   b = 3;

   console.log(a);
   console.log(b);

Answer:

 1
 3

Reason: Primitive values are independent - a and b are stored in different locations in memory. Therefore, modifying one does not affect the other.

   let a = 'Who you gonna call?';
   let b = a;
   b = 'Ghostbusters!';

   console.log(a);
   console.log(b);

Answer:

 Who you gonna call?
 Ghostbusters!

Reason: Same as exercise 1.

   let a = { favoriteColor: 'red' };
   let b = a;
   a.favoriteColor = 'green';

   console.log(b.favoriteColor);

Answer:

 green

Reason: Non-primitive values are stored as references to addresses in memory. Therefore, a and b share the same address, which means that changing one will also affect the other.

Thank you for reading the very first article in my Core JavaScript series! If you found this useful, if you have anything to add, or if I made any mistakes - I would love to hear from you! I'm also very open to suggestions for future topics for the series. 😊

Expect to see the second part soon. Thanks and see you there!

Do's and Don'ts of Creating Your Portfolio Website

Ioana Tiplea — Sun, 21 Aug 2022 05:43:00 +0000

A portfolio website is something most developers will attempt to build at some point in their careers. It can be a great tool for finding customers, getting hired, and showcasing your work, technical skills and know-how.

Many developers create stunning portfolio websites, some of which even end up going viral. However, others create portfolio websites that end up being more of a hindrance than an advantage. Below are some Do's and Don'ts that will hopefully help you build a better portfolio website.

DO plan ahead

A failure to plan is a plan to fail. Before you even think about opening your code editor, you need to have a clear plan. Visualize what you want your website to look like. What color scheme and font will you use? What sections do you want to include? How will you describe yourself and your work? What kind of images will you need, if any?

After you answer all of these questions, open a new Figma or Adobe XD design file, or whatever your preferred design tool is, or simply grab a pen and paper. Start sketching out the image you've created in your head. Play around with the design until you're happy with what you see.

Only at this point should you start coding. Now it will be much faster to translate your design into code, and you'll find yourself going back and forth much less than if you had dived straight into coding.

DO have a clean and consistent design

Many portfolio websites come with brash colors, inconsistent spacing and font sizes, or are simply messy and unorganized. Unless you're into brutalist design, this is not something you want.

While you're in the planning phase, do some research about what constitutes good design. Find a good combination of colors and stick to it. Set some typography and spacing rules for yourself and follow them religiously.

One way to make this easier for yourself is to use a CSS framework or library, such as Tailwind CSS, Material UI, Bootstrap and so on. These tools will already have design systems pre-implemented, and they follow patterns that are tried and true.

DO include the names of your skills

Sure, you and other developers might be aware that a light blue atom symbol stands for React.js, or that a single green leaf stands for MongoDB. But if your goal is to find clients or a job, you need to think a little more about your target audience.

Hiring managers or potential clients might not be familiar with all of the technologies in your skillset, and they might not recognize their logos at first glance. For this reason, make sure you find a way to include the actual names of your skills.

DO showcase your work

Instead of simply including a link to your GitHub profile, consider showcasing some of your projects directly on your website. This makes it much easier for users to see what you're capable of, as they don't have to go to an external website and manually check your repositories.

The main things you should include when showcasing a project are:

a screenshot (if applicable)
the project's name
links to a live preview and to the GitHub repository
a short description of the functionality and/or the technologies used

DO include a call to action

A call to action is a well known marketing tool meant to prompt a user's response and increase their engagement. Whether you're looking for a job, clients or other developers to collaborate with, make sure you encourage your users to get in touch with you, and provide the means to do so.

DON'T overwhelm users with too many animations

Oftentimes, developers feel the need to showcase their animation skills to the max. This often means that they will have overly complex animations, or they will try to animate every single element of their web page.

Having too many or too complex animations will not only be incredibly distracting for your users, but it will also significantly impact the performance of your website, especially if they are not done correctly or your users aren't using the most high-end devices.

This doesn't mean that you should not have a single animation on your website. On the contrary, if you're good at it, show it! But do be careful not to go overboard. Your priority should be the content of your page. It would be much better to have a separate project where you can go as crazy as you want with all of your animation skills.

DON'T neglect accessibility and responsiveness

Your portfolio website should provide the best experience possible for all users. Make sure you learn about accessibility and try to incorporate at least some techniques that will make your page more accessible, not only for people with disabilities, but also for people who might have old devices, slow connections and so on.

In terms of responsiveness, keep in mind that almost 60% of web traffic happens on mobile devices. This means that on average, your users are more likely to be visiting your website from a mobile phone instead of a laptop or desktop computer.

A good approach is mobile-first design. This means that you build your website to look good on mobile devices first, and then you scale up to bigger screens. On a personal note, I find it easier to transform a small-screen design into a large-screen design, rather than the other way around.

DON'T ramble on forever

Writing about yourself, describing your work, calls to action - these are all important things to include in your portfolio website, but you should try to be as concise and to the point as possible.

There is no need to write your entire life story in your About section, or to describe in detail the trials and tribulations you went through while building your latest project. Your users will want to see you and your work at a glance, rather than read an entire essay. For lengthier texts, consider creating a blog section for your page.

DON'T clutter your work section

While showcasing your work is important, you don't need to overload your website with every single project you've ever built. Instead, stick to a few that you're most proud of, and provide a link to see the rest of your work (for example, a link to your GitHub profile).

DON'T set it and forget it

You've read a bunch of articles about creating your portfolio website, you've spent time planning and designing it, you've transformed your design into code, perfecting every single detail, you've found the perfect place to host your creation, perhaps you've even invested in a custom domain, and now your awesome portfolio is out there for the world to see! Done, right? Wrong!

Your portfolio website is something that you should always return to and update frequently. Learned a new skill? Update your website. Built a new project? Update your website. The list goes on. Your portfolio website is a reflection of yourself. Make sure it always reflects the present you, not the past you.

Conclusion

These have been my ten tips to keep in mind when creating your portfolio website. Many of these are based simply on my own opinions and on the feedback I've received while building my own portfolio website. Let me know if you've learned something useful from my article, or if you've implemented some of my tips in your own portfolio websites. 😊