At a high level, automatic garbage collection in Java works by:

But there’s a catch when it comes to how automatic garbage collection works in Java: there’s no guarantee when it will run, and there’s multiple reasons why this is:

So how can you hook into garbage collection? Well, objects created in Java inherit from the Object class, which means that all objects have certain methods that we can override: finanlize() is a method that is invoked by the garbage collector prior to the object being destroyed.

This might be a good place for you to invoke some business logic that you need to perform upon the object being deleted from memory, but remember: There is no guarantee when garbage collection will run, and therefore the logic that you put in the finalize() method of your object shouldn’t really be mission critical as it may or may not run when you expect it to. Also, garbage collection is generally an expensive task and we should really let the JVM do its things since it’s already highly optimized. (There really are very few reasons why you should be doing your own garbage collection in Java, and if you’re on the fence as whether or not it’s something you explicitly need to handle, you probably don’t.)

Furthermore, handling your own garbage collection is generally frowned upon, and if you do need to handle some kind of clean up activities for when objects are no longer needed, you should probably be building this logic into a service or a method that lives on the object that is going to be destroyed, or if you’re using Spring or Spring Boot, this is probably already managed for you to an extent.

To put it simply, the TDZ is a phase in a variable’s lifecycle where it technically exists, however it cannot be accessed or used – This phenomenon mostly applies to variables defined with the keyword let or const, but not var (And function definitions, too), thanks to the concept of hoisting (More on ‘hoisting’ in a moment – there are a few caveats, which is why I said ‘mostly’).

Let’s take a look at a contrived example to see the TDZ in action:

function myFunction() {
    console.log(x);
    let x = "Hello, world!";
}

myFunction();

The above will result in the following being logged to the JS console:

ReferenceError: Cannot access 'x' before initialization

The JS interpreter knows that x exists, however it cannot access it before it’s been initialized – x is in the temporal dead zone. Think of it this way: You’re going to make a dish that requires bread crumbs. You can see through the clear doors of the cabinet that you have bread crumbs available, but you cannot physically touch them until the doors have been opened. You know they exist, but you just can’t get to them yet. They too are in the temporal dead zone.

Let’s take a look at the same example from above, but using the var keyword to handle the variable declaration:

function myFunction() {
    console.log(x);
    var x = "Hello, world!";
}

myFunction();

The above works… Kind of. Undefined is logged to the console, indicating that x has been initialized, but has yet to be assigned any value. Interesting. Now is a good time to touch on the concept of hoisting.

In JS, hoisting is the concept where all variables (Those declared using var, let, and const) and function declarations get “hoisted” (think: “pulled to the top”) of the current scope. Note how I said declarations – NOT assignments.

Variables defined with var can be accessed before they are initialized, and they can be re-declared in the same scope, whereas variables defined with let and const cannot be accessed before they are initialized (They too are hoisted, but they are in the TDZ), and they cannot be re-declared in the same scope.

This is why in the last example from above where using var resulted in undefined being returned and not a ReferenceError like in the let example. x was declared, however it was not assigned any value, hence it was undefined.

So variables declared with the keyword var can be “used” before they’re actually assigned a value, just expect them to return undefined until they are actually assigned a value, whereas variables defined with let and const will result in a ReferenceError since they live in the temporal dead zone.

So why is the TDZ a thing when it comes to variables defined with either let or const?

Both let and const were introduced in 2015 with ES6, and the concept of the TDZ was born in order to enhance code readability and enforce some level of standardization by encouraging developers to initialize and define variables at the same time. var still exists because backwards compatibility needed to be kept in mind so older code didn’t break. As of 2024, let and const are the preferred key words to use when defining a variable.

Imagine having a remote control for your entertainment system. You can press the “play” button regardless of whether you’re playing a DVD or Blueray, streaming a movie, or listening to music. The remote acts as the interface, and the specific devices receiving the command handle the action in their own way (They are the objects). Polymorphism works similarly.

Why is Polymorphism Important?

Polymorphism offers several advantages:

• Flexibility: Code can adapt to different object types without needing to be rewritten for each specific case.
• Maintainability: As your program evolves, adding new object types becomes easier since the core logic remains unchanged.
• Readability: Code that leverages polymorphism is often cleaner and easier to understand because it focuses on the functionality rather than the specifics of each object type.

A Use Case: Animal Sounds

Let’s consider a scenario where you want to create a program that simulates animal sounds. You can define an abstract base class Animal with a method makeSound() that makes a generic animal noise. Now, create derived classes like Dog, Cat, and Bird that inherit from Animal and override the makeSound() method to produce their unique sounds (bark, meow, chirp, etc.).

