Abhay Gupta

Yes. So, hey, my name is Abha, and I'm working as a front-end developer. Like, I have around 4 years 9 months of experience in the front-end development domain. So, from the start of my career onwards, I've been working with React JS, HTML, CSS, and JavaScript, then later on, I picked Next.js because it is, like, a much better version of React in its entire framework, whereas React is, like, green only. And it also provides server-side caching and all those things, such as server-side rendering, static-side generation. So, that's why, I started working on Next.js also, which is also built on React. And, recently, I'm working with Zuma, which is like a proptech, a company-based startup, which is funded by Viacom, and recently, they have closed their series A funding. So, I was the lead front-end developer there, and I built many of the applications from scratch. So, the first was the inbox. The inbox is basically just like a WhatsApp messenger app where the users can just communicate with each other seamlessly. And the users here were, like, one of our agents and the customer, which we were dealing with in a B2B space. So, the customer can send messages, and our Kelsey, which is our, like, AI chatbot, was unable to respond. So, then, our agents would come into the picture, and they'd just reply on behalf of Kelsey. So, apart from real-time conversations, it has around 38 to 40 features, which include appointment booking, scheduling links, and the user wants to update any of the information or, like, his or her preferences for the unit in which they are supposed to move, and some more options, which we can, like, give around the budget or the preference or the area selected by the user. So, apart from that, this was one of my projects in which we used GraphQL, React, HTML, CSS, and all those technologies to the REST API. Some of the APIs were, like, built on the REST API. So, yeah. And, apart from that, I was recently leading a team of analytics team dashboards, like analytics dashboards where the users can visualize the performance of Zuma on their entire portfolio. Like, it's like the number of messages, the users, the number of messages that Kelsey has sent to these particular communities or to these clients. They can just log in to the dashboard and they can see, then they can manage the users that, portal users will get access to the dashboard and what sort of permissions they have. Then, we have the skill connect where there were some questions for each community, and there were specific answers for each community. So, whenever a community is going live, then, those answers will automatically be fetched by the, Kelsey, so that it helps in, like, building a database and making Kelsey more accurate. So, yeah, this is all about. And, before that, I was working as a front-end developer in Angara E-commerce and World of Fashions Private Limited, whereas in Angara, I was, like, responsible for being part of the team that was responsible for migrating the site, the entire PHP site into Next.js, and I was handling their product page, cart, and checkout page flows. So, this is all about, my journey of my entire career.

Yes. So JWT is basically a token-based authentication which most apps in today's world use to do the authentication and authorization of that particular user. So let's just start the flow. I'm a user, and I'm going to a site which requires a login. Without login, I can't access much of their functionalities or it's such a bare minimum criterion that first you should log in, then only you can access certain things. This is also called a JSON Web Token, which we store the user's information in some sort of encryption so that no one by just looking at the token can analyze what are permissions, or what is the username, or what is the user's email, or any sort of sensitive info. We're not letting anyone make that visible on the UI. So let's say someone is coming in. Let's say my name is Abhin. I won't log in to a particular site in which I have already registered. So I'll just go, I'll just type my name, password, whatever the login flow is there, and then I'll get a web token. That web token will be responsible for communication between my front end and the back end. So whenever I want to fetch the number of users my org has, I'll send the REST API, like, let's say, slash users with that JWT token. Then at the back end, they'll analyze whether I'm authorized to perform this particular operation or not using the permissions defined in the JWT token. If I am allowed, then I'll get the data. If I'm not allowed, the server will throw a 401 unauthorized error. And also, it has an expiration time, which after eight hours I have to log in to the system again. If I go to the site and I try to access any of the APIs or any of the pages, then they'll just directly throw me a 401 saying that your token has been expired. This is kind of a system which is required for the security of the site so that no one can manipulate the digital token or no one can access our site without having the proper permissions or authorization. So this is all about the strategy of JWT token in React.

Display method 2 unit test unit test. We have to confirm that logs on. Okay. So one of the methods is, like, in React components to write, your test cases, which is using the context. So what we can do is we can just move the entire context, which has been, like, which we are importing from let's say there is a component there, which is importing the context provider and we are using some of the properties of that particular context. So instead of just going and writing the entire context flow, what we can do is we can mock the entire context in the unit test cases. And not exactly the entire context, but whatever the values our component is using that we can mock. And once we have done the mocking of that particular values or the context provider for that particular context, then we can just simply use the variables and then add their own test cases to see whether the value of these particular properties are best, then their results should be equal to that particular thing. So I think just by mocking, we can simply achieve this.

