Shubhom Chatterjee

Hi. So I'm 5.2 years into web development as a full stack. It's a split of 60% front end, 40% back end. On the front end, I've mostly been working with React Native, Next.js, HTML, CSS, and JavaScript. And on the UI part, it's mostly been using SaaS, less normal CSS, Bootstrap, and Material UI frameworks, as well as Tailwind. On state management, it's been using Redux with Redux Toolkit and Context API. On the back end, it has mostly been Node with Express, MongoDB, PostgreSQL, and MySQL. So that's my introduction. I also have three apps live right now on the Play Store: StockX Social, and Geogram. And I've worked for brands like Mercedes-Benz, SHRM, and Verathon, like medical companies also. So, that's my introduction. And all the greatest achievements I think I have in my career so far is writing an app from scratch that's Stockage, and taking it to the market where it has over 1,000,000 downloads and 20,000 active daily users.

So to make an efficient webpack build process for React and TypeScript, we need to change the TypeScript configuration, make one of the files that will convert to JS, also one of the entry points for the JS files, the output directory for the bundles will be. 2nd is for the CSS, the entry points for the CSS will be, the output directory of it will be. And accordingly, we'll have also that whether it is a module structure or not that we will define in the webpack. And also, if you're using micro front ends, that is also configurable in the webpack. And for the TypeScript project, we have the tsconfig.json, and that is basically a configuration for TypeScript. This will make sure that the TypeScript features and certain configurations of it run in your project. So, that's about it.

Okay. So to merge a call to resolve a merge conflict between two branches, I'll give you an example. So let's have a branch. Okay? I have pulled a branch from the repository, and I've got conflicts on it. So to do that, I'll first synchronize my code with the other developer whose branch I'm having the conflict with. Okay. I will always take the latest pull from the main branch so that every day my code is synchronized and I make daily commits and daily pushes. Okay. And now if I have merge conflicts between two branches, then what I will do is basically take my branch, go to the merge conflict resolver in Visual Studio Code, and go to each file where the merge conflict is happening. And I will have a call with the other developer to determine which change I should keep, the incoming or the current one. And accordingly, I will save that file and commit that file to the gate. Okay? Now, I'll take the latest pull, and I'll synchronize my branch. So this will resolve the merge conflict on it.

Okay, so storybook is basically a documentation software where we can create individual components and also test them out in isolation. So, it'll create a storybook for each component. Let's say we are creating a button component, so component slash button dot t s x. Inside that, we'll have components slash button dot t s x and another file called button dot stories dot t s x. Yeah. So that story will basically have all the props, the actions, and the elements of the button. And we can create the story for it, and we can run NPM run storybook. So this will help by creating all the components, building them, and showing them in the storybook. Any developer, backend or frontend, if they want to know about the working of a component particularly, they can come here, test it out, and see how a component behaves on particular scenarios or with particular props or actions. And accordingly, they can work. And designers can also review the components in the storybook URL, which will be deployed, and they can see the documentation. They can see what the component does, how it looks, how it behaves, and accordingly, they can make changes. The same goes for backend as well and frontend as well.

So the critical factors to consider when choosing different NPM packages for a project will basically be the number of downloads. When it was last updated, are there any security concerns? Is it compatible, and also the weightage of it. Like, how big it is? How will it affect the bundle size that I'm creating? So, these are the things that are to be kept in mind. Also, make sure to update regularly and check for audit fixes using NPM audit fix. This will help you identify any outdated packages that pose a higher vulnerability of security exploitation, which can be removed. Also, it depends on the compatibility of the package. The factors to consider are downloads, security, the last published date, how active the library is, and how active the developers are on it. And, whether or not it has any security loopholes that can expose our internal data somewhere else.

So if it is a JavaScript code base so I'll first identify the common things that are being used, such as components or schemas, and give them types. We'll create the interfaces for it, the types for it, which will be reusable across the places. So type checks, like, let's say, whether a person is an admin or not, so that's a true or false. So we can accommodate it into one type that is user or admin. So, accordingly, we can set the types for it. We can generalize the interfaces and extend them as and when it is required in the components. And, also, for every single event handler on click or change, we have to add the types to it. And, yeah, that's all it. And, also, we have to give the type of HTML development for each HTML element. We can give that type so that it takes in all the props of the element and the types and type definitions that are there. Okay? And, accordingly, we can work over there. So this will be. Now, first, is to take out the common things which have been across the project that are being used. Take that and generalize that what are the types we can use on this components, take up, which is getting mostly used, the components. Define interfaces particularly for that component, and see if it is also shareable across other components or extend it if it is needed or not. So these are the two things. The third thing is, for the schemas or similar prop types or the similar types of data that will come up on the APIs. So we can put that types also when on the response and attach it to the responses so that the type mapping is safe. And, I think these three things only can be there.

