Arjun Shrivastava

Could you help me understand more about your background by giving a brief introduction of yourself? Yep. Uh, sure. So my name is, and I'm a senior front end developer. I have eight years of experience in total, and most of my experience is working on React. Js, NextShares, uh, Node. Js. That is, uh, Munster, but I do have experience working on, uh, MySQL databases as well. And, um, I'm very passionate about building uh, reusable components and application that are scalable and, uh, and that are user centric and, um, accessible web applications. I do have a little bit of experience in in React Native as well in building, uh, cross cross platform mobile applications. And I have been involved, uh, in, you know, implementing, uh, code review processes and implementing coding standards, in in the company to enhance, uh, the code as well as to enhance the to enhance the processes, uh, as well like implementing, um, like, implementing CICD, uh, in our, uh, in our pipeline so that we can, uh, we can save a lot of, uh, time, uh, in our day to day activity. So, yeah, I think that's all about myself.

How do you handle the version management of a Node. Js in a continuous integration workflow? Okay. Uh, so we can manage the Node. Js version in a continuous integration workflow. So, like, uh, we have platform, uh, through which we can so we have, uh, platform in us in the CICD, uh, you know, workflow only that allows us to change, uh, the the version of the Node JS according, uh, to our need. So we can just go in in the in the configuration of that tool, whatever tool we are using for our CICD. So for example, if we are using um, GitHub's actions, there we can simply, uh, specify what Node. Js version we want to use, and we can simply specify, uh, that there. Or if we are using, um, a tool like, uh, maybe, what do we say, a tool like Selenium or something. There also, we can just simp we can simply specify, uh, the Node. Js, uh, version, uh, that we need, uh, and it will be simply picked up by our continuous continuous integration, uh, you know, pipeline.

Can you discuss a strategy to manage state in large scale React application? Yes. Uh, sure. So in a large scale React application, we have, uh, plenty of ways to manage our, uh, React, uh, manage, uh, our state. So we can use, uh, third party state management library like Redux or maybe just stand. And, uh, if you do not want to use a third party library like this, uh, we can simply use React's context API, and we can create different different, you know, context according to according to a feature. And, uh, we can manage, uh, the state, uh, by context API as well, and we can leverage, uh, use reducer to handle complex state, uh, in a in a component, uh, as well. But, uh, I would prefer if we, uh, if we can use, uh, you know, if if we found the need that, uh, you know, in our in our large scale React application, we need to use a library, then I think we should definitely go with Redux or Justan. And, uh, if I have to choose between Redux and Justan, then I'll definitely go with Justan because Justan is lightweight, uh, from Redux in terms of size. But it is more, uh, performant as well, uh, compared to Redux.

How can you prevent memory leaks in the application with complex state logic? Okay. Uh, so to prevent memory leaks in a React JS application, uh, we should have we should, you know, always, uh, have a have a keen eye on, um, on on any subscription if we are having, and we should close those subscriptions when the component is getting unmounted. So, for example, if we are subscribing, uh, through a through a socket. Okay. So and that socket is consuming a lot of memory. So we should always, uh, we should always, you know, remember that we need to close that socket subscription inside, uh, inside, and then the component will unmount, uh, life cycle method if we are using class based component. And if we are using function based component, then we can simply, uh, return a function from the useEffect, uh, hook, and that will act as a as as a unmount component will unmount life cycle hook. And, uh, it it it applies on on everything, like a socket subscription, uh, or if you are listening for an event, um, on DOM. Maybe we are listening for a scroll event, maybe we are listening for some other event. Uh, so all these events, we should, uh, we should, you know, uh, detach from the or destroy from the DOM when the company is is unmounting. So that's how we can, uh, you know, prevent memory leaks in a ReactJS application, uh, that is having very complex state logic.

