DEV Community: Ismail Labbi

The ABCs of Angular : Dependency Injection Provider & Provide Part 2

Ismail Labbi — Thu, 08 Jun 2023 21:22:20 +0000

In the previous article, we introduced the useClass property within the providers array to define how the Angular Dependency Injection system instantiates a class. In this article, we will delve deeper into this syntax and explore providers in Angular.

Before we proceed, let's refresh our memory 😁 .

In Angular, providers are an array of instructions, where each provider is an instruction or recipe that describes how an object for a particular class, string, token, etc., is created.

Now, let's focus on a specific object in the providers array:

{ provide: LoggerService, useClass: LoggerService }

This Provider object contains two properties: provide and useClass.

The provide property represents the identifier of the provider, which can be either a string or an instance of InjectionToken. In our example

Contructor(public loggerService:LoggerService)

we inject an instance of LoggerService into a component's constructor using LoggerService as the token 🥴🥴.

If this isn't clear, don't worry; examples will help you understand it better 😉.

Consider the following modified provider syntax:

providers: [
  { provide: LoggerService, useClass: BetterProductService }
]

Now, when Angular encounters the need to inject LoggerService in a constructor, it will search the providers and find LoggerService. However, instead of injecting LoggerService, it will inject BetterProductService. In other words, the provide: LoggerService is merely a token used to identify what we want to inject.

For your Information :
Angular doesn't complain if the token is used multiple times. In the following example, the token LoggerService is used twice, but the last registration (BetterProductService) takes precedence.

providers: [
  { provide: LoggerService, useClass: LoggerService },
  { provide: LoggerService, useClass: BetterProductService }
]

*You should also know that the token can also be a string ! *
For example:

providers: [{ provide: 'LoggerService', useClass: LoggerService }]

In this case, 'LoggerService' serves as a string token. To inject LoggerService, we can use the @Inject decorator as shown below:

export class AppComponent {
  constructor(@Inject('LoggerService') private loggerService: LoggerService) {}
}

However, using string tokens can introduce naming collisions if multiple parts of your application use the same string for different purposes. This can lead to conflicts and make your code harder to understand.

To address this, Angular provides the InjectionToken

What is an Injection Token?

An Injection Token is similar to a string token, but instead of using a hardcoded string, we create the Injection Token by instantiating the InjectionToken class. This ensures that the tokens are always unique.

To create an Injection Token, import InjectionToken from @angular/core:

import { InjectionToken } from '@angular/core';

Next, create a new instance of InjectionToken with a unique name, such as LoggerServiceToken:

export const LoggerServiceToken = new InjectionToken<string>('LoggerService');

Here, we specify the optional type parameter and the token description, which helps clarify the token's purpose.

providers: [
  { provide: LoggerServiceToken, useClass: LoggerService },
  // Other providers...
]

Now, you can inject the LoggerService using the Injection Token in your component:

export class AppComponent {
  constructor(@Inject(LoggerServiceToken) public loggerService: LoggerService) {}

In the next article, we will explore additional properties of the provider object in Angular. Apart from provide, there are other properties that can be used to configure the dependency injection behavior.

The ABCs of Angular : Dependency Injection Part 1

Ismail Labbi — Tue, 23 May 2023 22:01:54 +0000

What is Dependency Injection?

Let’s start with an example to better understand 😃.

I have a LoggerService class that implements a log method. This method helps us display messages:

export class LoggerService {
  log(message: string) {
    console.log(`Logger Service: ${message}`);
  }
}

Now, suppose I have a UserService that needs the LoggerService to display some messages. We could instantiate the LoggerService directly in UserService like this:

export class UserService {
  private loggerService: LoggerService;

  constructor() {
    this.loggerService = new LoggerService();
  }

  getUser() {
    // Fetch user logic...
    this.loggerService.log('User fetched successfully!');
  }
}

While this approach works, it is generally less flexible and more difficult to maintain. For example, if you ever wanted to replace LoggerService with a different implementation, you would need to manually change all the places in your code where LoggerService is instantiated. Moreover, it's your responsibility to manage the entire lifecycle of that dependency, including its destruction. Hence, we need a mechanism that instances dependencies for us and manages the lifecycle of those dependencies

💥💥And the solution is Dependency Injection (DI):💥💥

Dependency Injection is a design pattern where a class receives its dependencies from an external source rather than creating them itself. These dependencies are often instances of other classes.

Angular implements this pattern for us. The new implementation will look like this:

export class UserService {
  constructor(private loggerService: LoggerService) { }