So this might cause unnecessary re renders, and how do you optimize it? Okay. So we can make it a pure component, firstly, this thing. And the second is, we can convert it to a class component, and that'll be a pure component because that will not re-render. And to render this, we need to attach some conditions, that is, if it's a prop, we can add the 'is active' or something of that sort. And if it's not active, we can send any other element over there. Otherwise, we can return this. This is basically returning an empty template so that will be an error. And that's why we can use a pure component. We can wrap this component in React.memo. So what will happen, React will memoize this component, and it will prevent it from re-rendering. And yeah, so I think a pure component and React.memo.

Okay. So firstly, we can replace all those if else using the switch case. Okay. And we can specify the return type, specifically. And this is the second one. The third is the third is and if it's bird, fly legs. Also, we if you are going with the if statements, also, you can add an else over there so that by default, it does not throw the error of unknown word when this is getting run. And also, we can take the sparrow and the penguin as the bird type. Right? We can take it as a bird type, and we can define those types just below the interface itself. That's what are the types of the birds that you want to be over here so that we can match the type over there. Okay? So we don't need to take a string instead. Okay? So we can define the bird type. Secondly, we can add the switch case. Secondly, it's better if we take this if we can define a JSON object, and in that JSON object, there will be a key, which has let's say two methods, and we can say that accordingly we can respond accordingly to the method what it has. Right? And so instead of writing so much if and else nested code, we can add a switch case. And in that, we said that if the case has this key, okay. If the case has this key, then do according to the key dot fly and key dot lay eggs. So what it will do is console dot log will basically read from a JSON. Okay? And it will give us the desired result. And the bird type is a string, and that's why we can define the bird type itself.

The process of ensuring that React components are usable across multiple projects is basically decoupling the logic as well as the UI from it. So both of these things will be decoupled and define the interfaces for these components. Also, make it type safe and make it prop driven. Instead of hard-coded data, make it prop driven and document it in Storybook. And we can use micro frontends over here to share the components across multiple projects. And fourth, we can create micro frontends out of this. Fourth is basically about dynamic content and also the error handling of these components. If there's something that's going wrong, you need to handle the error and the edge cases too over here. So I think defining the interface, making it prop driven or data driven that is dynamic is key. Second is handling the error handling. Fourth is basically stateless. Fifth is basically creating a micro frontend architecture that will help you reuse all these components across projects.

So we have written in a test case. So I was working on a project that was on the stock market. So now you know that a lot of data changes dynamically all the time and the chart also changes. Right? So we use D3 for it, and we wrote a component test cases regarding the x axis, the y axis, what the ranges should be, what the ranges or the domains should be according to the data that is being mapped, and also responsiveness of it that is how it should behave on the resize of it. And then, the third is basically that we were looking for something that new data is bringing, and we wanted it on the DOM. So we wanted to check that if that element is in the DOM or not, that data is in the DOM or not. So this way, we wrote the test cases, and it was around 15 test cases we wrote regarding these charts. And it was quite critical because the data was ever changing, and the charts had to be responsive. The charts had to map the perfect data out for them to put the perfect domains and ranges on the x and y axis. So that was a very critical test case that we wrote because it was the core of the entire app. Anyone who is coming on the app is coming to see those charts. They're not here for any other feature. They're coming here to see those charts, analyze those charts, and those charts mean a lot because that can be summarized, that can be analyzed. You can have the technical and fundamental analysis out of it. So it's very critical to the reputation. So, yeah, that's one of my most critical features that we have tested out.

To keep up with the best practices in front-end development, I regularly follow the Medium dev.to blog, and also follow daily code with Antonio web project on YouTube, as well as freecodecamp.org. I regularly subscribe to newsletters, such as Medium and others. I'm also an active member of the developers community in the Reddit channel. So I keep getting updates from there, and accordingly, I put the best practices into practice. And I also follow Harkir Singh and Akshayani on YouTube. We put their practices to the test on our own projects because, you see, these people have worked for large-scale organizations and enterprises. So the thought process they bring out, the modern approach they bring out with every single update, and how we can replace old methods with that and optimize it. So I keep up with that. And also, I'm learning about developments like web assembly with Rust and p5.js. So, yeah, these are the things I do to stay updated.