Praveen soni

Yeah. The question is could you help me understand about your background by giving a brief introduction of yourself. Yes. So I'll start by introducing myself. Hello. My name is Praveen Soni, and I started my journey in the software industry just after my graduation. So, after my graduation, I joined an education startup's initiative. They had a Learning Management System product. At the time of joining, I was working as a front-end engineer, specifically in Angular. And after some time, when we were migrating our product from Angular to Angular 4 and from Python 2 to Python 3. I was leading a team of four people and also connecting with clients, getting their requirements, and converting those to epic stories and delegating within the team. I was also managing the whole pipeline from scrum planning to delivery and releases. After that, we released our product to the market. We also created a product for native platforms for student-teacher interactions. That was created in Flutter, and we later migrated it to the market. After my exploration in the education sector, I moved to a consultancy. I worked as a software engineer for a year, specializing in accessibility and performance issues. I also guided junior and intermediate developers about Angular and web technologies. After that, I moved back to full-time development and joined Freshworks. There, I'm working as a senior software engineer, focusing on front-end development. Yeah.

Okay. What is your approach to error handling and loading in the full stick application using React, Next, JS, and TypeScript? So logging error handling and logging is a must part of any application to understand where the issues arise in at the production level and how to, sophisticatedly delegate or handle those. Basically, most of the time, I handle error handling or loading flows with Datadox, which is a platform which provide us a way to store the flows properly and also, errors and user sessions so we can later on debug and find the root cause of the issues and easily fix those and create more proper releases. Yeah. Thanks.

The question here is, how do you manage local state in a React component, and when do you decide to use a global state management solution? Okay. So, basically, it's more reliant on business logic. But still, whenever the state is shared between multiple components or multiple routes or between different business domains, then it's a good proposal to use a global state management because otherwise, lifting the state up is not a good approach to handle multiple components' need for access to the state. For that, mostly Redux is good enough because it handles most of the flux architecture, basically storing action effects. And that gives a proper flow to handle the whole state. And whatever is not global and not required by components outside, maybe such as a toggle button, if you click on the toggle button, there is a state change for that or maybe there is an intermediate state change. Those global stores don't care about, so we can save those in a local storage of a component by using state hooks or something similar. Yeah.

Explain how you would handle caching of the API response to the next year's application to enhance user application, user experience, and reduce server load. Yeah. So here, the point is how we handle the caching of any API or any static bundle things, right, to increase the load time of the application and improve the UX for the user. So for this, the good way I think of is a service worker, which is applicable throughout the application because it works as an intermediary between the server and the client. And whenever some response is coming, we base it on the business logic to understand if this is a priority refresh. By that means, should it be fresh all the time, or can it be saved via a service worker or maybe React Query or maybe Apollo client? So whatever library we want to use, we need to first understand what is the business requirement around the same API call. If you are fetching a list of countries, that data will not change frequently. That can be cached and saved locally. So next time when you try to hit the API, the service worker can intercept or maybe the query can intercept and then provide the same response that you already faced. But if you are working on a trading application where the live data of a stock, maybe NASDAQ or maybe Nifty 50, that data refreshes quickly, and we cannot cache it. Because each time when we want it, we should get a new fresh data from the server only. So, it's all based on the business requirement and also the use case of the API and how we want to utilize it.

In a scenario where multiple components need to access the same API data in a Next JS application, the architecture I would set up and why is: The question is, what architecture would you set up in a scenario where multiple components need to access the same API data in a Next JS application, and why? The architecture here would be as follows: if the data is used in the client part of the application, the API data will be fetched initially whenever required and then cached in the client only and reused throughout the application. If we're specifically talking about the client side, we can save this data in a global store, which initially loads the data from the server side only. Then, it will just reuse the same data again and again. This architecture is similar to the data dump architecture, where the presentation components and the smart components architecture can also help here. The reason is that most of the components will be dumb components. Only a few components will be smart components, which will take care of how to handle the data and also hitting the server if the data is missing in the cache or store.

