Jagadeesh J

My name is Jagdish, and I'm from India. I have close to 13 years of experience. And in terms of front-end, I have around 11 years of experience. For the past 6 years, I have been working remotely, and I have worked with your distributor team across a lot of time zones. I started my career with a data center service where I was a back-end developer, and then I moved to front-end because I'm quite good in JavaScript. Later, I worked with a gaming company, and then I moved to a marketing company where I was working on product information pages and campaign pages. And then I joined Freshworks, which is a SaaS company. I was working in a product called Fresh Color. It's based on Amber and Ruby on Rails stack. So I was the only front-end developer in the team, and then I became the front-end lead, and there were around 6 front-end developers who worked with me. I was in Freshworks for around 4 years and a few months, and we launched Freshcaller, and we also scaled the team as well as the customer base. At one point in time, we were making 2 million in ARR. After Freshworks, I joined a US-based company. That was my first remote company, and I was working with people from a lot of places, including Brazil, Poland, and the US. I was in North Creative, which is a file-sharing and chat platform. So it was a Vue JS-based project, and I also implemented the desktop version using Electron JS. After that, I have done small contract jobs. Some of them include a product-based company from Sydney, which is Zoom to You, where I worked on helping the team to build their Google map tracking. And later, I also worked with the Japanese SaaS company called Otify, where I implemented a lot of features in the React product, and I also moved the Chrome extension version 2, to manifest 3. And then I started contract work with Turing, where I worked for Marshland Brand, which is a US-based company. It's a tablet manufacturing company with a lot of sister companies, close to 13 websites. So I worked with the brand site and marketing team where I helped creating a lot of features in their websites and unifying the code base. My contract ended on December 31, and I am looking for my next opportunity.

We can split that in multiple approaches. The first approach is to introduce a code splitting mechanism, not just for images, but for pages or conferences in general. The second approach is to use lazy loading, where we will not load the image at the beginning, but load it on demand. So, if we have a lot of images below the viewport, we don't have to make the application wait. We can just load the application and then load the images with proper skeleton and placeholders. Since we're talking about high-resolution images, one way is to have server-side rendering of images, where we can use libraries or utility tools like Tiny PNG or Tiny JPG to optimize the image in the backend. We can also have multiple versions of images. For example, we can have a server-rendered image in terms of sizes, so that when we're displaying it on a desktop, we can use a different size than when we're using it on a mobile. We can have an API that will say, "Image question mark with some width, let's say 100." This will be optimized for mobile on our end. So we can do it in real-time or do a cached version. These high-resolution images can be optimized. The reason is that we don't have to show the high-resolution image in the client unless it's something that's very detail-oriented. Let's say I want to load my avatar. It doesn't have to be data-oriented. Right? So we can save an optimized version in the server and then we can load it. Let's say I'm opening it or maximizing it. In that case, then we can load the high-resolution version.

I think one issue that I see is the fact that we are binding on the image even to the button on click, which may happen again and again when the component re-renders. For example, a component is always subject to re-rendering. So this is one issue that I see. And, I see another possible issue, which is we are using Emmet, which is not really scalable. For example, today I'm having a parent component, a JSL component. And tomorrow, I might have another component that will come in between this. So in that case, we may have to add one more Emmet event, and this is going to bubble up all the way to the top. So that's a lot of computation for the CPU. So, I would personally resolve this by going for a centralized state or action dispatcher management, which will not only make the code simpler, but we can use it in any place. And it will be independent of the parent component. So if we want to make any changes, then we have to go all the way up to the parent component and then make changes. But in the case of centralized action dispatcher, we just have to do it in one place and we can use it.

One thing that I will not use is to have a lot of properties in, drill down to the child. But I guess we can use context, so we don't have to worry about having multiple drill downs of properties. And this is actually in-built, so we don't have to use any external libraries like Redux.

Side effects. In general, hooks, the major problem that we face is when later that is happening, then the hoax may be called again and again. So one way to handle this, we can use properly passing the properties or properties that will trigger the usage of folks. And the second thing is, like, we have to make sure that we are not calling without any conditions. We are calling it based on certain conditions.

The first thing that I will do is make sure that the design is based on a design system. So, I will first create the basic components. For example, the boxes in which the conference will be fitted, and then the elements or the basic elements, like it could be a form element or it could be the typography or it could be the elements that will have some features, like chords or accordion. So, I will identify all the common elements and create all these common things. That will be my first step. And my second step is to make sure that I have a proper theming system so that in the future, if we have changes in the color, I can easily implement it. So, a lot of plugins are available for Figma where we can extract the colors and themes, which I'm sure Figma developers would have used variables. So, I will collect all the variables and make sure that they are applied to the top-level classes. And then, I'll start building the basic component based on the element-based component. For example, if there are cards used in multiple places, I will build those single card. If there are a lot of forms used in multiple places, I will build the input components first and then the general form. And once it is done, all I need to do is just input the components into the code and build the project.

I don't know what the meaning of state groceries is, but I can see the problem here where because the set state is actually not synchronous. It is asynchronous. So, we cannot honestly expect on the value of input value to be the target value on the next line itself. So, what we can do is make sure that we enable the submit button once the input value is set, or we can use the second argument of set state, which is the callback function required for calling. So, that's one way of doing it.

I think the easiest way to do this is to enclose the function in a try-catch block. I enclose the method in a try-catch block and make sure that if there are any issues, we'll catch the error and also display it in the front end so that the user knows that something is wrong. We can proactively cast the error even before it is being passed into the method. For example, if the types are not matching, we can just catch the error.

I think this is about traffic because the server might not be able to serve everything. So, since this is happening from a lot of people logged in. So what we can do is separate the concerns, and distribute them into different servers. For example, we'll be using a lot of responses from the server. For instance, if I'm logging in, I'll be having information about myself, my cart, or information about the product or the payment I'm listing. So, instead of sending everything, we can cache a lot of this information which are static, and we can have a flag that whether they are changed or not. We don't have to transfer everything from the back end to the front end. Some of them can be cached in the front end or stored in the local storage. And second thing is, we can split the services. If there is a particular service that is being used by a lot of people at the same time, we can see if we can split those services and make sure that the server is not overloaded. So, generally, front end being slow happens because of the services, the API calls are taking a long time. So, we can fix this effectively from a server side by segregation of concern, so the front end will look

(I'll wait for the text to edit)

So I have done this. I worked for FileClord, which is a file sharing software, and it had a monolithic architecture. When we transformed it, we first sat with the back-end team, and then we agreed on the APIs that we would have. First, we created a storybook. Then from the front end, we started writing microservices that would consume various main features. For example, there is a feature that lists the files, and there is another feature that handles permissions, and then something about this information. First, we agreed with the back-end team and split the API, creating a storybook. Then, let's say there are major routes. For example, a route for a user and a route for a particular feature. We can split the front-end team into those routes, and they can work independently. This way, the code base will not have a lot of conflicts when users are working, and it will be easy to integrate. The second thing is to write unit test cases so that when we develop faster, we don't file mistakes, and we won't form any regression issues.