Sandeepa singh

I'm Sandeepa, a senior software engineer with expertise in front-end development. I've primarily worked with React, JavaScript, HTML, CSS, and JavaScript, as well as React Native for mobile applications and Android and iOS development. I've worked with CSS, SCSS, Material UI, and Semantic UI, among other libraries, over the past five years. In that time, I've created apps from scratch and deployed them to production, serving millions of users. One such application is ClassPlus DIY. As a front-end team lead of 14 engineers, we deployed to production on a daily basis, or at least weekly. I've also worked with Method and Bottle, as well as the Waterfall method, but my primary work has been with Jira and Figma on front-end design, which helps us design large-scale applications. Additionally, I have experience in team management. Over the past two years, I've led a team of four to five developers. Currently, I'm also managing a team of three developers and two front-end interns. That's about me.

So okay. Tailwind CSS as a speedy development tool helps us in developing applications speedily. Instead of switching between HTML and CSS files, we can directly use it as a markup CSS, like design and directly markup, and we can use it directly from there. Through the help of Tailwind CSS, we can highly customize our application. That is not possible with traditional CSS methodology even with CSS. Or, a major drawback that I have faced by using a UI or semantic UI was when we have to make a component customizable. Let's say we are using a button or a modal. When we have to customize it, then we have to override their internal CSS a lot. Like, by let's say there is a div inside a div and inside a div, and then there is a label. So we have to drill throughout that label to customize it. That is very easy with Tailwind CSS. So Tailwind CSS is making the development process very quick instead of traditional CSS methodology and utility-first approach altogether. So, you know, the development process is enhanced and drilling through a component to make it customizable is very easy in building CSS altogether.

API is a way in React to pass, is to store your variables or store your global or, like, store your variables or constants globally and leverage them throughout the application. It is an effective way to produce global variables that can be passed throughout the application rather than and it helps a lot in reducing the prop drilling. Initially, we had to prop drill a lot for, like, if we wanted to use a particular state inside a child or grandchild component, then we had to pass it from grandchild to child and then to parent and so on. By using React Context API, we can easily store it inside a global variable and use it anywhere. If we have a parent and we want to use a particular date, let's say, in the child component or inside the child of a child component, a grandchild component, we don't have to pass it down through the help of props. We can directly call it from the store. And Redux is also a similar kind of way to reduce prop drilling and storing variables globally. But Context API is somehow more effective than Redux itself because in Redux, we have to use actions, use a reducer, and then the store. So for saving a particular component in a store, we have to call an action, and the action will call the reducer, and they'll do the complex calculation, and then it will get to the store. But in React Context API, it's quite easy to store a variable globally.

Within JavaScript, how do you ensure browser compatibility across major web browsers? Okay. So, if you want to ensure compatibility across major web browsers, first, you have to use those kinds of libraries or HTML contexts that are global and compatible throughout the browser. Let's say, don't put some hacky kind of thing to work on Safari, for example, and that will definitely break on Microsoft Edge, like, Microsoft Edge. There are many functions in JavaScript itself that will not work on Microsoft Edge. Like, set timeout, set interval, sometimes work glitchy on the Edge. So while working with those functions, you specifically manage those states for Microsoft Edge as well. Like, I'm using a particular JavaScript function that I know will not work on Edge, then I will definitely put a check on it. Like, okay. Or if the browser is Edge, then do this instead of that. You know? Do different calculations and show different results. Although the output will be the same, but the calculation and the process will be different. That thing, we have to keep in mind when using JavaScript. Like, any JavaScript function that we know will not work on different web browsers. And, but what I personally do to check cross-browser compatibility is while making an application, I simply code and do dev testing on major browsers like Firefox, Edge, Safari, and Chrome, so that will ensure if all the things are intact or not.

Okay. So, personally, I have worked with CSS Grid and Flexbox both. So, Flexbox is usually used in mobile applications, and their grids are not possible. So, we use Flexbox a lot in mobile applications. So, the major difference between the grid and the flex box is that CSS Grid usually divides the whole screen into 12 grids. And in those grids, you can easily put your data in, like, put your components in. And from there, you can manipulate it. But in Flexbox, it gives you a major flexibility in terms of, okay, you want to let's say, there are three components, three boxes that you want to show on the screen, and you want to show them directly, like, between an equal square distance, you can simply apply a CSS on the parent component, like, display flex and justify content space between. It will automatically make the space between the three components equal. There, that is the time when Flexbox comes in handy. While CSS Grid is definitely useful when there is complex table components or components that we have to put at a certain position. Like, we have a grid of 12. Right? Then we want to show, okay, this particular box should stay here only, not depending on the browser, not depending on the screen or the width of the screen. It should not change. It should come at a particular place, then we use CSS Grid. Flexbox is handy when you have flexibility, like, okay, we want to show it here and here. That will work. Does the space between them need to be equal? When we have such a kind of requirement, we use Flexbox.