  getUser() {
    // Fetch user logic...
    this.loggerService.log('User fetched successfully!');
  }
}

There's no need to instantiate the dependency (LoggerService) manually. Angular will do this for us by using the Dependency Injection pattern.

However, if you write this code in your project, unfortunately, you might encounter this type of error: R3InjectorError(AppModule)[LoggerService -> LoggerService -> LoggerService]: NullInjectorError: No provider for LoggerService! 😡😡😡

Don't fear, the solution is simple 😁 😁. The error message "no provider" simply means that the Angular Dependency Injection system can't instantiate a given dependency because it doesn't know how to create it.

In Angular, we define how to create our dependencies using the providers array in the module. By adding our services to this array, we tell Angular when and how to create them. This way, the services are set up and ready for use throughout our application with Angular's Dependency Injection system:

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule
  ],
  providers: [{
    provide: LoggerService,
    useClass: LoggerService
  }],
  bootstrap: [AppComponent]
})

In the providers array, we add a new object. To understand this object, we need to ask two questions:

Which class do we want to instantiate and return? This is the value of the useClass property.
When to return this instantiated class? Each time we call LoggerService as a dependency, which is defined by the provide property.

And Angular simplifies this for us; we don't need to write all the mentioned code 😎. We can simply write providers: [LoggerService] and Angular takes care of the rest. And voilà, our service is ready to be injected and used .

Let's stop here so we don't overwhelm you. In our next session, we'll dive deeper into more details and uncover the miracles of Dependency Injection in Angular

The ABCs of JavaScript : Closures

Ismail Labbi — Mon, 20 Mar 2023 23:42:01 +0000

Hello and welcome to "The ABCs of JavaScript"! In today's lesson, we'll be delving into the fascinating topic of closures.

In JavaScript, Closures are an important and advanced feature in JavaScript that provide functions with access to variables scope and parameters of their outer function, even when the function is executed outside that outer function.

If you're unclear about closures defintion, don't worry, we'll break it down step by step.

First, let's clarify what an_ outer function and inner function_ means.
In JavaScript, functions can be defined inside other functions, like in the example below:

function outerFunction() {
  console.log("This is an outer function.");

  function innerFunction() {
    console.log("This is an inner function.");
  }

  innerFunction();
}

outerFunction();

In this example, the function that encloses the nested function is called outerFunction, and the nested function is called innerFunction very simple 😊😊.
You might ask why we need to declare functions like this instead of declaring them separately. While that is not our subject, let me give you some pointers to explain why this is useful in JavaScript 😇 😇:

Encapsulation: Defining a function inside another function allows you to encapsulate that function and its functionality within a specific scope.
Information Hiding: If you have a function that relies on some variables or other functions that are not relevant to the rest of your program.
Reusability
Performance

Let's return to our concept. As we saw earlier, the nested function is called the inner function. However an inner function can create a _closure _when it references variables from its outer scope! That's right, we've arrived at the heart of the matter.

function outerFunction() {
  let increment = 0;
  console.log("This is an outer function.");

  function innerFunction() {
    increment = increment + 1;
    console.log(increment);
    console.log("This is an inner function.");
  }

  innerFunction();
}

outerFunction()

If we execute this code, we will see the value 1 in our terminal because the inner function (or closure) has access to the variable of its outer function as we explained earlier in the definition.

But there's something even more powerful about closures 🚀 🚀 . Let's modify our code again:


function outerFunction() {
  let increment = 0;
  console.log("This is an outer function.");

  return function innerFunction() {
    increment = increment + 1;
    console.log(increment);
    console.log("This is an inner function.");
  }
}

let incrementMethod = outerFunction();
incrementMethod(); //1;
incrementMethod();//2;
incrementMethod();//3;

Did you see this beautiful magic 😍 😍? Even though the outer function has finished executing, the inner function still has access to the increment variable in its state. This demonstrates the power of closures - they can still access the variables of their outer function even after it has finished executing.

To remember this concept in JavaScript, here's a useful trick: always imagine that each function has a backpack. Before any execution of any function, the backpack is filled with all information preceding the declaration of the function. When the function is executed, it has its own backpack that it can access.

In our example, the inner function's backpack is filled with the "increment" variable, and it will always be in its backpack even if the outer function has finished execution.

