Rahul Ajrekar

Yeah, myself, Rahul Azrikar. I am working as a front-end engineer. Like, I'm currently not working in it right now, but I was working as a front-end engineer in my last company. It's been 6.5 years. I'm into front-end tools itself. I've worked on multiple frameworks, basically, Vue JS, React, HTML, CSS, JavaScript, TypeScript, GraphQL, and testing unit test cases also. So, yeah, basically, I worked on multiple domains also. Basically, like, marketing domain, retail domain, banking, product-based companies also. Like, they are data products and everything. I've worked from startups to MNCs also. So, yeah, basically, I feel pretty much confident in this role also.

And most critical factors to consider when choosing an NPM package for a project are, basically, when you choose an NPM package, the version definitely comes into play, whether that package supports your current Node version, going forward if you want to scale that component specifically. For example, if you are using a data table, it might need some changes going forward as per our requirements. So we should see how much you can extend that package, how many modifications and customizations you can make into that project. And, yeah, these are the things, basically. Also, if your application is in React or Vue or whatever, you should also check how the package can support your framework and the application you're using. Yeah, that's what you want to look after. The more important part is how much you can customize your package. Because most of the time, the challenges come from there itself. That's what I've faced in my earlier experiences. So that's it. That is what you want to consider.

Yeah. Using TypeScript for unit testing is the best thing I've experienced in my last project. So we were deaf; we were kind of using so first, we in our project, we had a lot of components that were used from some other library, basically. And we decided later on going forward, like, we should be creating our own component library. And there we should, like, develop our own components and also write a storybook for that. But along with the storybook, we decided to also write some unit testing for each of those components with TypeScript. So basically, all of our components which were earlier in the project were written in JavaScript, and those who are being transformed into TypeScript again. So while developing these things, I found out, like, we implement the component in a very strict, but still unbreakable way, basically. Because even if you were trying to pass any kind of other prop to it, like, instead of a string, you're passing in a null object or an object itself or an array. We definitely had control in the component at the component level to decide if you want to accept these props or not. This would prevent our component from reducing a lot of bugs, basically, and showing a lot of prevented errors in our component. Yeah. That was the best idea, like, the best decision they made, and I was lucky enough, I can say, to get a chance to work on those things also recently.

In a component process, how do you decide on the granularity of the component, okay. So, for example, in your whole application, you have divided the components, like, describe and define the components and you have used that in your whole application. Suppose we can consider an example of a data table itself. A data table would have a lot of things in it. We can modularize it or granularize it at different levels. Basically, we can make a different header component in it. We can make actions, like, if we have an actions component or a column, so that we can have actions like button items into it. We can create that separately. We can have a pagination component separately, and if you want to show some nested level of data into our columns or rows, we can have that particular component separately, and with props we can decide if we want to show that component or not. So, yeah, definitely, we can modularize these kinds of components easily. I've done this already, like, in my recent project, one of my pet projects. So I had to implement headers dynamically because if you're using a data table, you won't have any headers defined specifically. What I did was implement sending a JSON data itself and choose what columns should we show and what shouldn't be shown. So I gave that prop to it, and we were showing only those specific columns and like, data, basically, what you want to show into the data table. So, yeah, I had done this recently, and it works very well, basically.

Should we approach creating an efficient webpack build process for a React and TypeScript project? Should we approach creating an efficient webpack build process for a React and TypeScript project? Okay, for webpack, basically you can start by defining the necessary configurations at the beginning of the project. You should define the needed loaders because if you're using CSS libraries in your application, you need to define some loaders or plugins to use them. After this, to make the build process efficient, you can use a library that takes out specific methods from libraries you're using, such as lodash, and builds the bundle, negating everything else. This reduces the bundle size. You can also use obfuscation, minifying of CSS, and code splitting at the code level. You can define customizations here as well. And yeah, this is all I can remember so far.

