Ayush Goyal

My name is Ayush Noel, and I have completed my engineering from Professional Engineering College, Najibar in 2020. And after that, I joined a company called Aluqua Sports Technologies as an associate software engineer in March 2020, and I worked there for around 1 year. Then, I joined another company where I worked as a software engineer. There, I worked for around 8 to 9 months, and I switched from there due to some relocation issues. After that, I joined RNM Technology as a full stack developer in November 2021, and since then, I've been working here as a full stack developer. And I'm working on technologies like React, Next, Node, MongoDB, Elasticsearch, and all those things.

When would you use a fragment in media? What problem is this? Okay. So, a React fragment is nothing but an empty tag that we can use when we don't want to create an additional HTML element in the norm. So, what React components do is they always return a single element. So, if we return two children inside a single component, we can wrap those two into a single React fragment that will be a simple empty tag. You can say an empty element tag that can wrap those two divs to make it a single element.

How do you approach error handling in asynchronous JavaScript code? Okay, so if we have any code running in our application, for example, we have a function, and we are making an API call which is asynchronous in nature. So what we will do is write and wrap that into a try-catch block. And in try, we will make that API call and do whatever is in operation we are doing. API calls or error catching. So if there is any exception or if there is any error that occurs, then we will catch that in the catch block. And we also have a block, finally. The try-catch-finally block, or we can use that block if we want to run some code irrespective of whether we caught the error or there was no error. The finally block will always.

Flexbox and grid differ in CSS and when it is appropriate to use one over another. Both Flexbox and Grid are used in the CSS. And, in my experience, I try to use flex mostly over the grid. But, generally, I use grid also when I want to create some fixed portion of, I should say, the separation of particular screens. For example, if I want to separate a screen into 4 parts, then I'll use grid and display grid and then grid template columns to 4 actions. 1 fr, 1 fr, 1 fr, and 1 fr. And as compared to if I have 2 div blocks and I want them to display in a single line. And if I want them to come into a single line, then maybe I'll use display flex and align them center. So they'll come into a similar line. So they both have their significance, and they both can achieve the same UI whatever you want to achieve. We can achieve the same thing using Flex, and it depends on the developer and why they are using it.

Discround. How would you create a real-time collaborative feature in an application using WebSockets. Okay. So in React, we can use WebSockets. So, what WebSockets does is create a two-way communication. So, in the best case, there is a client-server connection open where we can say that we want to send data to the client. The client can say that it wants to send data to the server, and the server sends the data to the client, and the connection is established. But in that case, if the connection stays open, both the client and the frontend can send data to the backend all the time, and the backend can send data to the frontend all the time. Okay. So, in React, what we can do is create events and listen to those events. We can create events using Emmet, and we can add listeners to those events using Emmet, and we can listen to those events. If any event happens, we can use that. So, using these events, event creation, and event handling, you can use that for a real-time React or React application component.

So in TypeScript, we can define the type of a particular minor type except for certain fixed states. Obviously, we can always define the type by using a colon and the type that we can go and define. The type you can define. Like, for example, we are saying bar. Tempo variable equals to not equals to colon, test type. Either is a string or number. You can use that.

Given the typescript snippet below, which part of solid principle does it potentially violate? Okay. So glass rectangle with height constructor. We have width c number, height and number. That's the height line. Then after that, we have class square. Click calculate area. Now we are creating a new square, and we are calculating the table. So it is following the single entity principle of solid as in single responsibility principle. So that is fine. I think the code I think the code looks good. I don't see any problem.

In this JavaScript code, why am I the usage of double equals to be problematic? What would you use instead of making more robust? Okay. So if, double equal to does not do type checking. So if user input types 42 in number, if user input values 42 in number, then also it will be, accepted. And if it is in string, that is also it will be accepted. So if we write triple equals to instead of double equals to, then it will also check its type. So if, it is triple equals to and the user input value is 42 instinct, then only it will say it is it comes along the correct answer. I'll say it will screw in. Try again. Else block and print try again.

What are the potential pitfalls when migrating a large JavaScript codebase to TypeScript and how would you mitigate them? So, the first difference is type checking, which does not happen in JavaScript but will happen in TypeScript. The level of type checking in TypeScript also depends on what you want to achieve. You can easily convert JavaScript code to TypeScript by declaring all variables as type 'any', but that's not the recommended approach because that defeats the purpose of using TypeScript. The main purpose of TypeScript is to properly define types, and that depends on the types of variables you have used in JavaScript. If you have done type conversion or type propagation in JavaScript, it will take a lot of time to properly identify, read, and understand the code. You need to consider whether you have declared a variable, for example, as equal to 10 and then changed its type to make it a boolean or a string, which should not happen in TypeScript. If you keep these things in mind, you can mitigate the code from JavaScript to TypeScript.

I'm doing a performance issue in React application. Obviously, performance issues in React applications can occur due to rerendering. And, we can resolve that by using React Memo to memoize the component or lazy importing the components if it is because of rerendering. It. And if they are not happening in real time, then I'll try to debug it using the developer tools. I'll check whether I am making infinite API calls in that or not. If that is happening, that will also cause a lot of performance issues. And, there are conditions that run in a for loop, that can also impact the paid performance because it blocks the main thread. So that will slow down our application. Maybe hang it as well. So all these things, we can see and debug the code to see why our page is not performing as it is expected.

How do you ensure accessibility is part of your UX design? Okay, so while developing the proper UI, I like to consider two things in mind. First, the UI is properly responsive on most screens, like laptops, mobiles, and tablets. Because now most people don't want to scroll through websites. And second, I try to check all events, especially in modern object-oriented JavaScript, because events can cause the page to hang if you're not careful. If you've used any event that's causing unnecessary calling, then that's the main reason why the page can hang. So, I keep in mind that our events are properly aligned. We have properly included events, and if I've added any event listeners, I'll properly remove them in a PMF function as well.