Shivansh Tyagi

So, uh, I'm Shivansh. Uh, I am currently working as a front end engineer at housing.com. Uh, I am currently working on the owner monetization part. It basically deals with an owner's journey to post their properties and sell it on the platform. Before this, uh, I used to work in a startup called Aviros. It is a video analytics startup which basically takes care of, uh, many, uh, use cases such as number plate recognition and vehicle identification and classification and facial recognition and many such use cases. Uh, so I built a vehicle classic I have built many applications for them, one of which was a vehicle classification and counting system, which was deployed on a major highway called the expressway, uh, in NCR region. It was a live project, and over 50, 60,000, uh, vehicles pass on that highway every day. And the app basically, uh, suggests, uh, what the make, model, type, and color of the vehicle is along with its number plate, registration number. Uh, it's displayed, uh, as live alerts on the in the table that they had. Also, all the live streams of all the cameras that were required to be present was visible, and there was also a report generation feature, uh, there as well. So, yeah, these are some of the projects that I have worked on. Uh, I'm I work primarily on React, Redux, JavaScript, uh, port basis, but I also have experience with TypeScript and React Native projects. And, also, expo, uh, with React Native as well. So, uh, yeah, this would be a brief introduction about my background in front end engineering.

Discuss how would you would handle routing in a single application using React. So there are many ways to go about this. Uh, one of them is react using React router library. So, uh, if it's if it is a a web application, I will prefer to use React router as, uh, it is not a file based router. I prefer to not use a file based router as it is very complex to manage it. If I had a file based router, uh, I've if I had to use a file based router, I would prefer to use Next. Js as it has it has the best ex, uh, implementation of file based routing and, uh, server components that exist, uh, till now. So I'll basically have a a primary router. In React router, I will have a primary router. And in that, I'll have home about all the pages that I required that required to exist. I'll also have, uh, private routes, which will basically be protected routes that, uh, should not allow a user to go into if it's, uh, if the user is not logged in. Apart from that, I'll have a default route, uh, so that if either I'll have a default route or I have a 404 page that basically tells the user that this is not a valid path that you have visited, and you need to go back or I'll give I can I have many options, uh, if users arrive on a nonexisting route? So they, uh, these this would be my approach to handling, uh, routing.

What is the use of React Hooks, and how do they perform class components? Lifecycle methods. So, uh, React Hooks, uh, and component lifecycle methods are entirely different things. Some React hooks can be a replacement of, uh, React component life cycle methods and function functional components. So, uh, the thing is, uh, for React Hooks, uh, there is there React uses many hooks like use, uh, state use effect, use call layout effect, and many, uh, hooks as a replacement to, uh, the life cycle method. So, uh, there are many life cycle methods like component uh, date amount, component will date update, comp component will unmount, and there are many, uh, corresponding hooks for them. For example, all of these these 3 component live cycle methods that I mentioned can be handled with a single hook that has called useEffect. So, uh, to mimic a component date update, it will require a dependency area that, uh, so that the callback that we provide to it runs only when, uh, the any variable in the dependency area area has changed. If we want to if we want it to work as a component inbound component, I'll have the dependency area empty. And if I have to you, uh, I have to, uh, use it as component well and more, And I'll use that same, uh, component did not use effect and return a callback from it. The callback I'm providing to it, I'll I'll return another callback from it so that, uh, it would run the cleanup function for that. Uh, if and it goes both ways. Uh, it will also, uh, work on it use of it without a dependency error with some variables in it. So, uh, the basic, uh, use case is just to provide cleanup, uh, so that the user can perform necessary actions like removing event listeners and removing, uh, all the strings, uh, that are entered in a form. There are many use cases for, uh, that. So the main difference is the component life cycle methods are used in class based components, and the and and React Hooks can only be used in a functional function based component.

