Namit Dhupar

I have around 5 plus years of experience as a front-end developer. This opportunity really excites me to join this organization. And, yes. So, currently, I'm in a company called Meski. It's an ecommerce-based startup based in Gurgaon. So, we basically deal with healthy products. Currently, I'm in charge of the front-end part. I'm the senior front-end developer in this organization, and I lead a group of 4 people, out of which I think one is currently in. I'm looking for a change because there have been some work-related issues and also some cost-cutting going on. So, just to be on the safe side, I am looking for a change.

So in order to get the life cycle method, I would use so if you're talking about the class-based component in React. So class-based components are basically what exactly are React life cycle methods? So I would say component did mount. And if there is any on change or something, we can have that on the change method, like any event-based trigger, like click, blur. We can make an API call. So component did mount along with component did update, we can have a props change. And if those props change, we can detect if there is any change in the prop or the state. And based on any of that, we will try to call a RESTful API. In case of the functional components, I would use, like, which I have been using most of the time. I would use the useEffect hook. And with the use of that hook, there is a dependency area. So I want and if I want the specific effect to be called on the mount of a specific component, then I'll do a mount. Like I'll leave an empty array dependency. If I want an API call to happen, if there is a change in certain data, then I would have that variable inside the dependency area. And, yeah. So mostly, I have been using Axios for the RESTful fetch, but this can also be done using the fetch API. And asynchronicity is obviously the best way. In order to have an optimal way to approach for a RESTful API call, say there are multiple API calls in which we need to deal with, then I will use the Promise.all method, which will ensure that all those APIs are getting called in parallel without affecting the page's performance. So that's how we can leverage React life cycle methods to call any RESTful API. If we talk about Axios specifically, I would like to go into more details. So Axios is basically a package which makes the fetch API much more robust. As in we can configure the endpoints, we can have a specific base URL and an auth token everywhere in a single file with a config file, and we can use that access instance in multiple other files based on the requirement of the API to be called. So that's how I have been doing in my existing projects. So yeah. UseEffect calls our API, async of it. We don't usually do async of it inside of useEffect because it's not a good practice. So instead, we would have a separate function call for an API to be called, and then I can use that function call inside the useEffect hook, instead of using the useEffect, async and then the curly braces, like the round brackets and then call the API. So, yeah, async of it, Axios, useEffect, combine it later. So that's the basic.

So basic flow of data in the rear component for Redux is when we're trying to install the Redux since Redux is basically your global state management. And this will be used in making sure that you don't lose a state if you unmount a specific component. So say in case of a cart, we need a cart to, in my case, if I'm working on an ecommerce project with React, then I would make sure that adding an item to the cart and triggering a response and making the cart amount as the length of the array inside the cart items specifically doesn't close or affect the cart items. So I would rather have that stored in the Redux, or there are other better ways to use Redux. Sorry, global state management, like the stand and context API, this inbuilt way of using React in building using the global state component. But, yeah, if you say about Redux, then it is sort of an architecture. So this architecture will contain a certain amount of components that we need to deal with. So it basically consists of an action, subscription, a middleware if required, and the middleware will go in a stack. So the action dispatcher will first call the other component, which will call the action dispatcher. That action dispatcher will send to the subscriber. And from the subscriber, that action will go to the Redux store. And the Redux store will contain all the data, which is present in the global store. And there, it will send this to the reducer, which will catch the action item, and then we can use that in our component. So to subscribe to that, we can use the map state to props method to send specific props and map it to a state and then get the changed state. So this is in order to render and trigger certain re renders if we change the Redux store. So the action dispatcher, reducer, middleware is used if we are trying to access the reducer using any side effect or async API call or side effect based calls, and we want that to be dealt inside the Redux itself. So the Redux model where it can be like Redux, the React Redux Saga. And, yeah, that's the basic gist of it. That's how a component can subscribe to the Redux store. If I don't want internal API, so, yeah, that would require the Redux and Redux Saga. I don't know the specifics right now, but, yeah, I think Redux Thunk is a version of Redux server, where you can get your job done if you're trying to access a middleware using just for

Complex Redux action creators that are not dispatched. That is not something you do. I'll show this. Okay, so there is a certain tool in Chrome or any other web browser that recognizes web browsers. It's called Redux Toolkit. And using this Redux Toolkit, we can see the entire structure of the Redux store in a straight format. We can use that toolkit to trigger certain actions. And the events we see once we connect any component to the Redux part itself, then we use that inspector to check if that particular action has been called or not. That action call is also triggered when we use that toolkit. So yeah.

Your phones and direct insurance. We're showing that state is efficient. So, in a personal experience, I have been mostly working with Krishna, not Redux, but with the state management system. Not with Redux, but with the state management system, so, using Formic state forms. I have been working in my previous organization, and I have built and basically used it a great deal. Currently, you're using forms in a traditional state to props format. And, in separate projects, we have implemented React Hook forms. So, in that way, we are using React forms. The most efficient way I feel is actually Formic because I have personal experience with Formic, and it contains its own validated functions. We can have our own regex methods if we keep them in it, on validate functions, on blur functions. The Formic React has its own field set of fields, which we can configure in our own data, in our own core project based on the requirements, which is very configurable. So, Formic is a better way. Forms are good, but I haven't used FormMaker in that great of a capacity. I'm sure it is good, but I haven't had the opportunity to use it. We can have a certain initial level of validations using the format, validate function, and onboard function. Then we can create our own custom validations using the on method. And the forms can be submitted, then we can create a specific payload. And based on the payload, we can send data to either the API itself, or we can track it in a Redux-like state management if we are dealing with a multistep form, which I have actually used in my previous work experience.