// Base class
public class Animal {
  public void makeSound();
}

// Derived class - Dog
class Dog extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Woof!");
  }
}

// Derived class - Cat
class Cat extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Meow!");
  }
}

// Derived class - Bird
class Bird extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Chirp!");
  }
}

public class AnimalSoundSimulator {
  public static void main(String[] args) {
    Animal[] animals = {new Dog(), new Cat(), new Bird()};
    for (Animal animal : animals) {
      animal.makeSound();
    }
  }
}

The above example is somewhat contrived and simplistic in nature, but it does convey the core concepts of polymorphism fairly well.

We have a base class of Animal, which defined a makeSound() method, and then several classes that extend the base class and then overwrite the behavior of the makeSound() method.

The animalSoundSimulator class simply defined a new collection of Animal objects (Since they all extend the Animal class, we can consider them to be Animals), and then loop over the collection and invoke makeSound() on each animal to see polymorphism in action.

Bonus: Extends vs. Implements

You’ll notice in the above that all of the classes like Cat, Dog, and Bird all extend the Animal class. This means that Cat, Dog, and Bird all, at a minimum, have at least the functionality of the class that they are extending, and in order for the magic to take place, you must override the methods that are defined in the class that is being extended. (The @Override annotation ensures that the method is being truly overwritten and not just overloaded, in which case strange behavior might occur and it might be difficult to debug.)

However, when it comes to implementing an Interface, the classes that are implementing the interface must conform to the methods outlined in the interface, however Overriding the methods defined in the interface is not a requirement. Also note that in the case of implementing an interface, the class that is doing the implementing must implement all of the behavior defined in the interface itself – Think of it as a contract of behavior.

Spring Boot heavily relies on annotations, similar to decorators when building an Angular front end application. Annotations are essentially metadata that are used to add context to what a class, method, or field does. This helps Spring Boot automatically configure Beans, manage dependencies, and handle other application configuration that we’d have to otherwise do manually when compiling our application.

One of these annotations is @Autowired. This annotation is a way for us to achieve dependency injection with next to no boilerplate code needed. It almost seems like magic because of how easy it is, and with that level of abstraction comes several caveats and pit falls when comparing this method of dependency injection versus traditional constructor injection.

Let’s first take a look at some of the benefits of using the @Autowired annotation:

• Reduce boilerplate code
  This is probably an obvious advantage and is the reason why some people tend to use @Autowired for any and every dependency needed: It’s so easy! All you need to do is simply add the @Autowired annotation to whatever field, constructor parameters, or setter methods you want to inject and you’re done! This also somewhat improves code readability because it reduces the amount of boilerplate code you have to write.
• Loose Coupling
  By injecting components at runtime we can achieve loose coupling which is a great advantage when it comes time to test our application via unit testing. Though you will likely have to mock or provide the appropriate test beans when running the unit tests.
• Automatic dependency lookup
  Spring Boot will find and manage the appropriate beans to inject based on their types and their annotations. You won’t have to create or locate the required Beans yourself while can reduce the likelihood of errors and added complexity. (More on why this could be bad in a little bit)

And let’s discuss some of the drawbacks when using @Autowired:

• Implicit dependencies
  Sure, @Autowired helps to reduce the amount of boilerplate required, it also can make it more difficult to truly discern what the class is doing and what exactly it relies on in order to function as intended. This could pose as a real challenge for future developers who are tasked with maintaining/enhancing the application in the future – they will have to take more time to reason about the code you’ve written.
• Less control
  By reducing the amount of boilerplate code needed, one of the trade offs is giving up some level of control. What if for some reason you have multiple beans of the same type? Spring Boot might not pick the correct bean and as a result cause the application to break or not function correctly. You can get around this by specifying qualifiers, but if you’re going down that route, why not rely on constructor injection?
• Circular Dependencies
  It is very easy to get yourself into a situation where service A depends on service B, which depends on service A. You have to be very careful not to create a circular dependency and you also have to ensure the order in which bean creation is taking place is correct. This is easier said than done in a large application with dozens and dozens of services, controllers, and repositories.

With that said, when should we be using the @Autowired annotation to handle dependency injection? It’s hard to come up with an iron clad rule – If you’re building a small CRUD application and are just working towards an MVP and you don’t have many services, then probably using constructor injection is the way to go in this case. If you’re working on a larger enterprise-level application, then most likely you will want to avoid using @Autowired in most cases. If you have a service that relies on half a dozen or more other services, there might be no other sensible way aside from using @Autowired – though this indicates code smell: Why does this service rely on so many other dependencies to function? Is it doing too much and can be broken into smaller chunks?