This was the pause process of migrating a legacy JavaScript code base to React, including handling data life cycle methods. Okay? So if a project is based on legacy JavaScript, uh, I would assume that it is, uh, using plain HTML CSS and, uh, JavaScript, uh, to, uh, render all the pages. It is, uh, really old way to approach that, uh, approach to create a creating a website. So what I I would do is I'll first earlier it used to, uh, each route in a page used to be an HTML page. And, uh, if the user had to travel from one page to another, it would, uh, have a loader, and it would go to that page after that HTML is, uh, done loading. So it would basically be another link, not just another route. It would be another link. It would act as another link. So, uh, what happens if I go to another page in Reactors? It would just load that section, and it would bring it. It won't need to load the entire page again. So, uh, first of all, I'll make a list of all the routes that existed, all the HTML pages that existed. I'll make, uh, route files for all of them. I will see what, uh, JavaScript that needed to be run on that. I'll, uh, make the list of all the JavaScript that is required. I'll firstly, uh, instead of just taking the JavaScript, I'll, uh, prefer to, uh, manually, uh, translate all the pages into, uh, React, uh, such as I'll take the HTML, put it as JSX. I'll take the Java I'll take the same functionality as JavaScript as it won't be that hard to, uh, reimplement it. I'll take that, uh, and is insert the, uh, functionality into the page again. And CSS would be pretty straightforward. It can be plug and play, uh, just like the way it used to be. It can be, uh, after that as well. This would be the fast way of doing that. Ideally, I would prefer to rewrite that, uh, whole website in React, uh, as it would be much more manageable in the future. And if I had to if this question is about migrating a class based component to no. It's just about React state lifecycle. Okay. So, uh, uh, I also, the React as React provides a way to store all the, uh, variables and, uh, the data in state and props form, I would, uh, be be able to, uh, if I am if I'm re rewriting it, I'll be able to use utilize those as and also the life cycle method. Add as if one page is about to 1 month, I'll be able to, uh, undo all the changes that I have done per and, also, I can react on any changes that might be happening on the page. I'm using component update. And if I have to fetch a fetch an API, I can use component. The whole process seems to be, uh, coming together very, uh, good compared to a legacy JavaScript code base.

Okay. So all of this, uh, search engines basically require a fully rendered, uh, HTML page on the first load itself. So, uh, the main requirement is that they require, uh, the page to be server side rendered so that they can crawl through all the data as the crawler won't wait around for the page to be loaded completely. If this was the case, and then then it would, uh, be easily exploitable by many bad characters, uh, as it would infinitely keep loading and the crawler will will keep waiting and be occupied. It would be a bad way to hand go about things. So, uh, it basically expects a fully rendered page. So I can, uh, I can basically render a page, uh, through servers or server side rendering. I'll fetch all the props that are required, uh, required for it. I'll fetch all the APIs that are required that can influence the page in any way. And, uh, at the end, it should be the fully rendered page that the, uh, search engine is receiving. And if, uh, there are any dynamic content updates, they they should be handled. Uh, they are pretty easy to be handled in the server side rendered component unless it is a static side generated project, uh, page. Uh, if that is a static page, uh, then then it would require a new build to be sent. But, otherwise, uh, it's pretty straightforward to handle, uh, if we, uh, we can set a flag so that uh, things don't move around. If we can handle anything set with that flag that how this should look, uh, when the bot is talking through it. So we can expand all the, uh, closed tags. We can just make everything visible so that the bot has an easier time to scroll, uh, to crawl, and we can give appropriate tags to all the things that the, uh, crawler might be looking for, such as h one tags, h two tags, and all the corresponding tags that the crawler uh, looks for to, uh, find important pointers for that page.

What are some techniques you use for writing cleaner common JavaScript code? So, uh, this all comes down to, uh, semantics. Uh, I prefer to write a cleaner code than a smaller code. Uh, also, uh, a little bit of, uh, algorithm knowledge is also required to write performance JavaScript code. So, uh, we need to look out for how many, uh, times this, uh, how many iterations might this take to evaluate this data. Uh, we always need to be on a lookout for, uh, this information as it might, uh, affect performance by a lot. So I have optimized many functions that existed in the code base from 0 n square to 0 n and at a few times also to o one. So, uh, I'll prefer to make the code more performant. For writing clean code, uh, I prefer that each code, if not understandable by a first or a second look, it does not it does not seem to me that it is a very clean code. It has to be understood by everyone on the first look that what, uh, that code is doing. Uh, that is the main point that I keep in mind while writing code. That if a next developer is going to come on come and work on this, they should not have find any confusion that what I'm currently doing here right now. So, uh, uh, yeah, these would be some techniques that I used to, uh, write lean code. Uh, nowadays, we also have some tools like, uh, ChargeGPT and, uh, GitHub Copilot, which can which if we write a code, it can make it can help us clean that, uh, code to be more readable or more optimized, and we obviously need to, uh, have some discretion at the end on ours or on our end. But the thing is, uh, that they are the tools are helpful, and they help us achieve what we are trying to achieve, but it also requires the full knowledge of what's going on on our end as well.

Looking at the React components in a blue, can you identify and explain any violation of the solid principles? Okay. Just a second. I'll check the user profile. Okay. Okay. I don't see any violations and very apparent violations in this. The only thing I can, uh, think of is a single responsibility principle as it all is it is also fetching the data and also rendering the data at the same time. Otherwise, I don't think there's any violation in it. Uh, it is on only, uh, wallet.