We're dynamically loading via conference based on user interaction such as clicking a button. Okay. So in order to do that, the dynamic load is something which is the specific dynamic import, like lazy import. However, I think we're not asking about the lazy part. So I would say that in order to trigger a certain component on click of a button, on any user event, we can actually bind that action state to the specific event. So, say, we have clicked on a specific button, and we want that button to change the state, and we can send that state to the external component, and it can detect that change in the state and render the component based on the current value of the state. So, say, we have a button, and we want a specific model to pop up when we're trying to click on the button. Now, what we'll do is we have a separate model file. And that model file, which we can call on in the component itself containing that action state. So, we can have a condition where if the state is false, then we don't need the model to pop up. Otherwise, we can just use the state. We can just trigger the state value to true. On the click of the button, we can bind that action, and we can use that action to trigger the state change. And on doing that, and when we do that, we can have the specific render trigger, and then we will see the model. And if you want to close it, you can again bind the on close method and trigger the state to false, and this will dismount the component. So, that's how we will be able to dynamically load a React component. If you talk about non-event based triggers, then I would say that it's better to have a certain lazy loading component, which once loaded, we will load it dynamically. So, there's a certain dynamic import module. So, that's how we can do it. I mean, I have to explain both the methods.

I'm sorry for the voices actually. There's some fusion classes going on in the other room. So, I think this is basically happening because we're trying to access a variable before it's being declared. So that's why. This is basically happening because of hoisting issues. So, let's, as you know, it's a functional scope variable, and you're trying to access the let variable before we're defining it. So this is where a reference error will come because of it. And as the hoisting principle is, it's not able to actually get the variable before we define it. So if we use let user and define a let user before we do a fetch call, then I think it will

So if you want to take a guarantee of a React component across different browsers and devices, you can use certain tools. For example, if you're talking about the best responsiveness, I would make use of the grid system. I would make use of various CSS properties, such as grid media queries. If we're using an external CSS package, like Tailwind or Material UI, or Tailwind Material UI, we can use that. Otherwise, we can use different devices. If you're talking about different devices, you can use something called the Google Inspector. Google Inspector will ensure that your component is responsive and able to work properly on different devices. We can configure all those devices based on different operating systems. We can use something called a third-party application called BrowserStack, which most of my testers use in my current organization. That's how they verify the functionality of each and everything in BrowserStack. Then there is also Lambda testing, which is something similar, but it's not that great in my personal experience. If I talk about different browsers, then we have to make sure that we are using ES6 in a capacity where it can easily be consumed by different browsers. Alternatively, we can use certain browser-specific JavaScript functions, which can cause different behavior based on different browsers. For example, Webpack, Mozilla, and Safari. We will do testing on different devices on BrowserStack. If we find any kind of discrepancy, we'll try to figure out a Webpack solution for that in CSS. So, yeah, this is how we can handle different devices and browsers using JavaScript, CSS, and guaranteed functioning, which is working properly across different platforms.

I'm sorry, I haven't actually worked with the portal. I would like to proceed to the next question.

So in order to secure a React application from common web vulnerabilities, the different approaches I'll follow are: first of all, I would suggest using HTTPS methods instead of HTTP, which would ensure certain authentication security. To prevent SQL injection or DDoS attacks, we can configure proper ways to handle multiple requests. For instance, if you have a specific form and you need to log in, you need to have a certain check on your system from both the back end and the front end. For the front end part, I wouldn't request an API to be called on multiple button presses. I would rather wait for a specific API to be called once. And if based on the response, the user has a certain count remaining, then only we can allow the user to access the API. Otherwise, we won't. This would prevent DDoS attacks and packets filing up another application. From an insecurity point of view, we can certainly use better ways to write JavaScript. We can minify the JavaScript so that our source code isn't easily identified and compromised. And I think there are a lot of things already being handled with the recent version of React, which we are using, version 18, for instance. It has a very good inbuilt security mechanism. Also, we would have a specific kind of authentication implemented, like pass auth or OTP based something, so that the user isn't able to compromise someone's account. We would make sure that event-based bindings don't call the API so often that it would actually crash the servers. The binding of events will have certain security considerations before we implement it, with certain countermeasures to prevent them from triggering multiple API calls at a time. So these are some common vulnerabilities that can be avoided if we use React. In terms of security, we can certainly use expiring cookies. For instance, we can store sensitive data in cookies for a very short period of time. Alternatively, we can store data in local storage and clear it out once we are logged out. There are certain steps that we can use to optimize and have a more secure way to establish React components.

I haven't gotten the opportunity to do any kind of unit testing in my organization. Normal organizations, actually, because I have never been a part of a well-established organization, and I did try to convince management to let us implement those functionalities. But, unfortunately, I wasn't given the required bandwidth or even time to actually get into it. So I would rather skip this question. Thank you.