Shubhom Chatterjee

Hi. So I'm 5.2 years into the web development full stack. It is a split of 60% front end, 40% back end. On the front end, I've mostly been working with the React React Native, uh, Next. Js, HTML, CSS, JavaScript. And, uh, on the UI part, it's mostly been SaaS less normal CSS, uh, bootstrap and material UI frameworks, Tailwind. On state management, it's been redux with tank and context. On the back end, it has mostly been node with express, uh, MongoDB, and postgreSQL and MySQL. So that's my introduction. I also have 3 apps live right now on the Play Store, StockX StockX Social, uh, Humana, as well as Geogram. And I worked for brands like Mercedes Benz, SHRM, and, uh, Verathon, like, medical companies also. So, yeah, that's my, uh, introduction. And all the greatest achievements, um, I think right till now that I have in my career has been writing an app from scratch that is stockage and taking it to the market where it has a 1,000,000 plus downloads and, uh, 20,000 active daily active user base.

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, what will be the output directory for the bundles. 2nd is for the CSS, what will be the entry points for the CSS, what will be the output directory of it? And, accordingly, we'll have also that whether it is modules module structure or not that you 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, uh, project, also, we have the tsconfig.json, and that is basically a configuration for TypeScript. And this will make sure that, uh, the TypeScript features and certain configurations of it run-in your project. So, yeah, that's about it.

Okay. So to merge, uh, call to resolve a merge conflict between 2 branches, I'll give you an example. So let's have a branch. Okay? I have, uh, pulled a branch, uh, from the repository, and I've got conflicts on it. So to do that, I'll firstly, uh, synchronize my code with the other developer with whose branch I'm having the conflict. Okay. I will always take the latest pull from the main branch so that every day my code is synchronized and daily commits, daily pushes. Okay. And now if I have merge conflicts between 2 branches, then what I will do is basically take my branch, go to the merge conflict, uh, resolver in the Versus code, and, uh, go each file where the to each file where the merge conflict is happening. And I will, uh, have a call with the other developer that or what is the change that I should keep the incoming or the current one. And, accordingly, I will, uh, save that file and commit that file to the gate. Okay? Now, uh, in 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, as we know, is basically a documentation, uh, software, uh, where we can create individual components and also test them out in isolation. So, uh, it'll create a storybook for each a story 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. Yeah. So that story will basically have the all the props, the actions, and the element of the button. And we can create the story for it, and we can run NPM run story book. Okay. So how this will help is, basically, uh, it will create all the components. Uh, it will build all the components, and it would show in the storybook. So any developer back end or front end, if they want to know about the working of a component particularly, they can come here. They can test it out and see how a component behaves on particular scenarios, on particular power props or actions. And, accordingly, uh, they can work. Okay? And designers can also review the the components in the storybook URL that will be deployed, and they can see the documentation. They can see that what the component does and how it looks, how it behaves, and, accordingly, they can make the changes. Same goes for back end as well and the front end as well.

So the critical factors to consider, um, different NPM packages for a project will basically be the number of downloads. When it was last updated, is 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 that is one thing that these are the things that are to be kept in mind. And, also, make sure to update regularly your, uh, check for audit fixes so it will be NPM audit fix. So any outdated packages, you can know which pose a higher vulnerability of security, uh, exploitation that can be removed. And, uh, uh, with more downloads, you have the assurance of the community that, okay, this is something that people are working on, that are people using. So we can use this too and have a great support in the future. Uh, also depends, uh, what is the what what is the compatibility of it. So these will be the factors. What is downloads, another is security, another is last published. How active is the, uh, library? How active are the developers on it? And 5, that, uh, whether or not it has any security loophole that can expose our internal, uh, data somewhere else.

