HARsha VARdhana B

I am a web developer, primarily working on JavaScript and launching stack, and I am focused more on the front end compared to the back end. I have been working on web applications since 2017, starting with a simple static site server and plain HTML, CSS, JavaScript sites to React and Next JS based applications in my latest projects. I tried a little bit of Python and web automation and data scraping in between, but I didn't stick with it. Apart from that, I have been part of both b to b and b to c web applications, where I was the founding engineer of the team. I later was acquired and part of the acquisition. I was part of the core team, followed by where I was responsible for bringing up the whole UI with a team of other UI developers. I had to take up the responsibilities of facilitating the feature discussions between stakeholders and the tech team. And you know, understanding the requirements from the stakeholders and marketing team and translating them to the technical stories for the UI side. Later on, we emerged into three different streams on the UI side, because we had three different applications, b to c and b to b including. So I was more of a face of the whole front end team, consisting of 10 UI developers including me. So I was responsible for both understanding the technical stories and translating them to the UI stories on the scrum boards and running the update calls in the first half of the day and followed by assisting the developers and managing the load of the work. That was for more than close to two years. Later, I joined a start-up where I was a solo contributor to the whole stream of non-data scientists, data analysts, and business units to understand their UI requirements and build them certain web portals to help them ease their internal work and understand their features better. Later on, I moved on to another firm where I helped them to productionize their prototype NextShares application and go to production in a quick manner while also solving their one of their existing onboarding issues and smoothening their onboarding flow. And I also helped them revamp their whole UI and deploy.

What approach do you take to ensure APAC is made efficiently in a React application already on the same network requests? One approach I would take is, for the same fetch call or same post call on the same endpoint, I make sure that there are no duplicate calls happening by maintaining a simple flag when an API call is being made until it is responded or handled. Right? That is one basic thing I would do to avoid unnecessary network requests at the application level. Even at simple UI elements level, I followed the balancing rule to prevent duplicate fetch calls or such calls. These are the two major things I usually follow. And also disabling user-interactable components that would cause post calls or any data submission calls. I follow, you know, I disable the UI elements that would trigger the API calls. Once an API call is triggered from the UI, I disable the UI events until the request is processed properly whether it is successful or not.

We will ensure that we use beta React components in different projects or teams. Oh, good. Great. This starts from designing, I believe. If we are working on different projects or teams with similar themes or the same functionalities. I start with the designing phase. I make sure that the designers are aware of the fact that we are trying to reuse components across multiple projects or teams in a given organization or environment. And I ask the designers to stick to the same design standards and codes. We also play by the same rules when building the React components, using the same theme across multiple teams and projects. Having a style guide for these components is an added benefit. This way, we have quicker feedback loops with the designers and stakeholders of the components and can reuse the components we are building. I would maintain a separate library for this, and we can import components from that and use them as needed. I strongly advise and make sure that the developers follow the same standards, that they are not writing their own components that are already part of the reusable library or common library across projects. If such a thing happens, I also make sure that the PR reviews or peer reviews happening across the team are looking out for these kinds of issues.

When choosing between using a class component versus a functional component with hooks in React, there is no consideration at this point in time in the current and latest React library functions. It's always hooks and functional components. There's nothing that class components could provide that functional components with hooks couldn't provide. So, there is no consideration at all unless I'm dealing with a legacy project that has been written in a certain React version that needs certain class component functionality. If not, I would suggest starting your React project in the latest version and start using hooks and functional components. If you are using some old React version in a big legacy project, there is nothing we can do but follow the class component or at least try to migrate a little by little every once in a while and try to migrate from class-based components towards functional components.