Finally, let’s discuss some of the advantages of using traditional constructor dependency injection, as well as some of its draw backs (You can probably guess what they are based off of the pros and cons of using @Autowired)

Benefits of constructor-based dependency injection:

• Clear dependencies
  Dependencies are declared directly in the constructor, which makes them clearly visible and identifiable. This will allow for better readability in the future and reduces the risk of missing or hidden dependencies. Sometimes being more verbose is better, and this is one of those cases.
• Fail-Fast
  If a mandatory dependency is missing, the constructor initialization fails which prevents the creation of half-baked objects. Even better, you avoid the wrong bean being injected if you wind up with two beans with the same name/type.
• Encourages immutability:
  If you’re using the functional programming paradigm when building your application or want to stay true to true OOO principles, using constructor-based dependency injection as opposed to @Autowired is basically a must.
• Testability
  Generally, constructor-based dependency injection is easier to test. You can more easily mock dependencies during unit testing by passing mock objects into the constructor.

And finally, let’s take a brief look at some of the drawbacks of using constructor-based dependency injection (Hint: there really aren’t many):

• Boilerplate code
  This is probably the biggest one for most people – it requires a lot more code than just simply using @Autowired to handle dependency injection, but in most cases the additional code is worth it. You could even explore using Lombok if you wanted to still use constructor-based dependency injection but keep the amount of boilerplate code at bay. Just be careful because you’re introducing yet another layer of abstraction by using Lombok. You have to find the right balance for your code base and the team you’re working with.
• Limited Flexibility
  There is really no way to handle optional dependencies when using constructor injection so situations that require dynamic configuration changes might pose a problem. The answer to this is just more code in the way of more objects and classes. Again, this is a trade-off between how easy the code is to read and maintain and how quickly you can get the code working.

If that’s the case, then you’re probably relying on services to manage state as it’s the out-of-the-box method presented to us by the Angular team.

The gist of services is to abstract away any business logic from our components, and subscribing to any state that we need to use within the component.

One common task that we routinely find ourselves doing when relying solely on services for state management is creating semaphore variables to determine whether or not a certain piece of state is loading and as a result displaying some kind of message or icon to the user letting them know that it may be a moment before the data is ready. Error handling also mimics this same pattern where we’re using Subjects or BehaviorSubjects and subscribing to them over and over again. Based on the truthiness of a variable like “hasErrors”, we can display a message letting the user know something unexpected happened and it requires their attention.

The async pipe provided to us by Angular out of the box is a great way to get around having to set up numerous subscriptions within our component TS files, and comes in especially handy when you’re working on a small to mid-sized application that doesn’t have extremely complex state and control flow.

Let’s take a look at the traditional way of setting up a simple service and a method to fetch some data from an external API, and then subscribe to that data from within a component:

import { Injectable } from '@angular/core';
import { BehaviorSubject, of } from 'rxjs';
@Injectable({
  providedIn: 'root',
})
export class CounterService {
  count$: BehaviorSubject<number> = new BehaviorSubject<number>(0);
  isLoading$: BehaviorSubject<boolean> = new BehaviorSubject<boolean>(false);
  constructor() {}
  increase() {
    this.isLoading$.next(true);
    setTimeout(() => {
      this.count$.next(this.count.value + 1);
      this.isLoading$.next(false);
    }, 3500);
  }
}

The above service is somewhat contrived, but it’s a good example to show us how subscribing to the isLoading variable can be abstracted away using the async pipe within our component template files. Let’s take a look at how how we’d implement showing the user some kind of loading prompt within the use of the async pipe:

import { CounterService } from '../services/counter.service';
import { Component, OnInit } from '@angular/core';
@Component({
  selector: 'app-my-counter',
  templateUrl: './my-counter.component.html',
  styleUrls: ['./my-counter.component.scss'],
})
export class MyCounterComponent implements OnInit {
  count: number;
  isLoading: boolean;
  constructor(public countService: CountService) {}
  ngOnInit(): void {
      this.countService.count$.subscribe((count) => {
        this.count = count;
      })
      this.countService.isLoading$.subscribe((isLoading) => {
        this.isLoading = isLoading;
      })
    this.countService.increase();
  }
}