Okay. So if it is a JavaScript, uh, code base so I'll firstly take out that what are the common things that are being used, let's say, components or let's say, schemas, all these things. Right? So we will give them the 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, if there is a JavaScript check that whether a person is an admin or not, so that's a true and false. So we can accommodate it into one type that is type user, admin, or user. So, accordingly, we can set the types for it. Uh, we can generalize the interfaces and extend them as and when it is required in the components. And, also, uh, for the, uh, every single event handler on click on change, we have to add the types to it. And, uh, and, yeah, that's all it. And, also, we have to for each every HTML element, we also have to give, uh, the type of HTML, uh, development. We can give that type so that it takes in all the props of the element and, uh, the types and type definitions that are there. Okay? And, accordingly, we can work over there. So this will be. Now firstly is to take out the common things, uh, which have been across, uh, 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. Okay? So these are the 2 things. 3rd thing is, uh, basically, uh, for the schemas or, let's say, the similar prop types or the similar types of data that will come up on the APIs. Right? So we can, uh, we can put that types also when on the response and attach it to the responses so that, uh, the type mapping is safe. And, uh, 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, uh, this thing. And the second is, uh, firstly, pure we can convert it to class component, and that'll be a pure component because that will not rerender. And, also, to render this, we need to attach some conditions that, uh, let's say, if they're a prop, uh, we can add the is active or something of that sort. And if it is not active, we can send, uh, any other we return any other, uh, element over there. Otherwise, we can return this. And this is basically returning an empty empty, uh, template so that will be an error. And that's why we can use the pure component. We can wrap this my component in react.memo. So what will happen, React will memoize this component, and it will prevent it from re renders. And, uh, yeah. So I think pure component and react.memo.

Okay. So firstly, we can, uh, replace all those if else using the switch case. Okay. And, uh, we can specify the return type, uh, return types over here, the specifically. And, uh, 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 a else over there so that, um, 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 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 don't need to take a string instead. Okay? So we can define the bird type. Uh, second is we can add the switch case. Uh, second is that, uh, it's better if we take this, uh, if we if we if we can define a JSON object, and in that JSON object, the will be a key, which has, let's say, 2 methods, and we can say that, uh, accordingly we can, uh, respond accordingly or to the method what it has. Right? And so instead of writing so much of if and else nested code, we can add a switch case. And in that, uh, 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, uh, console dot log, it will, uh, it will it will basically read from a JSON. Okay? And it will, uh, give us the desired result. And the board type is a string, and that's why, uh, we can define the board type itself. So yeah.

Okay. So, uh, the process of ensuring that React components are usable across multiple projects are basically decoupling the logics, the decoupling the logic as well as the UI from it. Okay? So both of these things will be decoupled and define the interfaces for these components. Also, make it type safe and, uh, make it prop driven. Instead of hard data driven, make it prop driven and, uh, document it in storybook. And, uh, we can use micro front ends over here to share the components, okay, across multiple projects. And, uh, 4th, uh, is we can create a library out of this, but no need. We can create micro front ends out of this. Okay? 4th is basically a dynamic dynamic contents and also the error handling of these components that if there is something that is going wrong, you need to handle the error and the edge cases too over here. So I think, yeah, defining the interface, uh, making it prop driven or data driven that is dynamic. 2nd is handling the error handlings. 4th is basically, uh, um, 4th is basically, uh, stateless mostly. 4th is, uh, 5th is basically creating a micro front end architecture that will help you reuse all these components across the projects.

So we have written in a test cases. So I was working on a project that was on the stock market. So now you as you know that a lot of data changes dynamically all the time and, uh, the chart also changes. Right? So we use d three for it, and we wrote, uh, a component test cases, uh, 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, uh, responsiveness of it that, uh, what it how it should behave on the resize of it. And then 4th is uh, 3rd is basically that we were looking for something that a new data is bringing, and we wanted it on the DOM. So we wanted 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. Uh, charts had to map that perfect data out for the they had to put the perfect domains and the range and the skills they wanted on the x and y axis. So that was a that was a very critical, uh, test case that we wrote because it was the core of the entire app because anybody who is coming on the app is coming to see those charts. Right? 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 the fundamental analysis out of it. So it's very, very critical to the rep. So, yeah, that's my one of my, uh, most critical, uh, features that we have tested out.

So, uh, to keep, uh, you know, keep up with the best practices in front end development, I regularly follow medium dev.tologrocket blog, and, also, I'm, uh, following daily, uh, code with Antonio web project to Prodigies on YouTube, uh, as well as freecodecamp.org. I regularly subscribe to newsletters, uh, like, uh, different newsletters, like Medium and all. And I also am a active member of the developers in their channel in, uh, Reddit. So I keep, uh, getting, uh, updates from there. And, accordingly, I put the best practices out there. And, also, I follow Harkir Singh, Akshayani, on YouTube. And, uh, we put, uh, like, we put the practices on the test on our on our own projects because, uh, you see, these people have been working for large scale organizations, large scale enterprises. So the, uh, so the thought process they bring out, the modern, uh, approach they bring out with every single update and how can we replace the old methods with that and how can we optimize that. So I keep up with that. And, uh, also, uh, developments like web assembly, I'm learning, uh, with Rust and p5.js. Uh, so, yeah, these are the things how I keep updated.