Stateful components again. Definitely. So I use just for unit testing, in. So in just what I do is when there is a stateful component, right, when we have, let's say, a component that is having a modal component, that should be shown on the button click. So for handling such states in unit testing, you have to define. On first, give data test ID to everything. If you want to, see, if the model is appearing on that button click or not. So, make a fireEvent on that button that you want to, let's say we will name a button called show model, and it has a data test ID show model. Show model, something like that. So, in the unit test cases, just try fireEvent.click. Your data test ID is show model. If that fired up, then apply the case. Okay. After this, let's say our modal is called beautiful modal. Then after that case, just write. Screen.getTestID('show model').fireEvent.click(); screen.getTestID('show model').getByText('Beautiful Modal').toBeInTheDocument(); In the unit test cases, just try fireEvent.click. Your data test ID is show model. If that fired up, then apply the case. Okay. After this, let's say our modal is called beautiful modal. Then after that case, just write. Screen.getTestID('show model').fireEvent.click(); screen.getTestID('show model').getByText('Beautiful Modal').toBeInTheDocument(); I am personally using Jest testing library for this. We can do the same with Cypress as well.

An API call is made in the rear conference, but there is a comment best after that is not being followed. Can you identify it and show how to improve it? Definitely. So it is class user details extend. We have component from the sector testing and user details. Okay. Component and noise that we are using an API. It is having the data. There's dots at state. User details data. Loading thoughts. Okay. Seems good. An API call is made in the React components, but there is a common that is not being used. Can you identify and show how to improve it? Okay. So it seems okay. So firstly, we are using React, previous React version, like, 14 or 16. No. Not 16. We are using React 14th here. That's why we're having class component. Okay? And in component did mount, so there is in constructor. We are making a state called user details unloading. And after the API call in the component in mount, we are using then response dot JSON then. We are setting the state. Okay. So there are a few issues with this. So while making an API call, the first thing first, we have to put it in the try catch method. This is this will work in the best case scenario. Let's say your API is giving you perfect data response, and you are storing that data in the set state. But what happen if that API is not working? The API is giving 500, 400, 404. Anything can happen. Right? So we should firstly put that put this API call in the try catch block, and, we should address the error. If it doesn't catch block, we should maintain a state for that also, and, we will we should show some toaster or some error message on the screen. Okay. The API is not working because of the following thing. Let's say the data is not this is just a good API, so that will not be the case. Payload is correct only. But let's say if something happens, like, Internet connection is not proper or maybe the API internal server error is there. So we should catch that in the catch block and show the error. Otherwise, what will happen, this will break and a blank screen a white blank screen will appear on the, application saying something went wrong. That will be very, you know, bad user experience. We should handle the catch thing, like, error in the catch block. So that is missing here. And, when doing component and mount, and fetching the API, that is all correct. if we are using any set loaders or anything, we should do component and dot mount as well, but that seems fine only. So major issue is that we are not handling the error cases here. Yeah. That seems good.

Template and then loading user data. Okay, so this is we're done. For default. Okay. Inside the data, it's been returned. If it did not create an API then catch. Okay. Better catch. Then. Okay. So the major issue with this is we are not putting inside a try catch block again in creator. We are doing the catch before then itself. Like, first, we are doing then response to our JSON. That is okay. And then we are using dot catch. This dot error goes to true. And then we are doing dot then data and saving the data into user data, which is completely wrong. Firstly, the statement should be for dot then response dot JSON, then again dot then data, this dot user data dot data is equals to data, then cap statement should be there because this is breaking the whole method. You know? We are using a promise. Let's say if we are calling the promise fetch here, the API call, and then we are using then we are resolving the promise. And before we are applying catch and then we are resolving the promise, this will break the whole flow of it. So this statement created one is correct, but itself is wrong. And second thing is we are using user data dot name, and we are not saving user data dot name anywhere in the application. We are using this dot user data as goes through data. We are not sure if the user data contains something called name. Right? We are not sure if the data coming here is an object which has name. So what will happen if the user data dot name is not there? Again, the application will break and completely white screen will be. Come on. So we should apply optional chaining in user data dot name to in the port line, we are using p. Right? P v l's, p tag inside the v l's, and then user data dot name, we should apply user dot optional chaining, question mark operator dot name. That is two of the things that are wrong with this.