How would you integrate a serverless API with the React application to ensure optimal performance? Okay. Uh, so to integrate a serverless API with React, uh, we can, uh, uh, so there are plenty of ways to do to, you know, do that. But, uh, if it is a very large, uh, scale application and if we need to look for the optimal performance, then I I think I should we should go with, uh, with the API uh, library like Xeo, or we should use React Query to integrate that because, uh, libraries like React Query provides, uh, caching, uh, strategies, and they provide, uh, you know, they they provide caching. They provide background fetching. They provide pagination. Uh, so all these things, uh, that we, you know, do not need to or we do not need to explicitly code by ourselves, and, you know, that they provide that kind of optimization, uh, implicitly, uh, toward to a developer. So I think if you want to integrate serverless API or a normal API as well, we should we should go with a library like React Query or maybe a library like SWR. And, you know, they provide, uh, a lot of performance benefits, caching benefits, and background fetching, and and, you know, pagination as and and a lot of, uh, new things to us. So I think we should go, uh, with those.

Okay. Below is a React component written in TypeScript. The component supposed to fetch and display a list of users from any key. However, there is a bug in the code and for the bug and fix it. Okay? Okay. I can see there is a component called user list, and we have a state users. We have another state of loading, then we have a use effect. And in the use effect, I can see, uh, this use effect is having empty dependency array. And, uh, first of all, we are setting our loading state to two, then we are calling the fetch. Dot then response on JSON. Okay. Then on dot then, we're getting the data, and then we are setting the users and set and we are, uh, setting the loader as false. Okay. And here okay. Okay. I think I got the error. So here in in the if condition, uh, we are checking if the loading is true, and then we are returning nothing. Yes. Here we are returning nothing. And if the loading is false, then we are so here we are not returning a JSX. Uh, we are, you know, directly returning an object. So it will give an it will give us an error that, uh, you know, we can't, uh, directly return an object from a component. We should return some JSX. So maybe we can wrap it with some tag, or maybe we can wrap it, uh, with the fragment, uh, of React. So that would solve the error.

In what ways does, uh, utilizing TypeScript's strict typing benefit and Node. Js backend API? Okay. In what ways does it tell you that it's strict typing benefit and Node. Js backend API? Yeah. Uh, so if we are using, uh, TypeScript on on Node JS code as well, uh, then it would give us, uh, the typing benefit, like, it gives us, uh, when we are, you know, writing, uh, TypeScript code in a in a React JS application or a front end application, uh, in in Node. Js as well, uh, when we are writing, uh, an API, you know, uh, and then we are using TypeScript, then it will definitely give us the auto suggestions, uh, you know, that what this API, uh, will accept as as a body if it is a post API or what parameters it needs. It will accept if it is a if it is a get API. So those static typing benefit it will give, uh, in case of, uh, you know, Node. Js backend API. We are using TypeScript for that. And TypeScript is very, uh, beneficial because it gives you, um, um, it tells you, uh, you know, these static errors upfront when we are writing the code. So, uh, it's it's a it's a good way to prevent a lot of, uh, issues if we are writing code in TypeScript rather than normal JavaScript.

Okay. Um, can you design a React component using Material UI that adheres to the solid principle? Yes. Definitely, we can, uh, create, uh, a React component using Material UI that adheres to two solid principles. And I think we always, uh, follow, uh, you know, solid principles when we are writing, uh, when we are writing code in general. So, uh, these solid principles, you know, uh, stand for, like, the solid, uh, solids s stand for single responsibility. And, um, this l stands for Liscove substitution principle. And this o stands for open close principle. So we should follow, uh, you know, we should always follow the solid principle when we are writing, uh, writing code for, um, for a real world application. Or in general, when we are writing code, if we follow these principles, then we will write a maintainable, readable, uh, and extendable code. And it will prevent a lot of bugs as well if we are follow following these principles.