Lines 21 – 23 are where things start to get really repetitive and you’ll find yourself setting up at least 3 subscriptions per component, assuming that each component always has some kind of meaningful external state (In our example the count variable), and semaphore variables for both loading and errors.

Also note: Line 14 we’re also marking the counterService public instead of private like we typically do when we handle dependency injection via the constructor’s parameters. If we did not do this, the counterService would not be available within the associated template file that we’re going to work with next.

Let’s abstract that away from our component TS files and implement it within our template files instead using the async pipe:

<div *ngIf="counterService.isLoading$ | async; else showCount">
    Loading... Please wait!
</div>
<ng-template #showCount>
    {{ counterService.count$ | async }}
</ng-template>

What a difference! We no longer have to set up subscriptions within our component TS files but can instead lean on the async pipe to manage the subscriptions and assignments for us!

The async pipe is great because it subscribes to the observable stream and takes whatever values comes across the stream and interpolates it within the template without us having to specifically initialize a local template variable and handle the assignment based on the subscription.

Just to be clear, this will work when working with not-so-complex states generally found in smaller to mid-sized apps. This pattern starts to break down once you start introducing things like role based authentication, really in depth control flow, or a more complex object with nested objects and other data structures and collections.

First, what is the difference between map and forEach in Javascript?

.map() – Iterates over a collection and does something to each item and then pushes that new element to a newly created array which is then returned once each element in the provided collection has been iterated over.

.forEach() – Still iterates over a collection and does something to each item but it does not push the returned value of the action to a new array. (Think: “for each element in this array, go off an fire of an XHR and get the response and do something with it”… Have fun with all of the promises!)

Let’s recreate .map() from scratch

When writing software we take for granted what is going on under the hood in the built in methods and functions Javascript provides to us (Really any language, for that matter). By re-creating .map() from scratch will give us a better understanding of how the code is behaving in our applications. From there we can start building on that knowledge to understand more advanced topics like how the reduce function works.

Remember: .map() allows us to go through each element in a collection (array) and does something to each element (it ‘maps it’ to a new value based on the instructions we give it) and then returns an array with all the new values.

A few things stick out right away with the above breakdown:

• Our custom map function will have two parameters:
  • The input collection (array)
  • Instructions (a callback function) that we pass in
• Our custom map function will also need a way to iterate over each element – So we’ll have to employ some kind of loop to achieve this
• We’re returning a new array – at some point we’re going to have to create a new array

Ready? Here’s essentially what map is doing under the hood:

const arr = [1, 2, 3, 4, 5];

const newMap = (input, mutator) => {
  let newArr = [];
  for (let i = 0; i < input.length; i++) {
    newArr.push(mutator(input[i]));
  }
  return newArr;
};
const multiplyByTwo = (num) => {
  return num * 2;
};

const answer = newMap(arr, multiplyByTwo);

console.log(answer);

Line 1 we’re declaring a constant in memory with the label arr and assigning it the value [1, 2, 3, 4, 5].

Line 3 we’re defining a function in memory with the label newMap.

Line 10 we’re again defining a function in memory with the label multiplyByTwo.

And finally, line 14 we are declaring a constant in memory and assigning it the value to whatever the code to the right of the equals sign evaluates to – this is where we invoke/run the code above.

To the right of the equals sign on line 14 we run the newMap function and we provide it with two arguments: arr and the function multiplyByTwo.

We then create a new local execution context when we start running the newMap function where we setup our parameters:

input: [1, 2, 3, 4, 5]
mutator: (num) => { return num * 2 }

Next, we create a new empty array giving it the label newArr.

The provided array, now known as input in this local execution context, is then iterated over using a for loop. For each element in the collection, we then run the multiplyByTwo function with the input, which then returns the input number multiplied by 2 and that number is then pushed into the previously created new blank array (newArr).

Finally, once the for loop completes, the function then runs the last line of code which is to “spit out” (return) the newly created array and store that into the variable answer where we then console.log it to see it’s value.

Closing thoughts

Recreating the map function is a great exercise for newer developers because it allows you to “peel back the layers” of what’s going on under the hood in some of the code you’ve been working with for several months or years. Furthermore, doing this also gives you a better understanding of how functional programming in Javascript works and by understanding how .map() works under the hood you will have a much better understanding of how .reduce() is working which is the cornerstone of functional programming.

Object oriented programming seeks to combine data and actions that we can invoke on that data while making it easy for us programmers to switch between the two.

Consider the following scenario: We have a user and that user wants to login to our eCommerce app, browse around, place an order and perhaps leave a review for a product they purchased several weeks ago.