Okay. What strategies can you employ to manage React application state in a large-scale React application? Sure. So in React, in large-scale React applications, I use personally use Redux to handle the states globally. That is one thing. What strategies can you employ to manage application state effectively? Okay. So application state is first and foremost, we use state hooks for handling a state that is used inside that particular component only. Let's say for a model or a button or smaller components, we'll use state to store the component's state. Let's say if there is a show model, set show model, and on that show model comes through, the model will appear. All those things, all those states are handled locally in the state variables. But for the states that we have to pass down again, from the grandchild to grandparent to child to parent to child, and so on, for those states, I use Redux for storing the states and making it global. And throughout the application, we can use those states. So that is one thing that I personally employ for the application state management in React in large-scale React applications. In large-scale React applications, it is very important to have global states because, let's say, on a button click, you want to show a side menu. Right? But you want to show the side menu again when you click on a file, like, for example. Or you want to show similar kinds of side menus when you are doing some other actions. So if a particular side menu has three action buttons, you cannot use local states and pass it down again and again. You have to use the global state that is responsible for that, but for that side menu to show up. That is very important to manage the global state. So what I do is I create a global file called store. In that store, we have actions, we have reducers, and we have the store itself where all the variables are stored. And then in every file, in every feature, every small feature, we have actions and reducers to call that state or to store something in that store. And through those actions and reducers, we again store all the data in the global store.

What experience do you have setting up? See if we do find friends for the app applications. Okay. So for React applications, I have, used to kind of, two methods of deployment. 1st is through NGINX. That one is a very old way to handle it. So, for our internal portal, like, for staging, we have NGINX to deploy the applications on. In NGINX, it is very straightforward. You go to your Ubuntu, log in there, and then set up your variables and then push the code on production or staging, wherever you are using. And there are other ways, you know, to say Jenkins, that is very popular, or you can deploy through AWS, but I have no experience with that. I have done it through Jenkins. In Jenkins, once you have written the script to manage your CICD pipeline, then it is very easy to just click a button to trigger the new build, and it gets triggered. You can pull back, you can roll that back as well. You can stop in between if you think that particular feature will break down. So in Jenkins, that is very easy. Oh, yeah. I remember. The 3rd way is through Versal. So there was our internal CRM tool. We were using Versal to deploy it because the users were internal users only. So we did not think to buy a paid service. For that, we use Versal. In Versal, it is very easy. We have integrated it with GitHub. So if any of my PR contains the starting prefix of hotfix, enhancement, and feature, you know? If any of my branches are features/slash this, enhancement/slash this, or hotfix/slash this, it automatically creates a new link for after deployment, and it will create a new link for Versal, and we can simply give that link to the tester or the quality team to verify the usage. That kind of practice comes handy when you are using hotfixes only, and that is why we have to go on production immediately to just stop the whole process. You can simply cut out a branch from production. You can do a small deployment on Versal. Just get it tested there and then you can simply merge that branch inside the production branch itself. So that helps a lot to maintain our CICD pipeline as well as maintain a good branch flow. So that, you know, let's say you have some kind of code that you don't want to deploy on staging. You don't have to cut a branch from staging, do a hotfix there, and then go to production. You can simply cut out a fixed branch from there and deploy it onwards. I'll get it tested there and then push it into production.

How would you utilize AWS Cloud Services to deploy a static application with maximum availability? So, personally, I don't have any experience with AWS cloud services, but to deploy a React application with maximum availability, and that is that was static, React application. So for static React application, I don't think we have much to worry about. We can simply, deploy it through whatever the AWS process is there. I'm not very sure of that. But we can simply deploy it because it is a static website, so we don't have to, you know, think about, the load or the load it gonna cost to server because there is no back end DPA calls. There is no server connection. So the costing of the server or the load of the server will be the minimum in this case. So I think it will be, easy process to deploy that. Again, not sure. Thank you.