Shivansh Tyagi

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

Discuss how you would handle routing in a single application using React. One of them is using React Router library. If it's a web application, I would prefer to use React Router as it is not a file-based router. I prefer not to use a file-based router as it is very complex to manage. If I had to use a file-based router, I would prefer to use Next.js as it has the best implementation of file-based routing and server components that exist till now. So, I'll have a primary router in React Router. In that, I'll have home and about all the pages that I require to exist. I'll also have private routes, which will basically be protected routes that should not allow a user to go into if the user is not logged in. Apart from that, I'll have a default route so that if a user arrives on a non-existent route, they will be directed to a 404 page that basically tells the user that this is not a valid path that they have visited, and they need to go back. So, these would be my approach to handling routing.

What is the use of React Hooks, and how do they perform class components? Lifecycle methods. So, React Hooks, and component lifecycle methods are entirely different things. Some React hooks can be a replacement for React component lifecycle methods and function functional components. So, the thing is, for React Hooks, there is a React use many hooks like useState, useEffect, and many hooks as a replacement to the lifecycle method. So, there are many lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount, and there are many corresponding hooks for them. For example, all of these three lifecycle methods can be handled with a single hook that has called useEffect. So, to mimic a componentDidMount, it will require a dependency array that, so that the callback that we provide to it runs only when any variable in the dependency array has changed. If we want it to work as a componentDidMount, I'll have the dependency array empty. And if I have to use it as a componentDidUpdate, I'll use the same useEffect and return a callback from it. The callback I'm providing to it, I'll return another callback from it so that it would run the cleanup function for that. If and it goes both ways. It will also work on it use of it without a dependency array with some variables in it. So, the basic use case is just to provide cleanup, so that the user can perform necessary actions like removing event listeners and removing all the strings that are entered in a form. There are many use cases for that. So, the main difference is the component lifecycle methods are used in class-based components, 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, I would assume that it is using plain HTML, CSS, and JavaScript to render all the pages. It is really an old way to approach creating a website. So what I would do is first, earlier it used to be that each route in a page used to be an HTML page. And if the user had to travel from one page to another, it would have a loader, and it would go to that page after that HTML was 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, what happens if I go to another page in React? It would just load that section, and it would bring it. It won't need to load the entire page again. So, first of all, I'll make a list of all the routes that existed, all the HTML pages that existed. I'll make route files for all of them. I will see what JavaScript was needed to be run on that. I'll make a list of all the JavaScript that is required. Instead of just taking the JavaScript, I'll prefer to manually translate all the pages into React, such as I'll take the HTML and put it as JSX. I'll take the JavaScript and take the same functionality as it won't be that hard to reimplement it. I'll take that and insert the functionality into the page again. And CSS would be pretty straightforward. It can be plug and play, just like the way it used to be. It can be done after that as well. This would be the fast way of doing that. Ideally, I would prefer to rewrite the whole website in React, as it would be much more manageable in the future. And if this question is about migrating a class-based component to functional components. It's just about React state lifecycle. Okay. So, React also provides a way to store all the variables and data in state and props form. I would be able to utilize those, and also the lifecycle methods. If one page is about to update, I'll be able to undo all the changes that I have done per page, and also react to any changes that might be happening on the page. I'm using component updates. And if I have to fetch an API, I can use component did mount. The whole process seems to be coming together very well compared to a legacy JavaScript code base.

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

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

I'm looking at the React components in a blue. Can you identify and explain any violation of the SOLID principles? Just a second, I'll check the user profile. Okay. I don't see any violations and very apparent violations in this. The only thing I can 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. It's only on the 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. 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. if I come back to this after, let's say I visit another, route and another component is, I'm I go to another component and this then come back to this. This certain table will keep, running until the end of the program. So, the thing is that it should the unmount state should also be handled. And, if I'm when whenever these components are unmounting, I should, clear interval on the I should run clear interval on the timer ID.

I would design a React application to be modular and reusable with adherence to SOLID principles as follows: We can separate each module to only have one function. For example, if we have a form, the text box should only have the functionality of the text form or text box and know no other functionalities. For instance, data fetching should not be happening for the text component. All the business logic should be separated into hooks. We can separate it into hooks. All the frontend logic should be in the component, and it should receive all the data required to render each component through a hook or another service or from Redux. Basically, anywhere other than being evaluated in the component itself. There should be no business logic in the component at any point of time. If we follow this for the entire app and for all of the components that we send out, it should never have an issue of having a 1,000 lines of code in a single component and where it then becomes very difficult to navigate through the code. I would keep a separate common component for the text box so that I can use that throughout my project, wherever I need the text box with that same design. Or I can have multiple sets on that same text box so that it can switch its designs if by a single flag as well. For example, we can have a separate hook for data fetching, a separate component for the text box, and a separate component for the form. This way, each component or hook will have a single responsibility and will be reusable throughout the application.

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

What is your approach to implementing accessibility standards in your front end? Okay, so many browsers themselves handle most of the accessibility part, such as narration and all. I prefer to add ARIA labels to relevant components, which might be helpful to the browser to access. For example, if I have a heading, I'll have a 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 use services to translate my application to other languages. I can go two ways about this. I can either hire language specialists and have strings for all the web pages in formats such as a config set for all the strings that I have on the website, or I can use services that use AI to translate all the web pages and give me a translated page. For example, if someone is vision impaired, my labels can help them out. If someone is hearing impaired, I can implement text. And if there's a video, I can implement subtitles. And if there are any other accommodations I need to make, I'll take care of that scenario as per their requirements. We can also have accommodations for color impairment problems like color blindness. We can have themes enabled throughout our page, which can help us have different colors for different sections of the page.