First, let’s take a look at a naive approach that you will see very quickly will not scale well and will lead to a lot of memory usage:

const user1 = {
    userId: "00001",
    name: "Thomas",
    displayName: "tom123",
    email: "thomas.smith@example.com",
    login: () => {
        //login business logic
        //maybe an API call, storing session info
        console.log("User has successfully logged in!")
    },
    logout: () => {
        //logout business logic
        //Another API call, removing session info
        console.log("User has successfully logged out!")
    }
}

console.log(user1.displayName) //returns 'tom123'
user1.login() //logs the user in to the app

The above code is fairly straightforward. We create an object with several properties (userId, name, etc) and assigned it the label ‘user1’ in memory. This also has a few methods attached as well: login and logout.

The object oriented ‘litmus test’ is: Can we run user1.login() and actually access both the object and the functionality that we want?

While the answer is ‘yes’ for the above sample, it has several fairly obvious issues:

What if we have 100 users, or perhaps 100,000 users or even more? Every single user object will have to have copies of those two login and logout methods and waste a lot of memory in the process. Also, what if we have to change the business logic in either of those methods sometime in the future due to some enhancements the product team wants? You would be stuck trying to individually update thousands and thousands of methods and hope for no errors along the way.

This implementation will not scale well, however at its core this is exactly what we want in terms of features – it satisfied the object oriented litmus test of ‘Can we run user1.login() and actually access both the object and the functionality that we want?’

Let’s take a look at another implementation that uses Object.create() – Object.create(), if invoked without any arguments will return a blank object. If passed an argument that is itself an object with key/value pairs, it will do something pretty interesting that gets us pretty close to our ideal solution to implement an object oriented programming paradigm in Javascript.

const userFunctions = {
  login: () => {
    //login business logic
    //maybe an API call, storing session info
    console.log("User has successfully logged in!");
  },
  logout: () => {
    //logout business logic
    //Another API call, removing session info
    console.log("User has successfully logged out!");
  },
};

const user2 = Object.create(userFunctions);

console.log(user2.__proto__, "user2 proto");

user2.userId = "00002";
user2.name = "Sam";
user2.displayName = "Sam123";
user2.email = "sam@example.com";

user2.login();

When we console.log(user2.__proto__) we get to see the magic that is going on behind the scenes. Javascript will append an __proto__ (double underscore proto, sometimes called ‘dunder proto’) to each object and it will then in turn give access to the login and logout functions. The litmus test holds true: When we call user2.login() Javascript looks to the __proto__ property when it doesn’t find the login() method immediately on user2. Once it finds it, it then invokes login() and the body of the function then runs.

Finally, we can clean this up a little further and utilize some more modern ES2015 features: The ‘new’ keyword.

The ‘new’ keyword in Javascript automates 3 key tasks for us:

1. It auto-creates an empty object and assigns it to the label ‘this’
2. It sets up a hidden __proto__ property that points to the constructor function’s prototype object that contains all of the desired functionality
3. It automatically returns the newly created object that was stored in the ‘this’ label in memory.

Let’s see it in action:

function CreateUser(userId, name, displayName, email) {
  this.userId = userId;
  this.name = name;
  this.displayName = displayName;
  this.email = email;
}

CreateUser.prototype.login = function () {
  console.log("User has successfully logged in!");
};

CreateUser.prototype.logout = function () {
  console.log("User3 has successfully logged out!");
};

const user3 = new CreateUser("00003", "Mike", "Mike123", "mike@example.com");

console.log(user3.__proto__, "user3 __proto__");

user3.login();

In this example, user3.__proto__ points to the prototype object on the CreateUser function – this happens thanks in part to the ‘new’ keyword. This functionality is made possible because when you create a function in memory, not only does Javascript save the function body, but it also creates a ‘hidden’ object that you can append key/value pairs to. This concept is sometimes referred to as a “function object combo”.

Javascript takes the above concepts even one step further by implementing classes, however that topic is better left for another article for another time. Thanks for reading and hopefully you’ve gained a better understanding of how the ‘new’ keyword is working under the hood!

If you’re a less experienced front end developer and are looking to up your JavaScript game, forcing yourself to create a few Angular apps is a great way to really level up your JS skill set. React and Vue do a great job at abstracting things away so some things that happen just seem like magic. Angular still has abstractions however not to the extent of the other two so you’re forced to roll up your sleeves and up your JS game. (This is really just me saying the learning curve for Angular is more demanding that any other front end framework.)