Can you identify the potential bug in this layout component slash cycle method that can suggest a possible fit and suggest a possible fix? Okay. This dot state dot current data dot tool location is time time. That's basically a timer function. It will basically we call it this, and it would keep setting the new date to current date. The potential bug is might be that. No. It's the intended feature. The only issue that I find with this might be that there's no ending of that set interval. Uh, if I come back to this after after, uh, let's say I visit another, uh, route and another component is, uh, I'm I go to another component and this then come back to this. This certain table will keep, uh, running until the end of the program. So, uh, the thing is that it should the unmount state should also be handled. And, uh, if I'm when whenever these components are unmounting, I should, uh, clear interval on the I should run clear interval on the timer ID.

How would you design a React application to be modular and reusable with the adhering to solar principles? So, basically, with the re with with any React application or any, uh, component based, uh, library that, uh, exists, Each module should only be, uh, having one function. For example, if I have a form, the text box should only, uh, have the functionality of the text form or text box and know the functionalities. For example, data fetching should not be happening for the text component. Uh, and everything should be segregated into sep smaller components altogether. For example, all the business logic should be separated in hooks. We can separate it into hooks. All the front end logic should be in the component, and it should that all the date required data to render each component should be provided to that component through a hook or, uh, another service or or from Redux. Basically, anywhere other than, uh, being evaluated in the component itself. There should be no business logic in the, uh, component at any point of time. Uh, so if we follow this for throughout the app and for, uh, all of the, uh, components that we sent out, it should never have an issue of, uh, being a 1,000 line line of code in for a single component and where it then becomes very difficult to navigate through the code. So, uh, this would be how I I would go about designing a React application to be modular and reusable. For example, I mentioned the text box. I'll keep a separate common component for that text box so that I can use that throughout my throughout my, uh, project, wherever I need the text box with that same design. Or I can, uh, have more set on that same text box so that it can switch your designs if by a single flag as well. So that would be, uh, one way to, uh, go about adhering to solid principles as well as creating a modular react, uh, application.

In what ways do you optimize the React application for mobile considering performance and user experience? So, uh, the way I like to go about things is that I prefer most of my application in at least in my current company. The experience is preferred to be, uh, mobile first. We separate mobile and, uh, desktop components. We don't, uh, have, uh, conditions condition based switches based on, uh, the type of device we're using. We basically separate out, uh, all the components in mobile and desktop so that the bundle size can be, uh, can be reduced by a lot for, uh, both of them both of the cases. Uh, for the user experience part, I prefer the experience to be responsive. The application should always be responsive for the user. It should not I prefer it to not have fixed dimensions, uh, and I I prefer to adjust the dimensions based on the user's device. Regarding the performance part, it is the utmost priority that there should not be any, uh, CLS after more I prefer the number to be not more than 0.002. Uh, that is the standard that I have set for myself. Uh, I would prefer I I'll check what can cause the layout shift, uh, through the performance tab. I would see that if any components goes out of the, uh, DOM tree and then comes back in, it would it might cause a layout shift. And I'll check every component and, uh, fix the height for what it should be when the component is rendered. I would not prefer to have any layout shifts, uh, when the user is receive working on it as it creates a very, uh, bad experience. I would also, uh, optimize the images as those take up the most time to be loaded. I'll have loaders, a lower side resolution image, uh, and then, uh, if the higher resolution image is loaded, I'll replace it with that. So and if mobile, uh, components need to be optimized for 2 scenarios, when the keyboard is open and when it is not. So in both of them scenarios, the component should not break or the whole page should not have distorted UI so that the user does not user has the best experience while, uh, navigating through our app.

What is your approach to implementing accessibility standards in your front end? Okay. So, uh, many browsers themselves handle men more most of the accessibility part, such as narration and all. Uh, I prefer to add ARIA labels, ARIA labels to uh, the comp relevant components which might be helpful to the browser to, uh, access. For for example, if I have a heading, I'll have an relevant ARIA label for it, and the browser might have an easier time identifying what information is important on the page. And I can also have a service I can also use services to translate my application to other languages. I can go 2 ways about this. I can either hire each language specialist and, uh, have strings for all the web pages that I have in in formats such as I'll have basically a config set for all the strings that I have on the website and have a language specialist go through them, or I can use services which use AI to translate all the web pages and, uh, give me a translated page so that the page can be accessed anywhere in the world or anywhere in the country itself, uh, as India has over 2,000, uh, languages and dialects. So it would be very helpful to have a service like that set up for, uh, translating into multiple languages that exists. For example, uh, for let let's say if someone is vision impaired, are your labels can help them out? If someone is hearing impaired, I can implement texts. And if there's a video, I can implement subtitles. And if there are any other accommodations I need to make, uh, I'll and my target audience falls into that. I'll take care of, uh, that that scenario, uh, as per their requirements. Also, we can all if there if someone has, uh, color impairment problems like color blindness and such problems. We can also have accommodation set for that as we can basically have themes in enabled throughout our page, which can help us out to have, uh, different colors for different sections of the page.