So, to troubleshoot performance issues in a React application possibly related to component life cycle method, there can be a few issues with the life cycle methods. Suppose you are using a React component and there is a child component which is doing heavy computation and your parent component is updating because of some specific flow, then your child component should be static and should not re-render again and again. Another point is if your useEffect is using the wrong dependency, it can update wrongly. It can trigger a wrong flow, which is also bad. Also, because React is a UI library, it thinks of UI in terms of a functional flow. So, basically, UI and data create a new UI. Right? It renders the new UI based on the data and immediately shakes the virtual DOM. It verifies the flow based on the virtual DOM comparison and creates a new DOM based on the requirement. Right? So whatever is computation heavy and whatever needs more resources, should be out of this rendering cycle. And once it's calculated or computed, it should be cached and memorized somehow and then only used in the UI rendering process. So, UI doesn't recompute everything unnecessarily. Right?

Okay. The here question is analyzing this TypeScript snippet. Can you explain what is incorrect about the use of any type? And how we rectified it following best practices. Okay. So it's a question about specifically TypeScript and showing why avoiding types can be a issue. Right? So, sorry. So the issue here can be the because currently, we are using data, and this function is not enforced to handle any specific interface. And we can pass anything here. And suppose the because as what I understand from this is responses object, which should at least have one key as a data, right, as a as a property. Right? And if somebody called the handle API response function with a string, like, argument as a string or a number or something, this will not handle it because it accept anything. And this is not utilizing any functionality of the TypeScript because this is just a plain JavaScript. And JavaScript itself have this issue that we cannot understand the interfaces, and, it don't do a type checking. TypeScript also don't do a type checking at the run time, but at least in the compile process or before, it checked all the types. And it ensured the flow of the whole implementation of the code stay and, handle the types properly. So to rectify it, we should provide a proper interface in the function arguments, response. And so each functions are specifically bind with interfaces. And we by looking at it, we can understand what inter what input it accept, what output it provide, and basically how to use these interfaces. Right? So yeah. Thanks.

Here the question is, here at React Snippet using hooks, can you identify the bug related to the use state who can explain what is going wrong here? Okay. Bug related to use state. Okay. What I understand is there is no need to use set time out. Use state count, set count. I see this is a perfectly valid code, and this will run this single time only. Okay. Yeah. The reason the issue here is the count will be stale if it's not in the dependency. Right? The reason is whenever the count updates, the effect should update. Otherwise, the count can be a stale value, and it will be used as an old value. Right? Suppose this is not a timeout but an interval. And because you're not asking it to update the count property, the count can be a stale property whenever the use interval triggers. And the stale property can point to the previous value or no value at all because it's never updated. We never asked to have it update. Right? So to handle that, you provide a dependency to useEffect that this functionality depends on these parameters, and these parameters should not go stale. Right? Or maybe it should not point to an old value. It should always point to the latest value because we're doing some computation on top of it. So I can see this can cause a stale issue. The reason is, we are missing a dependency. We are not updating yet with proper dependencies of what variables we are using. Thanks.

