Pratik Ghosh

Well, uh, I'm a front end engineer. I have been doing this for, uh, close to 10 years now. I started off with an EdTech firm. I was building educational and practice math and physics games for clients like Discovery, Pearson, Tata, etcetera. Then I moved to Amdocs where I started working on b to b products. Uh, text tag was check query, uh, vanilla JS, knockout, uh, and. Uh, after that, I got a chance to work on a great field project. This was more of an ecommerce product, so a customer facing product. And since I was part of the team that built it from scratch, I got to be on the panel of experts to implement the solution at the client side. Uh, this is when I started working with, uh, React and Redux, close to 6 years now. And after that, I moved to Walmart where I was working on, uh, another tools that was more of a b to b product for content validation and item curation. Post that, I moved to Europe, uh, in Berlin where I started working with Delivery Hero. It was the logistics domain, and the product that I was working on was head center. This was a customer facing application again. And the special thing about this was that it could render on all devices and across product lines. So the rider, seller, restaurant owner, picker, and customer, they all use the same head center. After that, I moved to Deutsche Bank where I was working on the trading portal. So WebSockets, real time data fetching for currency derivatives, euro, USD, JPY, and etcetera. Then, uh, because of bureaucratic issues, I had to go back, And now I have all my work permit and authorization sorted, and I'm working for SAP through an external consultant.

Well, so, uh, first of all, we need to decide what what are the levels of error handling that we're doing. So first is a common error, like, say, the application crashed or some unauthorized issues or maybe the server is down. So you have an HOC in, uh, in React where you can handle the error boundaries. Secondly is what to do for page level errors. So, again, this is based on design. If you have a React application, you maybe show a different HTML, like you have a conditional separator or maybe you redirect to another page. It all depends on the design. If you have a Nextiva's Play page, you would perhaps have the error in your pages section, and you would return that HTML instead of, uh, redirection because that is server side rendered. And so, yeah, it depends on the design. It depends on what are the levels of error handling that you require. If it's an API level error, and you will do more to block the UI for it, then you log the error on server logs or client logs. And, you know, it it it again, as I said, depends on the criticality, the level of error, how the application is designed, whether it's user facing or whether it's a b to b where the user is a trained person, and they have access to logs. So it has to be more meaningful in that case. It all depends on the design.

So when creating form components, uh, first thing that we need to make sure is that it has to be accessible because a good form is an accessible one where you take care of specially able people, uh, screen readers, and and and those kind of things. You you make sure it's a a 11 y compliant and w 3 compliant and all of those things. That is the first thing. Secondly, what you wanna make sure is whether you have a dynamic form or a static form, if you have a dynamic, uh, form. So we need to make sure that you've tested it across devices because you add new inputs or maybe new HTML depending on requirement or drop down selections or, uh, whatever is a is a case. You need to make sure that they are still in a in a correct design, whether it's on a phone, whether it's on a smaller screen or larger screen. So you have to make it responsive. Next is what what is the data that you're sending? Uh, so most of the forms are designed to send some data to the server. So to make it scalable and maintainable, we have to make sure that the data is in a correct format. So usually, I would I would assume that some web product, so it's a JSON data. So if it's a JSON data, we make sure that you have the right level of, uh, indentation. Like, uh, you have the right level of, uh, attributes. Well, you you do require nesting, but you also have to make sure there's not too many levels of nesting. So, yeah, you you make sure that the data is structured properly.

Well, I think, uh, when when you have an interface, then in in those cases, it is more first of all, looks appears more object oriented. So when you implement an interface, you directly get the prompts. You get the errors. TypeScript is better able to tell you that, uh, you've not you've missed out on some, uh, definitions. Secondly, uh, interface is something that is, uh, you know, gives it a more, uh, like, a you could obviously you could also import types, but then you put it, uh, differently. Like, if you if you have parameters or or variables, then it's more suited for them to have types. But if you have functions or classes, it it looks better, and I think it's it's also more suited for them to be implementing interfaces rather than for them to be of a particular type. I don't see any other advantage of this other than a more object oriented look, uh, more TypeScript. Uh, how do you call it? Easy, easy TypeScript prompting. Uh, attached TypeScript to identify it properly plus, you know, build time, uh, run time sorry, compile time errors. So I I know about these advantages. I am not aware if there's any other advantages to this.

Uh, well, I have only worked with remote caching, So you would use something for remote caching, maybe red is something on the sort. Again, you have to be very sure when you're cashing the AP responses because some of the responses are that it's possible that they change. So you don't want to cache those responses that can change quickly or through throughout the flow. You wanna cache the responses that you know cannot have data change. For example, a logged in profile cannot usually have a a name, contact, or a best change unless the flow for that is being met. Again, uh, you want these caching to be in a separate section in your server section, not in your pages section. Make sure that the cached values are also properly used in the, uh, in in the component. Because if you are doing a remote caching, we do not want unnecessary rerendering for for that data. So so make sure that, uh, the layout and the pages reflect that correctly, and there is no rerendering for a component that uses cached response. These are what what comes to mind. Uh, this is how I would handle it.