I hope this article helped you to better understand the concept of closures. See you in another article!

The ABCs of JavaScript: Autoboxing in javascript

Ismail Labbi — Mon, 27 Feb 2023 23:41:00 +0000

In our previous article , we discussed that JavaScript has not only objects but also primitive types. We also mentioned that primitive types do not have properties or methods since they are not objects.

However, let's test this point to confirm whether it is true or not. Try running this code in your editor:
const name = "john"; console.log(name.length);

The output will be 4, which refers to the number of characters in the string. But wait, didn't we just say that primitive data types don't have properties? 😠 😠 😠 😠

Autoboxing

Don't worry, there is an explanation for this 😊 😊. Although primitive values don't have properties or methods, JavaScript uses the concept of autoboxing to create a temporary object wrapper around the value when we use a property or method on a primitive value.

So, when we use the .length property on the string primitive name, JavaScript automatically creates a temporary String object wrapper around the value "john", which allows us to access the .length property.

We should note that this object is a built-in object in JavaScript, and there are many predefined objects such as String, Boolean, Date, and Math. JavaScript detects the type of primitive data that we create and automatically creates an object that corresponds to that data type. For example, since we created a string primitive in our example, the object created by JavaScript is a String object.

manual boxing

We can also perform manual boxing ourselves. Here's an example:

let firstName = String("naima"); console.log(firstName.length); console.log(name.valueOf()); // "john"

In this example, we create an object directly without using autoboxing, and we can retrieve our primitive value using the valueOf() method.

I hope this article helps to clear up the confusion that exists around primitive types in JavaScript

The ABCs of JavaScript: Primitive and Object types

Ismail Labbi — Mon, 20 Feb 2023 23:36:54 +0000

In JavaScript, there is a common saying that "everything is an object" while objects are a fundamental concept in JavaScript, there are other data types that are not objects.

Primitive Data

primitive data types in JavaScript, including strings, numbers, booleans, bigints, symbols, and undefined. While these data types are not objects,

console.log( typeof "test")//string
console.log( typeof 3)//number
console.log(typeof true)//boolean
console.log( typeof null)//object
console.log( typeof 42n)//bigint
console.log(typeof Symbol()) //symbol 
console.log( typeof undefined)//undefined

Don't worry about the null type, even though it is displayed as an object, it is actually a primitive type. We will return to this topic in a future article.

Primtive vs Object

Understanding the difference between objects and primitive values in JavaScript is crucial. There are two main differences to note:

Primitive data does not have properties or methods, which is to be expected since they are not objects. This is a straightforward concept.

Objects are mutable, while primitives are immutable. This means that once a primitive value is created, its value cannot be changed. On the other hand, objects can be changed after they are created, and modifications to their properties or values will be reflected in the original object.

But what does 'mutable' and 'immutable' mean?

'Immutable' means that values cannot be modified after creation.

Let's take an example to better understand this approach.

let obj = {
    a:1
}

function incrementByOne(arg){
    arg.a = arg.a + 1
    console.log(arg.a) //2
 }

 incrementByOne (obj)//2

 console.log(obj.a)//2

We have an object called 'obj' that has a property named 'a' with a stored value of 1. We pass our object to the 'incrementByOne' function, which increments our property value by one. The first console log displays 2, and when we display our object outside the function, the console log displays the same value of 2. This demonstrates that the object's value was changed after creation from 1 to 2, We can easily modify its state.

*Is it still not clear? *

the concept may become clearer with the second example, which involves primitive values

let number = 3

function incrementByOne (arg){
   arg = arg + 1
   console.log(arg)//4
}

incrementByOne (number)// 4

console.log(number)//3

We're applying the same function, but this time we're using a number instead of an object. It's clear that the first console log displays 4, but outside the function, the number remains the same as its original value of 3. This is because primitive values pass a copy of themselves to the function, and because they're immutable, their values can't be changed after creation.

Maybe you will say : I can change its value after creation by assigning a new value as Let number = 3 number =4

Unfortunately, no. You are not changing its value or state of creation, but rather creating a new value for our data.

We should really understand that when we assign a value to our variable, we create space in memory for this data. We create a container where we store our value 3. But when you assign a new value to your primitive value, you will create a new container and store the number 4 for our variable. In contrast, if you modify or assign our object, you will just modify the first container that was created.

I hope that I have helped to explain the difference between immutable and mutable, and that you now understand the difference between objects and primitive values.