Yeah. Here, the function saying outline a high-level approach for implementing a secure OAuth flow with third-party authentication in a Next.js application. Okay. So, basically, for OAuth flow, the main implementation looks like this: whenever you are in the frontend, you have client IDs. Right? And you trigger a specific URL. You open a new URL. And you create a URL for the third-party authentication, and that URL contains your client ID. And you understand that it opens a specific pop-up. Suppose if you take an example of Google. Right? So if you want to do authentication with Google first needs your client ID to understand who you are. Then once you open that URL, it asks your consent to allow our app to access it or not. So once you click, continue or maybe you agree to log in with it, the client gives back an auth code to our system again. The auth code, when it is provided, we provide the same auth code to our server. The server also has a client ID, but it also has a client secret. So with the auth code, client ID, and client secret, it goes to the third-party server, and it gets the authentication token, which is an auth token. Right? There's a different difference between an auth code and an auth token. An auth code is an intermediate thing, and it's not used in the authentication flow. It's just used to make sure our client, or the third-party server, understands who it's talking with. Right? So once you pass the auth code, which is an indication of consent passed to our server, and the server uses the client ID and the auth code to get the auth token from the server as well as a refresh token from the server. Once these details are there, we just use the auth token to authenticate. And whenever the auth token expires, we just use a refresh token to get the next auth token. This is a high-level flow of how third-party integrations should look like with any front-end or flow. If you see here, specifically in the Next.js approach, this will look similar. We have different endpoints. The front end will first trigger a request to the third party. It will receive an auth code. That auth code will point to the next best backend endpoint. That endpoint will have the client ID and client secret secured in the backend environment only. And that specific flow will trigger the third-party again with the client secret. We'll get the authentication token, and we'll utilize that to authenticate ourselves next time. Thanks.

Given your experience, what are the most critical things you consider when implementing error boundaries in React? It's good to have a question in answering. Error boundaries are a good thing in React, specifically because JavaScript is single-threaded. Something that breaks can break the whole flow, and nothing can be done afterward because it's single-threaded, and mostly the flow will break at that point. Whatever comes afterward should come as a proper flow without breaking anything. Right? So error boundaries are a way to create a specific set of sections. If something breaks, it should break within these boundaries. Right? So in React tags, we can provide a specific boundary. These components and their child components should be inside this error boundary. And whenever something breaks, this error boundary will be used and used as a fallback component to render at that place. Right? Critical aspects will be to ensure that React components used on proper error boundaries should not be on the root level or two root levels because they just consume everything as an error boundary. That's not a good start. I believe error boundaries should be specifically for specific sections – for example, for profiles at specific levels where we can expect any errors, we can have error boundaries there only. Any third-party or server-rendered data we're coming from should have error boundaries because those are the outsides – those are the sections which are outside our control, which can break due to Internet issues or something else. Should have proper error boundaries.

So next question is, how do you manage any sorry. How do you implement and manage feature toggling in complex grid project using TypeScript and real? Yeah. Feature toggling is an important part, which is used to hide, show, or partially configure the feature, based on a toggle. Basically, I have more experience with LaunchDarkly, which also provides feature toggling as a set of SDKs inside an SDK. Basically, feature toggling is something I'll give you a brief idea of how feature toggling is working. We have a string specifically indicating a feature. And the basic idea of it is to have binary information from a 3rd party or maybe somewhere in our system, which indicates whether this feature is enabled or not. So if you implement something new and you have proper CICD, every time a new commit hits your main branch, it will be automatically deployed to a report. Right? But you also want to do in continuous integration. Whatever you're implementing should also go properly with the system and should not be waiting for too long in the feature branch, like three weeks, four weeks. Right? So what you do is you create small chunks of your features, which are properly testable and self-contained, basically not breaking anything, but still behind the feature toggle. So whenever it hits a VIP environment or a QA environment, it will be enabled for them to test. But for prod environment, it will only be enabled once it has been AB tested or maybe some beta testers have verified it from prod, and then it can be enabled for others. So managing this one part is that each module should have its own properly defined process of feature toggling. And they should also have a proper scope of their feature toggling. Basically, if a specific module should have a feature toggling based on its specific toggle module only. So there can be different feature toggle modules also inside a React project. So we can be sure we're enabling or disabling a specific feature toggle only. On prod, basically, almost whatever new feature toggle is created should be disabled by default and only enabled once the beta testing and QA testing is done, and UAT is done, then only it should be enabled. Also, it should always have a default state. Sometimes the feature toggle feature or any 3rd party can break because of internet issues or anything else that's not in our control. So it should always have a default state, and we should always test without a feature toggle flow also how the flow should work without a feature toggle as a default state. Because once we verify the default state, then the feature toggle can be on top of it to ensure we have binary control over it to show it or not show it or maybe not binary, but a config level control over it. Thanks.