Praveen soni

Yeah. The question is could you help me understand about your background by giving a brief introduction of yourself. Um, Yeah. So I will start my with my introduction. Hello. Uh, my name is Praveen Soni, and I started my journey in software industry just after my graduation. So just after my graduation, I joined an initiative of education startup. They had LMS product. And at the end time of joining, I was working as this, uh, front end engineer there, um, and in Angular. And, uh, after some time when we were migrating our product from Angular to Angular 4 and Python 2 to Python 3. I was leading a team of 4 people and also, uh, connecting with clients, getting the requirements, and, uh, converting team converting those to epic stories and delegating within the team and also, uh, managing the whole pipeline from scrum planning to delivery and releases. And after that, we released, uh, after that, we released our product to market. And, also, we created a product for native platforms for student teacher. Um, so that was created in Flutter, and we also migrated that to market. And after after after my exploration in education sector, I moved to our consultancy. I worked as 1 year as a software engineer with accessibility help, uh, I mean, software matter expert. So I was helping people there to handle accessibility issues, performance issues, and also guiding the junior intermediate developers about Angular's and, uh, web technologies. After that, I moved to moved back to full full time development, and I joined, uh, Freshworks. There, I'm working as a senior software engineer front end. Yeah. Thanks.

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, uh, sophisticatedly delegate or handle those. Basically, most of the time, uh, 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, um, 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 your React component, and when do you decide to use a global state management solutions? Okay. So, basically, it's it's rely more on business logics. Um, but still, whenever the state is shared between multiple components or multiple routes or between multiples different, um, business domains, then it's a good, uh, proposal to use a global state management because, otherwise, the lifting the state up is not a good approach to handle the, uh, the multiple component needed access of the state. Um, for that, mostly, uh, Redux flow is good enough because that handle most of the, um, flux architecture, basically store, uh, action effect. And that's give a proper flow to handle the whole state. And whatever which is not global and not required by outside of the component, um, maybe suppose toggle button there is a toggle button. And if you click on the toggle button, there is a state change for that or maybe there is intermediate state change. Those, um, Global Store don't care about, so we can save those in a local storage of a component by using, um, maybe use state hook or something similar. Yeah. Thanks.

Question here is 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, uh, the the point is how we handle the caching of any API or any static bundle things, um, right, to increase to to improve the load time of application and improve the UX for a user. Right? So for this, basically, the good way I think of is a service worker, which is, uh, applicable throughout any of the application because its work as intermediate between the server and the client. And whenever some, um, response is coming, we based on the business logic, we can understand if this is on priority refresh. By that means, should it be should it be fresh all the time, or can it be saved via 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, um, around the same API call. Right? If you are fetching a list of countries, that data will not change frequently. That can be cached and saved in local client. So next time when you try to hit the API, the service server can intercept or maybe the query can intercept and then provide the same response, which you already faced. Right? And but if you are working on a trading application where the live data of a stock, maybe NASDAQ or maybe Nifty 50, those data refresh quickly, and we cannot cache it. Because each time when we want, we should get a new fresh data from the server only. So, yeah, it's all based on the business requirement and also the the use case of a AI sorry, API, and how we want to utilize it. Thanks.

Yeah. Your question is, in a scenario where multiple components need to access the same API data in a Next JS application, what architecture would you set up and why? Yeah. So the architecture here will be basically if the data is used, If the I believe this is the client part of the the discussion is going in the client part of the thing. And, basically, this API data will be phased initially whenever required and then will be cached in the client only and will be reused in throughout the application. And if we are specifically talking about client side, we can save this in a global store store, and that store initially will load the data from the server side only. And then afterward, it will just reuse the same data again and again. And this will also that the dump up architecture, basically, the presentation components and the, um, uh, the smart components architecture can also help here. The reason is, uh, most of the components will be dumb components. Only few components will be smart components, which will, uh, take care of how to handle the data and also to hitting the server if the data is missing in the cache or store. Thanks.