Practices for ensuring accessibility in your React components is a part of your component development. Components even though you are writing your own custom React component to achieve the same. For example, a radio button or a toggle button or any kind of input that you're taking from the user, try to use an input tag in your React component while writing. No matter how much styling or customization you need on the component, try as much as possible to use basic HTML tags and semantics so that your React component at the end of the day, even if it is a React component, translates to HTML and CSS. So the closer your React component render is to a HTML basic component, the better it is always. There are another example. Always link your labels to your inputs or link your labels to your checkbox input so that the HTML render knows that this certain label belongs to the certain input or this certain label belongs to the certain checkbox. And try to follow the same stuff with forms, tables, lists, and also follow as many, like using now, header HTML tags inside your components will just improve the accessibility to the next level. You don't have to go and implement all the accessibility features for people with disabilities or anything. Just sticking to basic HTML norms will give you 60 to 80% of the accessibility.

To refactor large component to smaller, more manageable components in React, I follow these steps: To apply the Single Responsibility Principle (SRP), I break down the large component into smaller responsibilities even if the whole large pair component makes sense in a single component. I try to understand and break down the functionality of that large component and break it down into smaller functionalities first. The moment I can break down the functionality and responsibility of the huge large component, I can come up with smaller React components that could act on their own and be meaningful on their own. And I might need a little bit of common state or shared state between these components, which can always be achieved by props and callbacks. But breaking down the responsibility, breaking down the functionality of the huge chunk of React component is what's gonna drive us to the smaller and more manageable React components. The moment you can break down the functionality, you have already broken down the React components. It's just a matter of writing that React component to achieve the function.

Even this type scripts reproduce in a React code base, identify the potential could follow and provide an explanation. Interface person has name and age. Display person takes a person, console dot log, person dot name, person dot age. The interface person has name and age as keys and the data types provided in the interface and which is referred to in the display person function as person type, which will, be utilized inside the function. But, when declaring the person data, there is also an additional, there is an additional key value pair inside the person data, which is not expected and which might break the, which might break the execution flow, basically. Either we could add one more, you know, key called email inside the person interface. Or yeah. I think that I only think that's the only answer.

How would you bug this piece of code in a real component where the data fetches from the API is not rendering as expected? The component did not fetch this dot state dot API data. The API data is set to catch. Return some HTML tag or maybe React fragments to render that data. Currently, the return statement is a simple JSON object wrapped in a flower basis, which is not a valid JSX format. Moving forward, if that's not the case, if the API call is not perfect and the response is not returned as expected, then you'll check for the error. If there is no error, that means the API call was perfect and the response is returned as expected. Next, you'll check if the data that we are trying to render is not valid. It might be an empty array or empty object or null. Null could render null, which wouldn't render anything in a valid JSX format. So, if there is no error and if the render function is returning a valid JSX format, the data might be null, so checking for the type and value of the data is the last step.

Always start small. Pick up certain data set or the data that is small in size and used in lesser known places so that refactoring becomes easier, and we know what we are dealing with. So pick up the dataset that is used in less spaces, less instances across the application, and has no impact. Refactor that first, implement the context API end to end in that manner. Once that is done, remove that from the Redux code state management and see if it is working or not. If it is working as expected, move on to the next and go on with refactoring. That's as simple as I could say it is. Pick up the least and small as possible and go from there to the largest and most used dataset and refactor everything into more small, manageable contexts. Don't keep everything in the same context. Try to break down the context into as many and as meaningful as possible and as relatable. The context should be meaningful on its own and as well as should be reusable. Just because it is full and not reusable at all doesn't mean we create a number of unnecessary contexts. Try to keep meaningful data together and reusable data together.

Here are ways to improve real time and reduce the bundle size of a large scale React application. Imports start with imports. Don't import a whole library just because you're using a certain model from the library. Import only what you need, you know, module based. If you can see, you can even in the dependencies in package.json, you don't have to mention the whole package. You could mention only a certain module from a package that you need. And that way, you don't have to deal with the whole library while creating the bundles and bundling and sizes. Also, try to use lazy imports, or chunking down lazy imports. Lazy imports is basically not bundling the whole application into a single bundle, but bundling it into as small and as many pieces as possible and serving them on demand.

Describe your approach to monitoring and improving the performance of your application in production.