Using lazy loading of components in an application breaks down your component bundle size into chunks and requests those chunks only when needed, instead of prefetching the whole bundle itself. This would make your application's page loading faster, because you're not loading the whole bundle.js at once in every routing. So basically, that's what you want to do by using lazy loading. We can use this best at the routing or component level, and then you can define the nested components or whatever components you're using in your app, like parent components, using lazy loading there. There's no harm in that. However, you can avoid very small components if they're static, like pop-up modules. But definitely, lazy loading helps to break down your application's bundle size into chunks.

Okay, first of all, there are no props or anything being okay. I'm considering this component as a kind of boilerplate and we might do something in this component and it might go into the rerendering phase. I would explain how we can optimize any component basically. So you're not using any useEffect here with the empty array, first of all. And if at all you are passing some props to it or maybe some changes, props are being passed to the component, but it's not controlled in any way. For example, we are not implementing this component in a pure component form. This might cause re renders again. You may use the memo hook for this to prevent rerendering of this component. You can definitely use callbacks. If we are using an HTML element with no callback added to that, it would cause rerendering even before clicking or triggering that.

Okay, first, we're defining the interface Bird here with fly and lay eggs as the properties in it. I think we should not define this in such a way, we should be using either the parentheses and the return type of that function. And, yeah, and not definitely, I mean, in this way. Apart from that,

This is my experience with testing Internet applications. Okay. So, suppose you have a component already existing that is a login page, and you're writing some unit test cases for the login component. Definitely, you might have described few of the types in your login component itself, but when you're writing the unit tests for that, you may do definitely if it's a small component. You can just go on and grab pure interfaces or types, whatever you're defining in your component. And just grab those and copy paste those. But suppose going forward, if you are making some changes or adding some types again to your login component, it's better to export that same type or interface from the component itself and you can use the same thing in your testing file. Usually, it's a better idea to keep the types file separate from your component, at the same level, and then it's very easy to import it anywhere else, like in your whole application, basically. This would definitely prevent the interference of the types in your testing file and the component file. But also, if you make any enhancements to your login component itself, it would also make or give some errors again in your application because the same type is being referred over there. And some of the test cases may fail or won't run, the coverage might not come entirely. So, yeah, this might help you.

Which will process front-end testing and development and deliver your project. So, I usually follow in my initial days the style of my working with TDD was a bit different. I was not so much into test-driven development basically. It was like I just used to get some task and continue with that. I'd just get started on the coding part and then come back with test cases. But as I grew up and understood a few things, I understood that we should, whenever we get a task, discuss it, find all the use cases of that. Suppose you're developing the login page itself, you should discuss all the scenarios with someone or go through the component itself, like the login page itself, and note down a few points. Once you have these points, you should definitely first write the unit tests, like empty unit tests, for the cases where you need to cover the code and everything. Once you have all the test cases ready, then you might go to the code and write everything. Those tests should handle these scenarios again in your code. Once that's complete, then you might come back to your test file and write the complete unit test cases. This is the way I follow usually in my development style.

There was a component, basically. We developed this page, which had everything, including tiles at the top, an accordion, and a tab component. Within the tab, there were also some accordions, and everything had to be developed dynamically based on one single API's response, so that every API would return used data with a lot of JSON fields. However, everything was categorized into 4 categories, and those 4 categories had to be shown in 2 different tabs, one tab component with 4, another with 4. That was a bit challenging because we had to take care of the optimization part, the performance, and also the consistency of the data, which was changing only on the basis of a single flag from one of the keys in that JSON. So, yeah, this was a bit challenging. I think I first did was, whenever I got the response of the data, I wrote a snippet of code to categorize the data and store it in a JSON object, which I then stored in our application using Redux. Once that was done, I had to render the tabs based on the categories available from that response. Suppose instead of 4 there were 3 only coming, I had to show only 3 of them. So, yeah, this had to categorize it at the initial response itself, then display it in the UI. As the data was huge, I had to optimize the loops and then dispatch the action to Redux to make these changes happen in the UI. That was a bit challenging.