I'm just using Jest to simulate browser events, and yeah, to test. So I'm giving you let me think how you can use just to simulate browser events via unit test. So browser events are mostly like, let's say, the DOM events are handle click or any other sort of events provided by the browser. We can just simply write mock functions for all those unit test cases that check if these functions have been called, then use these mock functions instead of the regular functions, and we can simply achieve whatever we want to do with those functionalities.

What style do you follow to ensure we have shared management logic as a robust and maintainable contact? So I think there are a couple of techniques to ensure that the React suite management logic is robust and maintainable. So, first, one is we can use the Redux toolkit in which we can create the store. We can create the dispatch functions or the dispatch events, and there will be one more file which will be holding the states, whatever the states are with, and they'll be associated with each dispatch function. And, initially, we will be having all the initial values for all these states, and we can just directly write the use dispatch, get this particular thing, and it will go to the store. It will find that dispatcher, and it will call the API, then it will update this state on itself and will get the updated value. So here, in this case, we have a single source of truth that is the Redux state. And for each page or each component or whatever the complexity of our app is or how complex functionality you're working with, we can either create the dispatchers and the states for each of the functionality features, or we can do it on the page level also. That also works. So, that is the first thing we are not writing any sort of logic in the components. We will be writing all the logics, all the modifications, and all the logics in the Redux toolkit files so that it will be easy for us to maintain that as a single source of truth. Another one is which is my personal favorite, is to use the context providers as much as possible to wrap the entire app in a global context provider in which we can store the data. Sorry, in which we can store the data. The global data is basically not really the JWT token, but any other user-related information we can store or the language user wants the entire site to be and so on, some global things. And then we can make the context for each of the pages or each of the features. But we can do both, pages. We can make the context providers. And if we see any complex functionality, we can just create one more context provider and wrap their entire context provider into that context provider which we have specifically created for that particular feature so that there will be a single source of truth, the entire state, the entire logics, the handle change, clicks, entire thing, the entire data part of the thing will be in that particular file. And our normal files will be just simple HTML and CSS with some rendering logics. That's all. So, I think that's easy to use also, and that is pretty much maintainable because if we want to do anything logical, just go to that particular context, find the variables, find the function, update the states, and you are good to go. And it is also robust because we have a single source of truth. It's not a buggy thing that some of the functionalities are in one file, some are in another file, and some are in another file. We have the errors occurring. Everything is there in the context, and we are good to go. So, yeah, these are the two techniques which I use personally to make the React suite management logic more robust and maintainable.

How do you ensure REST API calls are handled efficiently to provide unnecessary renders? Cool. So I think the REST APIs, which we'll be calling in React, we'll not call them directly. We'll not write them; we'll just write all those API calls in the useEffect hook only so that, either on the useEffect hook or on some event-based clicks. Like, let's say, if someone wants to submit the form, if someone is applying a filter or so and so, then only we'll be calling those particular APIs or either we'll be writing them in the useEffect hook. So whenever someone wants to change their data or someone wants to update anything or someone wants new data on their page, then we'll call the API. Otherwise, if any of our parameters are changing, which on which our get data is dependent on, which we have provided some filters or any filters are updated, but our data needs to update. So we can pass a dependency array, and the user will have to call the APIs whenever all those values change, then we can call the APIs. And, also, what we can do is, like, let's say there are multiple dependencies, like, there are a, b, c, and so on dependencies out there, and let's say two of the dependencies are changing. So a and b both are changing, then our app will only run the useEffect hook once. So what we can do is we can either stringify it, like a-b, so if this entire object is changing, then our string will change for the first time only, and our user will be calling the API for the single time only. There won't be any multiple API calls.

In this Node. Js code, extract the server as unresponsive. Determine why and indicate how you would debug this issue. Express is equals to require express app equals to express app dot get request.set time out. Hello world r dot lesson 3,000. I'm sorry. Who is unresponsive? I'm gonna apply. I'm gonna apply. It goes to express app.card. I think everything seems fine. I think Harry is dot send cannot be arias dot send is not any sort of, keyword or, like, request aria dot send. I think instead of aria dot send, we should have used something else. Or because of this aria is not send hello world thing, this will go there. So this is my finding, I guess.

Imagine the following snippet causing the application to run into a critical screen where a new method might be improperly used here and what the potential is for a user profile, a concept of all user data and a component that is not a component to a user. There's no such static data as it does not exist in the browser or user data. Static get is trying to check from. I think it's updating the data when we are doing the component mode. So this is using the set state. K. So I think instead of component mode, we should use component update. So whenever the props are changing, our component update will call, and it will set the state user data to the latest props we are getting. So I think the instead of component mount, we'll be using the component update method, and then everything will be rendered correctly for this particular component.