Okay. What factors influence the choice of state management solutions in a large React application? Yes. Uh, so this question is a very important questions when we, uh, when we are choosing what statement and solutions we need to use, uh, for our large React applications. Uh, so I think, uh, this depends totally on on the application and on the use case that we are trying to solve. And, uh, you know, the choice to choose a third party library as a as our, uh, state management solution or if we are going to use a context API. That totally depends upon, uh, upon the type of application, upon the type of problem that we are going to solve that we're trying to solve. Um, maybe, uh, we do not need to use a third party library altogether in a in a in our use case, or maybe, you know, sometime we need to use that, you know, that library. So that totally depend on the use case of the problem and the nature of the application that we're trying to solve. So, uh, I think that would mostly influence, uh, on the choice of state management solution in in a large React applications. And I've seen, uh, it by myself that, uh, you know, sometimes we we overlooked, uh, this question, and, uh, we use a third party library. But in in reality, we did not need to use that third party library. Uh, instead, we could have used, uh, contact API or maybe we could have used use a sync external store hook, or maybe we could have used user reducer hook, uh, for, you know, having for solving this, uh, this particular problem. Uh, but we have introduced, uh, a third party library, and now we are, uh, maintaining a lot of, uh, code for that library. And, uh, we we need to, you know, um, we need to, uh, maintain that code. We need to, uh, have, uh, you know, that that we do not need, I think. So I think we should always, you know, carefully choose, uh, what what is the problem we are trying to solve and what, uh, library or what, uh, you know, functions, uh, that framework the front end framework, uh, that we are using is going to provide.

Okay. Your team is planning a refactor of an aging front end code base to a modern ReactOS architecture. How do you evaluate and prioritize the components for refactoring considering performance, maintaining duty, and business impact? Okay. Your team is planning a refactor of an aging front end code base to a modern edge architecture. How do you evaluate and prioritize the components for refactoring? Considering performance, maintaining business impact. Okay. Yes. Yes. So I have done this in my, uh, past as well. Uh, so I was, uh, I was refactoring an old front end application to a modern access architecture. So there, what we have done is we have, uh, refactored it, you know, uh, component by component. So we have used a component based architecture. So first of all, what we have done is, uh, we have created all the, uh, you know, all the common components, all the reusable components into React. So, like, all the, uh, all the atomic components, first of all, we we have created all the atomic components as as reusable components as a reusable React, uh, components, and we have created our design library system from that. So that in future as well, uh, or when we will actually start, uh, going to start the migration, uh, we do not, uh, you know, we'll not, uh, create these little, uh, or small components again and again. So we'll create those atomic components, and we'll create a a design library system, uh, from that. And everybody in the team who is part of that migration can use those reusable components. After creating those, uh, reusable components, uh, we'll go with the, uh, with the, you know, route by maybe, uh, if you if you if your application is having a lot of routes, we can go route by route. Or maybe what we can do is we can, uh, see what, uh, what component or what page in our application is is very, uh, slow, you know, and, um, we can pick those first. So and and and, you know, to choose what pages or what components need to be migrated first, we can, uh, use a strategy called or we can use a principle called Pareto principle, uh, which tells us, you know, what, uh, area we should work or or, you know, where we will, uh, put less effort less efforts and we'll get the more, uh, impact. So we can use that principle, and we can find out the areas where we should work first and where we should, uh, you know, optimize or the, you know, uh, refactor the component. Uh, so that principle can can tell us the, uh, the areas in, uh, you know, in our application. And, um, after finding those areas in which we need to work first, uh, we can, you know, go and and refactor that, uh, that component or page or, uh, to our modern React JS architecture in a component, uh, component based architecture. So now we have already in place our design library system. So we do not need to create everything, uh, from scratch. Also, we can use liabilities like material UI or shared scene UI components or Tailwind CSS to further increase, uh, our time to, you know, refactor that code, um, base to React JS architecture.

Okay. How do you set up a development environment to work with both the JS and Node. Js efficiently? Okay. So to set up a development environment to work with both the JS and Node. Js, we can uh, use, you know, a lot of libraries that are available. Uh, if you want to create a full stack application, uh, we can we can maybe use Next. Js framework because that provides the edges and node JS environment both. If you do not want a full stack frame if you do not want to use our full stack, uh, framework like Next. Js, what we can do, we can have two separate projects, uh, of React and Node JS. We can set up a React JS project with Vite, you know, build tool, and we can set up a Node. Js tool separately. And, um, or maybe we can use p n p, um, you know, PNPM to, uh, uh, to handle and then when we can create a monorepo, uh, kind of architecture where we are having our React JS and Node JS, uh, projects, uh, handle as a monorepo. So there are, you know, plenty of ways by which we can, uh, set up and manage our Node JS, uh, development environment efficiently.