Angular ships with RxJS and it’s a complete paradigm shift in that you no longer simply rely on fetch() or axios.get() to handle your HTTP requests in your app. RxJS instead allows us as developers to subscribe to a data stream and listen to it for any changes while the subscription is active. To be fair, you can implement RxJS in either a React or Vue app, but neither ships with it out of the box so it’s up to you the install it as a dependency and use it (Convention over configuration… Remember?)

Subjects and BehaviorSubjects are observables that can emit their values to multiple observers via subscriptions. On the surface we’re almost inclined to think that both a Subject and a BehaviorSubject do the same thing, but the differences are subtle and can make a pretty big impact on your application.

In simple terms: A Subject does not need to have an initial value when being created but a BehaviorSubject requires an initial value when being created. Therefore, a Subject will only emit upcoming values, whereas a BehaviorSubject will emit one previous value and all upcoming values.

Let’s set the stage for a pretty common example front end developers handle on a routine basis: showing or hiding a modal to let the user edit settings. As you can imagine, this is a good use case for a BehaviorSubject because we’ll want to set the initial value of “showModal” to “false”.

// src/app/services/modal.service.ts

import { BehaviorSubject } from 'rxjs';

export class ModalService {
  showModal = new BehaviorSubject<boolean>(false);

  toggleModal() {
    this.showModal.next(!this.showModal.value);
  }
}

Had we not passed in a boolean value to the BehaviorSubject’s constructor, TypeScript would have immediately given us an error indicating that one argument was expected, but we’ve given it 0.

The above example sets up an Angular service that we can then import into any other component and utilize the toggleModal() method. Any subscriptions to this observable therefore will receive an initial value of “false” since BehaviorSubjects allow us to track and initial value and any subsequent changes in the future.

On the other hand, a Subject does not require an initial value. In sticking with the modal example from above, a good parallel use case for a Subject would be if upon the user opening a modal in the app we want to display a form containing the app’s settings that they can modify and then save. Let’s take a look:

// src/app/services/settings.service.ts

import { Subject } from 'rxjs';
import { HttpClient } from '@angular/common/http';

export class SettingsService {

  appSettings = new Subject<Settings>();

  constructor(private http: HttpClient) {}

  getAppSettings() {
  this.http.get<Settings>('https://www.myapp_api.com/settings')
    .subscribe((settings: Settings) => {
      console.log(settings, 'Settings received from API call.');
      this.settings.next(settings);
    )};
  }

}

Sure, there’s a little more code than the previous BehaviorSubject example but most of it is simply boiler plate code in order to set things up. The key takeaway here should be that when we create a new Subject, we do not have to supply its constructor method with an argument to set the initial value upon creation. We only have to indicate what kind of value will be occupying it in the future, which in this case is an object of type “Settings”.

We’ve defined a getAppSettings() method that we can again import into any other component and fetch our user’s app settings from the back end and then once the request comes back we will push the new value via the next() method and any subscriptions made will finally receive their first value. We will then have access to the app settings, now stored with the label appSettings, be it an object of settings or an array.

So what’s the tl;dr version of all of this? Pretty simple, actually:

Use a BehaviorSubject if you need an initial value (The modal example above is a really good example) and use a Subject if you do not need an initial value.

From MDN, a closure is as follows:

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures

Essentially, we can think of a closure as a backpack that every function gets whenever it is defined. The contents of said backpack are dependent on where the function was defined – this is also known as its scope. This is what we mean when something is lexically scoped. In this backpack we will find the surrounding function’s variables, which will allow the inner function (the one that is carrying the backpack) to have access to the outer function’s scope/variables even after it’s finished executing. We can really start to leverage this feature of JavaScript when we return a function from another function.

Let’s take a look at a really basic example to get a better understanding at how this concept works in practice:

function outerFunc() {
  let counter = 0;

  return function innerFunc() {
    console.log(`The value of counter is: ${counter}`);
    counter++;
  };
}

const runnerFunc = outerFunc();

runnerFunc();
runnerFunc();
runnerFunc();
runnerFunc();
runnerFunc();
runnerFunc();

And the output that’s logged to the console is:

The value of counter is: 0
The value of counter is: 1
The value of counter is: 2
The value of counter is: 3
The value of counter is: 4
The value of counter is: 5

Line 6 from the code example above (Not the console.log output) is extremely important – the inner function is incrementing a variable that was defined in the outer function’s scope. When running functions, we’re used to them not being able to persist the variables/state from its previous execution context (the last time it was run), but somehow in this example the inner function was still able to access variables that belonged to the outer function’s scope even after it was finished running! Enter the concept of closures!