How would you design the actual management system that can handle complex search between the components efficiently? Okay, so as I've already answered this particular question, what I'll do is let's say I have these 5 components, and each of the 5 components has 1 or 2 child components. And so what I'll do is use a globally accessible system. So let's say I have defined 2 states, and I'm passing all these states into these 5 components, then from these 5 components to their child components. And let's assume there are 3rd level of children out there, and we are sending those states to 3rd level children or from parent to grandchildren, which we can say. So instead of doing this, what we can do is create a context provider. Once I've created the context provider, I can wrap the entire functionality into that particular context provider. I can define the state in that context provider, and then I'll be importing the useContext. By using the useContext hook, I'll be importing the entire context. Whatever the values I want to use in each of the components, I can just simply use them. I don't have to take all the values which the context provider has. I'll just import 2 to 3 values or whatever the values required for rendering of that particular component. I'll be just using that. And in this way, we can just avoid prop drilling. We can improve the readability of the code, and also, it's easy to maintain because we aren't really 100% sure that we have not missed any of the props or we don't have to think of that we have passed the props correctly or shared correctly to the child component, and that child component has passed the correct things to their child component. So I think that this way, I'll be handling the complex React shared states between the components.

Yes, so there was a situation where there was an analytics dashboard, so its loading time was 7 to 8 seconds, and we had a huge amount of data. We had a huge sort of data. So it was causing rerendering again and again for some of the components which were not required. So I started with the React memo thing. Let's say if the props are not changing, let's just not rerender all these components. Because if the parent prop is changing, let's say someone is applying a filter, then the table and all those things were changing. Let's say if I'm clicking on any particular tab and the drawer is opening and it's causing the rerendering of all the components. So the first step I just used the React memo thing. Then, again, the page load time was not that good. So then I started thinking about how we can make how we can actually use Next.js. So I started building out I started writing code and getting server-side props in which I was getting the data from the server. And initially, the page would load with the CSS, not with the bundles. And then after that, it would go and start rendering the client-side bundles on the client side. This helped me a lot in improving the performance. And apart from this, also, I've shared one example where if our useEffect has multiple dependencies, multiple array dependencies, then we can create a string or we can just send or stringify it so that our useEffect will not be rendering a number of times and our API won't be calling that number of times. So that's another thing. And apart from that, I also used the preconnect things to make things better, just to reduce the time. Like, 500 milliseconds have been reduced when the handshake was done on the server itself. So they don't have to come to the client, wait for the server to get a response. That's one of the things. Apart from that, I think for some of the values which were not updating as frequently, I used the use memo thing so that our React application or the React components don't have to do that calculation again and again, and we can save their time. And so this was one of the rendering techniques I've used. And I think, yeah, these are pretty much the only things I've used to optimize the rendering techniques or improve the rendering techniques from my last startup in which I worked.

The process of constructing a retroactive user interface while considering okay. The process of constructing leverage and the app to user interface and react while considering the performance and maintainability is quite simple in my opinion. So what we can do is from the starting point onwards, we can create some of the basic components. We can create some basic components such as buttons, text headers, footers, sidebars, and the correct image carousels, images, and other basic components, which are called atoms so that those atoms can be combined to make something bigger. First, we can do that. Once that particular thing is done, then we can start creating our pages, our home page, product page, and whatever the application requirements are, we can start building those pages and use those components. And we can make sure that every component itself is reusable, whatever the components which we are trying to make. Let's say, from all these items, we are trying to make a component which will be used by other pages, other features, and other components also. So let's try to make each and every component unique and shareable as possible so that we can use that component anywhere, anytime in any of those components. And it should be able to handle all of the logic and things inside that particular component only so that we can reuse it anytime. This will save a lot of effort and performance while rendering the React app because every time if we are writing the same code, we'll just increase our bundle size and it will decrease our site performance. And apart from that, it's easy to maintain, thus you have to just go and change it to a single place. Once you are done with that, we are good to go. You don't have to change it everywhere. Let's say you are importing a button and we want to change some of the colors or some of the fonts or anything in the button. So the first thing is just go to every file or every component and change the color or the text of the buttons. Another thing is you have this one global component or one atom in which if you'll change, it will change in the entire site. So I think by using this by making our components as I say, by creating components in such a way that we can use it in a number of places, at a number of times with different features or for different business requirements, so the in this way, it will be easy to maintain and it will be high performance. And obviously, we'll be shipping out features in the product much faster. So this is my process. I'm understanding this is the overall process of constructing a large interactive user interface in React.