Kashyap Sojitra

My name is. I'm based out of Gujarat, India. I have around 5.5 to 6 years of experience working as a full tech developer with multiple early stage startups. The main technologies that I have used on the front end is React, Vue, and Next. Js. On the back end, I have used Node and Nest. Js. With the databases, I have experience using Firestore, MongoDB, MySQL, PostgreSQL. I have always been working as a full stack developer with startups, and hence, I've been getting challenging raw, challenging task in day to day situation. The different domains of the companies that I have worked with includes I started my career with, corporate admin start up named Tripio, which was acquired by a US based company, named Strip Actions. then I moved on to an enterprise analytics startup named Byted Prophecy, which was acquired by Accenture supplied intelligence wing in India, which was also Accenture's 1st acquisition in India. Currently, I am working with a digital marketing all in one platform, which also Support's white labeling. it's a CRM, platform that's based out of US. And I have been contributing to their automation, so the workflow builder. Other skills that I possess is Web scrapping and, Babel configurations, something that I had worked on as well. For CSS libraries, I have experience using Tailwind, Material UI, as well as Bootstrap. On I On the CSS part, I do have experience using SCSS. I have I don't have much exposure to less, but that's something that I would be flexible learning for.

So for front end testing, I have used Cypress. Cypress, where we can use the it's HTML or the path to just see if the component is rendered or not. For back end related testing, I have used Chest and Mocha. I used to just tweak some of the data that I would need in case it's required. I think, yeah, that's pretty much it in terms of testing the front end and

So in order to optimize a WebSocket connection, I would suggest to keep allow the same connections rather. I think with socket dot I those latest versions, it always keeps, on the connection until we close it explicitly In order to ensure that no new connections are made or new connect new socket connection is not established for It'll, every time for the for the same user even in different sessions, which would really help managing the number of connections as well as Retrieve data. So the long pulling that we call basically I think with socket.ios Jettest version, it's already taken care of. I'm not particularly so sure about how we could do it with WebSocket connections, but I think a better approach here would be To add the ID to the WebSocket, it makes a connection and use the same ID connection ID every time the user connects

So the best practices that I have been following is to divide or break down the components into smaller pieces and ensure that if a part of code is repeated, I try to make it a component. Also, for React based application, I generally try to create base components. Let's ins. Let's say a button, a drop down, or the commonly used, like, the input box, whatever it is. I try to create a wrapper over their conventional input so that it ensures using the same style throughout my system, which helps in adopting team based systems very easily. 2nd approach that I follow is add I ensure to add proper keys to any of the data that's been looped over. For example, I loop over an area to render multiple dues. So I ensure that proper keys are maintained so that the pro performance is optimized. I then use, methods like useCallback, use memo, and memoist components to ensure that the number of recalculations of something or the number of references of a function are minimize, in successive re renders. I try to use context API for something that require the central state management, and it ensures that all the components up to the current components are rendered properly in case there is some state that needs to be updated. I also ensure that while unmounting the component, if I am adding any event listener, ensure to remove those event listeners as well to not overload the components. Yeah. That's it.

You are tasked with building a live epic Hello to get that allows multiple users to edit a document. So do you implement to minimize conflicts and ensure data So I believe this would be very similar to what Google Docs, Google Sheets, or, Figma and so many of the products nowadays provide, which is collaboration live collaboration, basically. So I have you, I have read about a few techniques. I am currently not recalling the exact technique name, But, there are 2, 3 techniques that I had referred to which we could use in order to Have a comparison between the changes made by multiple users and then ensure that The changes are not conflicting or the latest change is the one which takes the High priority. Let me just think of the method name. I'm just trying to think what are the I think it's OEMs. No. Really OEMs. That's something very similar to it, which I'm just trying to recall. Let me just think of it. I think I am not currently remembering it. Let me think of the algorithm that it might be using. I think I am not currently

So in order to manage state, we can, induce 1 of the 2 things. One is either we can use a third party library like Redux, or we can use context in order to maintain state. I think, we're complex here. one of the 2 methods should be good enough. We need to And, I think if it's real if it's a really complex application, then we should go for Maintaining Redux as Redux, setup needs as the Redux boiler plate needs certain kind of setups which needs to be done in order for Redux to be used in the system. So if it's really complex and there's a lot of state, updations or state management happening. I would go with Redux. But if it's a simple to intermediate complex app, I would Rather use context or a third party library

Updated. So one thing that I Noticed here was, not having a proper component, as well as a function that would that would be involved when clicking on that button. So I think that's a mistake on the return statement where increment should click button. It was on click handler should be the increment count, and There we should be actually updating the stat state. This does have state. Count. And, Yeah. I think the second thing should be maybe we should edit, We should add a component date method where we should be performing certain operations.

A message, just send that pass. Update chart. Notification. Show notification. So firstly, I would add a proper mechanism for dry catch. Like, let's say that some error on, just a note pass. I would have some proper error handling then. Second thing is this if else letter Doesn't really seem to be extendable so that I would, I would try to add a switch case where based on the case, I can, call out certain functions, or I can invoke certain functions. Yep. I think these 2 things should be enough to ensure robustness as well as maintainability and extendability.

Alright. So okay. So, firstly, at the components level, I would be using React bound, React error boundaries in order to ensure that if something breaks or if a component throws some error, it does not break the application or Show a blank white page or some errors. So first thing, implementing React error boundaries, I would be adding a custom component, Say, which I could display in case of any errors. Second, I would integrate some tools like Sentry, which So which handles all that kind of errors that the application is throwing and Give me visualizations on what component basically give me a proper stack trace of the error that has been resulting The application and which components is showing the error. Using analytics provided by Sentry, We could easily eliminate most of the errors and ensure that such

In a scenario where your SaaS application built with React, it's quite Quickly due to surge in user base. So this, I would say, is more based on how the scalability of the back end would impact. But in terms of To get app, I would ensure that there would be minimum number of requests that I should be making to back end or any third party applications. And, also, in order to ensure that there is very less wait time. Also, what I would try to do is I will ensure that data that I'm storing in the state, the state does not becomes too heavy, which becomes difficult to actually render the DOM. What I would also ensure is I only pass the bare minimum or the needed data to my child components so that it, the payload or the data exchange does not really take a lot of time. I would also try to keep the bundle as small as possible To ensure the overall application is on the lighter side and it I would try to avoid heavy images to be loaded on the app and, scale them down before, rendering on to the UI.