Angular Interview Questions

In the CLI generated feature module, there are two JavaScript import statements at the top of the file

1. NgModule: InOrder to use the @NgModule decorator
2. CommonModule: It provides many common directives such as ngIf and ngFor.

Below are the main differences between Angular NgModule and javascript module,

There are two common possible errors with declarations array,

1. If you use a component without declaring it, Angular returns an error message.
2. If you try to declare the same class in more than one module then compiler emits an error.

Below are the steps to be followed to use declaration elements.

1. Create the element(component, directive and pipes) and export it from the file where you wrote it
2. Import it into the appropriate module.
3. Declare it in the @NgModule declarations array.

If you do import BrowserModule into a lazy loaded feature module, Angular returns an error telling you to use CommonModule instead. Because BrowserModule’s providers are for the entire app so it should only be in the root module, not in feature module. Whereas Feature modules only need the common directives in CommonModule.

Below are the five categories of feature modules,

1. Domain: Deliver a user experience dedicated to a particular application domain(For example, place an order, registration etc)
2. Routed: These are domain feature modules whose top components are the targets of router navigation routes.
3. Routing: It provides routing configuration for another module.
4. Service: It provides utility services such as data access and messaging(For example, HttpClientModule)
5. Widget: It makes components, directives, and pipes available to external modules(For example, third-party libraries such as Material UI)

A provider is an instruction to the Dependency Injection system on how to obtain a value for a dependency(aka services created). The service can be provided using Angular CLI as below,

ng generate service my-service

The created service by CLI would be as below,

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

@Injectable({
providedIn: 'root', //Angular provide the service in root injector
})
export class MyService {
}

You should always provide your service in the root injector unless there is a case where you want the service to be available only if you import a particular @NgModule.

It is possible to restrict service provider scope to a specific module instead making available to entire application. There are two possible ways to do it.

1. Using providedIn in service:

import { Injectable } from '@angular/core';
import { SomeModule } from './some.module';

@Injectable({
providedIn: SomeModule,
})
export class SomeService {
}

2. Declare provider for the service in module:

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

import { SomeService } from './some.service';

@NgModule({
providers: [SomeService],
})
export class SomeModule {
}

There are two possible ways to provide a singleton service.

1. Set the providedIn property of the @Injectable() to "root". This is the preferred way(starting from Angular 6.0) of creating a singleton service since it makes your services tree-shakable.

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

@Injectable({
providedIn: 'root',
})
export class MyService {
}

2. Include the service in root module or in a module that is only imported by root module. It has been used to register services before Angular 6.0.

@NgModule({
...
providers: [MyService],
...
})

If a module defines provides and declarations then loading the module in multiple feature modules will duplicate the registration of the service. Below are the different ways to prevent this duplicate behavior.

1. Use the providedIn syntax instead of registering the service in the module.
2. Separate your services into their own module.
3. Define forRoot() and forChild() methods in the module.

If the RouterModule module didn’t have forRoot() static method then each feature module would instantiate a new Router instance, which leads to broken application due to duplicate instances. After using forRoot() method, the root application module imports RouterModule.forRoot(...) and gets a Router, and all feature modules import RouterModule.forChild(...) which does not instantiate another Router.

The Shared Module is the module in which you put commonly used directives, pipes, and components into one module that is shared(import it) throughout the application.

For example, the below shared module imports CommonModule, FormsModule for common directives and components, pipes and directives based on the need,

import { CommonModule } from '@angular/common';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { UserComponent } from './user.component';
import { NewUserDirective } from './new-user.directive';
import { OrdersPipe } from './orders.pipe';

@NgModule({
 imports:      [ CommonModule ],
 declarations: [ UserComponent, NewUserDirective, OrdersPipe ],
 exports:      [ UserComponent, NewUserDirective, OrdersPipe,
CommonModule, FormsModule ]
})
export class SharedModule { }

No, it is not recommended to share services by importing module. i.e Import modules when you want to use directives, pipes, and components only. The best approach to get a hold of shared services is through 'Angular dependency injection' because importing a module will result in a new service instance.

In Angular 9.1, the API method getLocaleDirection can be used to get the current direction in your app. This method is useful to support Right to Left locales for your Internationalization based applications.

import { getLocaleDirection, registerLocaleData } from '@angular/common';
import { LOCALE_ID } from '@angular/core';
import localeAr from '@angular/common/locales/ar';

...

constructor(@Inject(LOCALE_ID) locale) {

const directionForLocale = getLocaleDirection(locale); // Returns 'rtl' or 'ltr' based on the current locale
registerLocaleData(localeAr, 'ar-ae');
const direction = getLocaleDirection('ar-ae'); // Returns 'rtl'

// Current direction is used to provide conditional logic here
}