Ankit G

Okay, so my name is Ankit. I started my career with freelancing six years ago. For two years, I did freelancing, then I moved to a consultant job in Flipkart. After that, I switched to a startup called Pyxis, which is a martech company, and I was working there as a senior software engineer. After that, I switched back to my parent company, Flipkart. The previous company, I mean. And this time, Flipkart had me as a full-time employee, and it was the same team, everything the same, and now I'm doing this contract. So that's mostly it. And then I have experience from a startup to freelancing to full-time.

Could you implement a method for implementing that and requiring interaction in the browser's local storage? So in order to interact with the browser's local storage, that method should be implemented inside our callback API. So first, call and make a use callback and react component. Then in that component, try to access the, local storage as you want, and this should be it. And in order to get the data from local storage at the time of rendering, you just make a useEffect component. And on the mount or maybe if some dependency, is there, then maybe add that dependency to user spec, and then just fetch the data from local storage. That should be mostly like it. Use effect to get the data at the time of render, or maybe use callback to change the data from in the local storage or maybe get the data from the local storage also on user actions.

We handle the installation of 3rd party services such as payment gateway, social media APIs in a React application. We generally use the SDKs provided by these APIs or this API gateways at our application. We generally redirect the users back to their gateways and stuff. Once those gateways make the processing and everything on social media, we get our authorization code, and it's more generally an OAuth based mechanism. Then we use that authorization code to get some access token, and we can use that access token from the back end generally to get the resources. So, generally, from the React application, we just redirect it to the gateway. The gateway gives us the authorization code. We use that code to validate the token on the back end side, and then we make a call to that gateway. The idea is to interact with the gateway either from the front end directly if it provides a JS SDK, or from the back end if it doesn't.

Single page application react using client side routing. So, generally, it's like at the mount point, you mount the router at the root container. Once the router is mounted, you give it paths, and then all these paths have different components depending on them. You can have a skeleton that includes head, etcetera, which is shared in all of the components, and that's mostly it. You use some router, such as React router or Remix router, or something in React that you can use. And those routers, based on the history API, they get the URL, they render the appropriate component, and that's mostly it.

To debug a complex issue that spans across JavaScript, HTML, and CSS, I explain my process as follows: So, in order to debug, if some error is coming, we go to the console. If some memory issue or performance issue is coming, we go to the profiler. And if some rendering issue or delay is coming, we go to the React Profiler or React Component. So, basically, we use dev tools. Once we identify if the issue is with HTML not looking proper, we just inspect the code. If CSS is not looking proper, we just inspect the element and check the CSS applied on their dev tools. But, generally, in order to debug a complex application in JavaScript, we use the profiler. We can take snapshots of it to save memory. You use Lighthouse to get the overall health of our website. We audit the website. And if any console errors come, we just add breakpoints to our code. And whenever we see where the code is breaking, we just add a breakpoint and check the local environment, what kind of things are there, and all that stuff.

How do you manage state in a React application? And can you mention a scenario where there might be a better chance than local state? Yeah, definitely. So the state in React is generally local, and whenever you need any data that needs to be preserved between the renders of a component, then we store them in React. And, state and props are two similar things, but props come from the parent and the state is from within the component till the life of that component exists. And generally, we use React to share the state across our whole application. So suppose one component is using some state and another component also needs that state. Suppose maybe user data they would need, then we will share it with Redux. And also Redux gives a very clean control over state, so it also gives us backtracking and things like that. So, yeah, mostly, this is why we'll use Redux.

I'm preferring large areas. It's a bit to optimize it. So, in order, it is actually trying to loop over the whole array and then give the sum. And when processing larger ends, it might not be performing well because of the complexity of O(n) and then we are using the area operation over it. So that's for each iteration we are calling it, maybe we can use a for loop here with a simple sum counter if we can, and that is going to be the fastest way. If we cannot do that, then we can use Math.max with the spread operator or Math.sum using a spread operator, but that is most likely going to be less performant. But, yeah, these two are approaches, either use a for loop or use Math.sum.

So here, with legacy browsers, this grid layout might not function well. In that case, we can go back to Flexbox, and we can use Flexbox or maybe float left will work fine. But otherwise, if we cannot use grid, we will just go back to Flexbox and use that.

So to manage the usability and maintainability in our React component, which is very big, we just try to identify the individual functionalities that we can extract from that component. Then we will just extract those functionalities and break the component into smaller ones. When those components are broken into smaller ones, then we will try to memoize them. We will try to lazy load the component using react.lazy, then we will memoize the computations inside. If still it does not work, we will have some other state. We will use context to share the state in this component so that renders are minimized. And if any component can be a pure component, we should be using a pure component there. A should component can control updates, then we should control the should component updates, and that should be mostly it.

So in order to secure a React application, we just say we need to protect our users from 3 things. 1, we need to prevent it from sending user input directly as the input so that our users don't get into typical SQL injection and those types of attacks don't happen. Once we have sanitized the input, then in order to protect the user from cross-site scripting attacks, we just validate the input before showing it on another user's page, like blogs and all. And in order to use the same origin policy to save our users from CSRF attacks, we need to provide some CSRF protection, which we can do by setting a cookie with the same site none attribute or giving CSRF token protection.

Implement code splitting in a React application using dynamic imports or React lazy, which will decrease the bundle size. After that, try to have the critical rendering part optimized and have as little CSS at the table as possible at the start. Once we have those things sorted, lazy loading, impact, memoize, and that's it.