We can do some really interesting things with this newly found knowledge. Let’s take another look at a custom made generator function that we can pull values from one at a time. This is a big paradigm shift in that we normally iterate over a collection of objects and get the value one at a time that way using a tried and true for or while loop. Let’s have a look:

function countUpUntil(x) {
  let counter = 0;
  function next() {
    if (counter <= x) {
      return { value: counter++, done: false };
    }
    return { value: undefined, done: true };
  }

  return { next };
}

const iterator = countUpUntil(5);

console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(interator.next());

And let’s have a look at the output from the console:

{ value: 0, done: false }
{ value: 1, done: false }
{ value: 2, done: false }
{ value: 3, done: false }
{ value: 4, done: false }
{ value: 5, done: false }
{ value: undefined, done: true }

Now we’ve created a function in such a way that will only allow us to run it a certain amount of times! We can use this method to enable us to “pull” from a collection each time the function is run as opposed to us traversing the entire collection using a traditional for/while loop – an incredible paradigm shift that paves the way for concepts like observable streams, generator functions, and iterator functions, all of which are significant building blocks in the JavaScript ecosystem.

In the above code example, we again have an inner function, this time called next, that is accessing the variable with the label counter that was defined in the outer function’s execution context. In fact, we reference counter twice – we perform a conditional to see if counter is less than or equal to x (the number we want to ‘count’ up until), and if the conditional is true, we then return an object that contains the value of count after it’s been incremented by 1, as well as a boolean letting us know whether or not the stream is done. When the conditional returns false, we get an object back with a value of undefined, and a truthy value for done letting us know the stream has finished giving us results. We can then implement logic elsewhere in our program to check for the truthy value.

A unit test is a smaller piece of the TDD paradigm in which it sets out to test a single unit of code – in most cases a function or method – to ensure that when it runs in a controlled environment the code behaves as we intended it to do so.

When we say unit testing as it relates to Angular, in most cases we’re talking about testing a single component to ensure that its functionality works as intended and no breaking changes have been introduced. (We can also unit test services, directives, and pipes) By default, Angular comes out of the box with Jasmine and Karma to assist with unit testing. Jasmine is a testing framework that gives us things such as spies and pattern matching, whereas Karma is a task runner that helps us with the execution of the tests.

When we generate a new component using the Angular CLI (ng generate component users) in addition to it generating our usual CSS, HTML template, and TS Class file, it also generates a .spec.ts file for us that scaffolds a basic test for us that ensures the component is at least successfully created. Certainly a great starting point!

Let’s take a look at what the CLI gives us after running the above ng generate command:

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { UsersComponent } from './users.component';

describe('UsersComponent', () => {
  let component: UsersComponent;
  let fixture: ComponentFixture<UsersComponent>;

  //SECTION 1
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ UsersComponent ]
    })
    .compileComponents();
  });

  //SECTION 2
  beforeEach(() => {
    fixture = TestBed.createComponent(UsersComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  //SECTION 3
  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

I’ve added several comments to act as section headers to better assist in explaining what’s going on.

Section 1
This beforeEach block runs before each test we define later on in the spec file. We’re setting up a Test Bed, which is a controlled Angular environment for our tests to run in. Notice how the configureTestingModule method takes in an object as its argument and within that object we have a declarations property that is an array. Where else have we seen this? When ever we declare a module using the @NgModule decorator, of course! We’re essentially setting up a mini-module to test our component in!

Section 2
This second beforeEach block is where we’ll actually be setting up an instance of the component we want to test.

TestBed.createComponent(UsersComponent) returns to us a TestBed with an instance of the UsersComponent, and on the very next line we’re setting our component variable to fixture.componentInstance property which is an instance of our component that we can now run tests on!

fixture.detectChanges() gives us access to any changes to the component – it’s essentially refreshing the component after we’ve run a method or made some changes to some of the component’s properites.

Section 3
Finally! What we’ve been waiting for! Section 3 is where we’re actually writing our tests – Remember before each of these tests run, sections 1 and 2 will run each time – hence the beforeEach blocks. This boiler plate test lets us know that the component is created successfully without any bugs that are preventing it from compiling/loading.

Putting it all together

Let’s take things a step further. Let’s create a test for a login form that should only attempt to authenticate a user if the username and password fields are filled out. This is a great example because not only is it a real world use case, but it’ll also show us how to incorporate spies into our unit tests. Our login form also relies on a service, in this case the authService, so it’ll also give us a chance to look at how we incorporate services into our tests as well.

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { FormsModule, NgForm } from '@angular/forms';
import { AppRoutingModule } from 'src/app/app-routing.module';
import { AuthService } from 'src/app/services/auth.service';

import { LoginComponent } from './login.component';

const authServiceStub = {
  login: () => {},
  signup: () => {},
  user: {
    subscribe: () => {},
  },
};

describe('LoginComponent', () => {
  let component: LoginComponent;
  let authService: AuthService;
  let fixture: ComponentFixture<LoginComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [LoginComponent],
      imports: [AppRoutingModule, FormsModule],
      providers: [{ provide: AuthService, useValue: authServiceStub }],
    }).compileComponents();
  });

  beforeEach(() => {
    fixture = TestBed.createComponent(LoginComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
    authService = TestBed.inject(AuthService);
  });

  it('Should not attempt to authenticate user if the form is invalid', () => {
    const authSpy = spyOn(authService, 'login');
    const testFormData = <NgForm>{
      valid: false,
      value: {
        email: '',
        password: '',
      },
    };
    component.onSubmit(testFormData);
    fixture.detectChanges();
    expect(authSpy).toHaveBeenCalledTimes(0);
  });
});