Well, uh, first of all, we I I would always recommend to have a BWC checklist. It it depends on a lot of factors. First thing is how often do you upgrade major dependencies. If you if it's something that do do monthly or quarterly, it's much easier because then the tech debt doesn't accumulate into a big huge change. So having a beta to see checklist and keeping it updated to latest versions definitely helps. But there's another point that you'll need to keep in mind because sometimes you work on projects that are used by those, like, the usable components or, uh, foundation layered components. So these things, you know, just keep updating and stop support for the older versions because other things takes time for them for all to come to a particular level. So, yeah, you you need to have proper documentation for each version. You have to have a VWO checklist. You have to stop support for certain versions so that you know you you mark and deprecate it. So the teams also know that they cannot stay on a version for way longer than they should. Yeah. This this would be the strategy for maintaining, uh, an application that that has to stay b double c compatible as well as up to date.

Well, I think, uh, in the use effect, you have to specify the dependency parameter. Otherwise, what happens is the useEffect runs only once. And And you use a set time out. So once that is updated, you do not have the page updating. It's not a second term. So you have to have the dependency parameters so that the effect can run again. This one is run only, I think, on mount or a mount. And then after that, it's not updated anymore.

Well, if you are using any, there has to be a very, very good reason to use it because what the the reason one of the major reasons why you're using TypeScript is for, uh, parameters, objects, responses, payloads to know what they are gonna be. You if if you allow any on that, then it beats the purpose. So you cannot allow, uh, especially something as important as a response to be of any type. How you can rectify it is you can either define a type and you import it and then you assign that to the response. So I do know it's particular, say, you know, network response type. Uh, what would have what are the fields they should have, and and which of them are mandatory, which of them are optional. You you need to do that. That is, I think, pretty much how you handle it to make sure that best practices are being followed. You can in an extreme case, you know, you can use something like an unknown or or something, but I don't know why a network response would be up in long time. So yeah.

Well, uh, I to be honest, I've not had an experience like this. So I would have to take a guess if if there is a memory leak. Pinpointing is, uh, is mostly only possible when you're logging stuff and when you're debugging things. So it's like when you have something to track your store, your your maybe if you're using Redux or React context or caching whatever is. So you you it's only possible that when you when you keep a track of that, uh, if if there's some other memory leak like state objects or things, it's again very difficult to find out. Uh, you you need to find out the error first. Yeah. It's it's better to be able to move towards to backwards. Like, you first find out the impacted portion and then trace it back to the leak. And you can do this better if you have the right logs, if you have the right, uh, debugging tools or debugging setup. And how do you resolve this? You well, uh, I mean, you obviously cannot have, uh, you cannot it's not a good practice to beat the browser constraints or, uh, you know, the the memory or time out provided by the browser. So it's better to make sure that you work in those constraints. You make sure that you handle the exceptions or or give the user warnings or you log out the user or do something like that so that doesn't happen because of, uh, you know, idle state or something. Secondly is when you update things, you make sure that the old ones are deleted. You do not unnecessary store stuff that you do not need. Yeah. Uh, this this is what I can think.

Well, uh, the setup is usually, uh, you you have your, uh, project setup, and then you you do your NPM in it, then you do the NPM next, the the command for text project. Your packages gets updated, then you do the next step run, and you start then you you also need an index JS file for the entry point. Then you divide your project into server pages layout. So your layout is things usually that not supposed to change often. Pages are the different pages that you would be returning to the client from the server. And server is, uh, running server that that would be the endpoint that the client hits in order to get the. So, yeah, this is the basic, uh, process. And, uh, setting it up is you would require next config instead of those files, uh, and handle the different kinds of requests that you have. And the server basically will take care of which page to return on what request.

Well, uh, to be honest, I have worked on this. Usually, the feature toggle is done by the back end. You you send them a request that the response has to contain a particular flag sometimes. Sometimes that feature is toggled from the AWS server itself so that back end doesn't make a change. You just, uh, log into it, and then you make the change so that that that flag is part of every users or other targeted group of users, uh, JWT token maybe. Uh, so that there are many ways in which this is done. Uh, I I don't know one best method of getting it done, but you can do it with, uh, server configuration, AWS configurations, server responses. You can do it with also deployments like client side. Uh, you you take hardcoded ones for like, if you if you know that you are setting up a feature for a particular area, then you do it during deployment. Like, you deploy something with a hardcoded value for US and another one for EU. So, yeah, there are there are many ways to get it done. You monitor it and then you change it for all. So I had a lot know which is the best approach. It depends on what what are the target audience. So, also, it depends on whether it's area based, whether it's group based, whether it's role based. So, yeah, a lot of things that need to be considered when handling this.