Okay. The question here is how would you troubleshoot performance issue in a React application possibly related to component life cycle method? So there can be few issues with the life cycle methods. Suppose you are using a React component and there is a child component which is heavy computation and your parent component is updating because of some specific flow, then your child component should be static and should not render again and again. That's one point. Um, the another point is if your useEffect is using the wrong it can update wrongly. It it can trigger wrong flow, which is also bad. Also, um, because React is a UI library, it you it it it it think UI in a terms of functional flow. So, basically, UI and data create a new UI. Right? It's again and again render the new UI based on the data. And in immediately, it shake the virtual DOM. It based on the virtual DOM comparison, it verify what is the flow, and it it create a new DOM based on the requirement. Right? So whatever is computation heavy and whatever is, um, need more resources, uh, more CPU cycles, should be out of this rendering cycles. And once it's calculated or computed, it should be cached and memorized somehow and then only should be used in the UI rendering process. So UI don't recompute everything above the bigger things. Right? Yeah. Thanks.

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, uh, 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 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, uh, 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 it it checked all the types. And it ensured the flow of the whole implementation of the code stay and, uh, handle the types properly. So to rectify it, we should provide a proper interface in the function arguments, uh, 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. Um, what I understand is there is no you 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 the issue here I can see is the count will should be in the dependency. Right? The reason is whenever the count update, the flow should update. Otherwise, the count can be a stale value, and it will be used as a old value. Right? Suppose this is not a time out but interval. And because you are not asking it to update the count property, it the count can be a stale property whenever the use interval trigger. 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 to update it. Right? So to handle that, we we provide a dependency to useEffect that this functionality depend on these these parameters, and these parameters should not go to stale. Right? Or maybe old it should not point to a old value. It should always point to a latest value because we are doing some computation on top of it. So I can see this can cause a stale issue. The reason is, um, we are missing a dependencies. 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. Um, so basically, for OAT flow, the main implementation look like is whenever you are in front end, you have client IDs. Right? And you trigger a specific URL. You open a new URL. And you are creating a URL for the 3rd party authentication, and that URL contain your client ID. And you'd understand, um, it open a specific pop up. Suppose if you take example of Google. Right? So if you want to do authentication with Google, Google first need your client ID to understand who you are. Then once you open that URL, it asks your consent to, um, to allow our app to access it or not. So once you click, uh, continue or maybe you agree to log in with it or use it, uh, the client give back auth code to the, uh, to our system again. The auth code, when it is provided, we provide the same auth code to our server. The server also have client ID, but it also have client secret. So with the auth code, client ID, and client secret, it again go to server, the 3rd party server. And it this time, it get the authentication token auth token. Right? The there's a different difference between auth code and auth token. Auth code is intermediate thing and is not used in authentication flow. It just used to make sure our client, sorry, 3rd party server understand who it is talking with. Right? So once you pass the oth pass the auth code, which is indication of consent passed to our server, and the server use client password, uh, client ID, and also the auth code to get the auth token from the server as well as refresh token from server. Once these detail are there, we just use the auth token to authenticate. And whenever the auth token expires, we just use refresh token to get the next auth token. This is a high level of flow, of how, uh, third party integrations should look like with the, uh, any implementation any front end or flow front end flow. If you see here next, specifically in Next. Js approach, uh, this will look similar. We have different endpoints. Uh, the front end will first trigger the request from third party. It will receive a auth code. That auth code will point to the next best backend endpoint. That endpoint will have client side cluster client ID and client password secured in back backend environment only. And that that specific flow will trigger the 3rd party again with the client password. We'll get the authentication token, and we'll utilize that to authenticate itself next time. Thanks.

Okay. Question here is given you her experience, what are the most critical expect you consider when implementing error boundaries in React? It's good to have a question in answering. Okay. Error boundaries is good thing I see in the React that specifically is whenever because JavaScript is single threaded. So something break can break the whole flow and nothing we cannot do anything extra afterward because it's single threaded, and mostly the flow will break at that point. And whatever the new comes should come afterward as a proper flow without breaking anything. Right? So error boundaries are a way to create a specific set of sections. Like, if something break, should break within these boundaries. Right? So in the, uh, in the React tags, we can provide a specific boundary. So these these components and these child component should be inside this error boundary. And whenever something break, this error boundary will be used and used as a fallback and error, uh, component to render it at that place. Right? Critical aspects will be, um, to ensure, uh, there, uh, the React, um, added components used on a proper air boundaries, it should not be on the 2 child level or 2 root level because it just consume everything as a error boundary. Right? Which is not a good start. Uh, I believe that error boundary should be specifically for specific sections. So was for profile at the specific levels where we can expect any errors, we can have error boundaries there only. Any, uh, third party or server rendering, the data we're coming from should have error boundaries because those are the outs those are the sections which are outside control, which can break due to Internet issues or something else. Should have a proper air boundaries. Yeah. Thanks.

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, uh, config the feature, based on a toggle. Basically, I have more experience with launch LaunchDarkly, which also provide feature toggling as as a set of SDK, um, inside SDK. Basically, feature toggling is something I will give you a brief idea how feature toggling is working. Basically, we have a string specifically, um, indicating a feature. And the basic idea of it is to have a binary information from 3rd party or maybe somewhere in our system, which is enable this is enabled or not. So if you implement something new and you have proper CICD, every time a new commit hit to your main branch, it will be automatically deployed to a report. Right? But you also want to do in continuous integration. Whatever you are recording, you whatever you are implementing should be also going properly with the system and should not be waiting for too long in the feature branch, like, 3 week, 4 weeks. Right? So what you do is you create small chunks of your features, um, which is properly testable and which is also a self contained, basically not breaking anything, uh, but still behind the feature toggle. So whenever it hit to a VIP environment or a QA environment, it will be enabled for them to test. But for prod environment, it will only enable once it have a AB testing or maybe, uh, uh, some beta tester already verified in from the prod, and then it can be enabled for the others. So managing in one part is that each module should have their own properly definition defined, uh, process of, uh, feature toggling. And they also have should have 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 the React project. So we can be sure we are enabling, disabling a specific feature toggle only. Uh, on prod, basically, almost whatever new fidget toggle created should be disabled by default and only be 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 features or any third party can break because of the Internet issues or anything else which is 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 fidgetoggle as a default state. Because, um, once we verify the default state, then fidgetoggle at the can be on top of it to ensure we have a binary, uh, control over it to show it or not show it or, um, maybe not binary, but a, uh, config level, um, control over it. Thanks.