A few important things to take note of that differ from the boiler plate code the Angular CLI gives us:

• We create an object called authServiceStub that stubs out all of the methods/properties that our login component will interact with. In the majority of cases it’s alright to just create no-op functions. We can run them, but we don’t expect anything to happen. We can spy on them to see if they do or do not run, and how many times if they do run.
• The login component relies on the AppRoutingModule as well as the FormsModule. These must be imported into our test module via the imports array.
• We need to provide the AuthService to this module, but we don’t want to test the logic within the service itself when unit testing this component. At this point we don’t really care how the service’s login and signup methods work. We just want to ensure that our login component actually runs them when expected. We’ll more or less overwrite most of its functionality via the useValue property.
• We inject the new mock AuthService into the TestBed so we can later interact with it and spy on its methods.

Lastly, let’s take a look at the single it spec from above:

  it('Should not attempt to authenticate user if the form is invalid', () => {
    const authSpy = spyOn(authService, 'login');
    const testFormData = <NgForm>{
      valid: false,
      value: {
        email: '',
        password: '',
      },
    };
    component.onSubmit(testFormData);
    fixture.detectChanges();
    expect(authSpy).toHaveBeenCalledTimes(0);
  });

We’re doing a few important things here:

• We’re creating a spy. We’re going to spy on the login method from our newly created authService that we injected into this test bed.
• We’re setting up basic form data that we know should result in the login function not running.
• We attempt to run the component’s onSubmit function with the testFormData as an argument and we’re refreshing to get any changes.
• Finally, we’re checking to see how many times the login function was run thanks to the authSpy. We’re expecting this value to be 0. If it’s been run 1 or more times the test will fail and we know that we introduced breaking changes into our code. (Did we remove a conditional, perhaps?)

What about DOM elements?

The above example didn’t verify that an error message was being presented to the user, which would be somewhat of an awkward user experience if we just left them guessing as to why nothing is happening while using the application. How would we go about creating a unit test that also ensures that some kind of error message is being shown to the user? Let’s take a look at another it block:

  it('Should display a div that contains an error message in the event of a user error during login', () => {
    const testFormData = <NgForm>{
      valid: false,
      value: {
        email: '',
        password: '',
      },
      reset: () => {},
    };
    component.onSubmit(testFormData);
    fixture.detectChanges();
    const loginElement: HTMLElement = fixture.nativeElement;
    expect(loginElement.querySelector('#error-container')?.innerHTML).toContain(
      'Must provide valid credentials'
    );
  });

A lot of this is pretty similar to the previous example. The main difference is that after we attempt to submit the form with data that we know will cause it to fail, we run fixture.detectChanges() to “refresh” the component, and then we access the underlying HTML element via fixture.nativeElement. We then create an expect/toContain check that accesses the HTML element that has error-container as its ID and ensures that its innerHTML contains the string “Must provide valid credentials”.

Wrapping things up

Overall, unit testing can be challenging, but as an application grows and development teams have to move faster, it speeds up the overall development process and decreases errors going into production because you can immediately check to see if the changes you are making have unintended consequences elsewhere in the application. It’s also important to note that as a best practice, it’s best to write the majority of tests before writing any code in order to ensure you’re not introducing biases – It is test driven development, afterall!