Bharath Jayachandran

Yeah, myself Bharath and I am from Chennai. My total years of experience is 4.8 years in the IT industry and 4.5 plus years of experience as an Angular developer. I started my career in 2019 in January at TCS as a front-end developer and after 3.6 years of experience, I moved from TCS to X server technologies as a senior software developer in front-end in the same Angular technology. I am looking for projects like Angular, which is a fully front-end position, and I want to work on very unique projects. There's a start-up so I am looking forward to working like a company called Aplus. It's my pleasure to be attending this interview. I am currently concentrating on building a good relationship with the team as well as the company. So yeah, thank you so much.

2-way data binding is nothing but in Angular we are having data binding which is used to know send the data from the component to the template. So 2-way data binding is nothing but you can update the data either from the view to the template or from the template to the view, I mean, component. We can achieve this by using ngModel, so by using that ngModel we can achieve 2-way data binding.

So, basically Angular's HTTP client module is used to interact with the backend to get data in a service. These HTTP client modules have methods such as get, put, update, and delete. In case I want to get data from the backend, whether it's Java-based or Node.js, I can use the get method with the HTTP client. With this method, I can access the endpoint through a URL, making it easy to consume APIs by using the HTTP client module in Angular. To do this, I need to import the HTTP client module in app.module and then in the service where I'm going to call the get method, I need to import and inject the HTTP client using the constructor, which allows me to easily call the API.

Yeah, actually this code snippet is using an HTTP client to make an HTTP call. So on top, we are importing that HTTP client from the node modules at angular slash common slash HTTP, from that location we are using that HTTP client. So in the constructor, we are injecting that HTTP client. So to do that, I will have a private variable HTTP, colon that imported thing, the HTTP client class we have imported. This is called dependency injection, actually. We are dependent on the HTTP client, yeah. So in the ngOnInit lifecycle hook, this.http.get is called. This.http.get is nothing but an HTTP client method to call the API or update the API. So this method.get is used to get the data from that api.example.com slash data URL, we are going to get the data, okay. And then it is subscribing to that method. So this data comes from the observable. We are going to subscribe to the data. So once it's subscribed, that data will be populated in the particular method called ngOnInit, okay. So after that, by using an arrow function, they are using console.log of data. So they are logging their data by using console.log. This is nothing but a way to get the data from the particular URL using observable and print it in the console, that's it. A potential problem is, I am not sure whether this will be a service or something like that. So here they are subscribing, right. If it is an observable in our service, a service means we can reuse this method of the get method throughout the component. But I think this is directly called in ngOnInit. So the very first time of the load itself, this data gets loaded. So it has some problem. But by using a service, we can easily overcome this issue because if you are using that HTTP client, if it is a service, we can use the injectable decorator and all. So yeah, first I explained what it is doing, next it will have some issues to make this call properly.

The dry principle is nothing but don't repeat yourself. If you're, in CSS 3, for example, you're using some classes to be performed, some styles, some colors to be performed in that application. In previous versions, you can repeat the classes or those colors, but while introducing CSS 3, you can use the dry principle by having some common class or something like that. By creating variables for some particular color, you don't have to call each and every time the class will be called. These kinds of things are applied in CSS 3, like mixins and all that. You can use mixins, some common class. You can reuse that whatever style is implied to that mixin, you can able to reuse that. So, you don't want to repeat yourselves. That's what the dry principle is.

When handling an error page in Angular, there are several things we can do. We need to check the routing, ensure that the data is coming from the API in the right format, and handle all potential errors in a common way. For this purpose, we can use HTTP interceptors. We can create an HTTP interceptor using a CLI command. In this interceptor, we have a method called intercept, where we can check if API responses or updates are happening properly. If they're not, we can perform some logic, log the error to the console, or display an alert to handle the error. To use this concept, we need to add the HTTP interceptor to the providers in the app module, import the necessary classes, and configure it in the app routing. Generally, HTTP interceptors are helpful in handling errors for APIs.

Consider an Angular application with the following code input in the computed file. Actually, this code performs input decorator first name by using same at input decorator last name, which is basically generally used in Angular application to communicate data from the parent to child. In the ngOnInit lifecycle hook, they provide void using void and this.fullname. So, this.fullname equals using template literals dollar this.firstname and this.lastname. By using the template, it will be able to data bind easily, and it will not use any operators. However, this code might not work because this.fullname is not declared anywhere. If you want to use this, it will see the window, and in that window, whether it is full name will be declared or not. I hope this.fullname is not declared. Also, this.firstname and this.lastname will not assign to this.fullname since it is not declared yet. And, it is using ngOnInit with void. So, first, we need to declare the full name, and we need to check whether in the child class we are passing the first name and last name. We are using that first name last name in the child component, and we need to check. These are the things we need to basically check this full name. We need to declare it properly, and then we can able to use. If you want to console, we can easily console.log by this.fullname, and we can see what is the first name and last name. I think basically it will be that know it will be the input. So, in that parent thing, we are having some input box that ngModel will be this first name or last name. While typing here, this should display, but we need to know we need to we need to initialize that variable called full name, which is a matter. And, I do not think ngOnInit we need to use void. I do not need to can use any or something like that because since it is just an on typing some input, that data is coming from the parent. So, no, we do not need to use void and all, so yeah, that's it.

I will explain the output of this code strip and what it signifies about the size of the significant like enum is a convenient feature offered by the TypeScript actually, so which allows you to specify some possible property, you know, some property value as a predefined set. So here you know, here enum days Sunday equals 1. So we are going to know predefined something in that object, right? So we can predefine some set of values using some proper names or some useful or meaningful names in TypeScript. So, you know, like instead of having or using some numeric constant, so we can use this kind of objects in TypeScript. So days of 1 the day name will be no string e.g., days will be days since it is an object, we need to call it by days dot. If it is a days dot, Sunday means it will print 1, days of 1, it will throw an error or something like that.

Like the process of handling null and undefined in TypeScript. See, in case I just want to know if I want to define a value to null for some variable, which is initially null, okay. Undefined is nothing but I'm just initializing the value, but I'm not defining some value. Let's say if I use let A equals null, then A will be defined as null. In case if I just use let A without initializing any value, it will be considered undefined, okay. So, if I want to specify something will be null, I can directly tell that null, okay. In let's say if I'm getting some value from the backend and doing a condition-based check, if the condition equals null, then it will be easy to handle whether the data is there or it's null. So, for both null and undefined, we can handle them in TypeScript, and also determine whether it's defined or not. Generally, if it's not defined, it will be considered undefined. So, when compared to JavaScript, in TypeScript we can easily handle these null and undefined.

In RxJS, I mostly used RxJS in services to get data by using the observable for continuous data transformation and subscribing to the method. So for that, I will use RxJS and if I can use some operators like map, filter, reduce, I can do everything in that service which comes under RxJS operators itself. To manage state between different components, like in cases where I want to send data and share it between two unrelated components or something like that, I will first use subjects. We have many subjects like the behavioral subject, replay subject, these kinds of subjects in RxJS. I can initialize some value in the behavioral subject at the beginning, whereas in the subject, I cannot initialize that value. By using the next method in the RxJS subject, I can easily transform the data to the unrelated component as well as to different components. These things happen in RxJS. I think I covered most of the RxJS concepts which are helpful in the…