Manish Parui

Hi. My name is Manish Paravi, and I'm a senior software engineer currently working in a Calcutta-based IT company with 5 years of experience. And previously, I worked in a Jaipur-based IT company as well. So, in my day-to-day work, I closely work with stakeholders to understand their requirements fully and eventually suggest solutions to them. Once the solution is approved, I do the coding with my team and deliver the coding, which meets the client's expectations. And if I talk about the technology stack, which I have worked with, I mostly work with front-end technology, but I do have a little experience with back-end and cloud technologies as well. So, front-end, I'm currently working with React and Microfrontends, mostly. And previously, I worked with Angular, and I have worked with HTML, CSS, Typekit, and JavaScript. And on the back-end side, I mostly work with Node.js, and I have a little experience with Laravel as well. And on the database side, I have worked with DynamoDB and MySQL. And on the cloud side, I mostly work with AWS and have a little experience with Azure. And I also have experience with agile methodology tools like Jira and other tools such as Trello. And I also have experience with quote management tools like GitHub or Bitbucket. This is all about me.

We can use the CMD environment. What it will do is, like, when we are building any application or running it on a local environment, we have an option to mention in a particular script comment that if it's the environment. So let's say we have an environment called develop stage and production. So if we mention in the script that it's a develop environment or the production environment, it will eventually pick up the environment file based on that. Yes. Also, we can mention the environment file name as well. Let's say the environment dot development, dot something or maybe development dot the environment file. So if we do that, we eventually pick up the different environment file, which is named as a development dot environment or production dot environment, and which will hold a different environment variable, let's say, for an API signature, there will be some token or maybe some API-based URL will be there. And eventually, if we do that, we will end up using multiple environments using Webpack or NPM.

So if you seem to affect the build process for a React and TypeScript project, we'll definitely try to include code security or code reliability kind of stuff using SonarCloud. Or, we may use ESLint or something like that. I'll use ESLint and Prettier for checking any linting problems and making the code formatted properly. Once the code is formatted properly, I'll run the unit test cases to understand how many tests are passing and how our code is performing. After that, we can integrate SonarCloud to understand if there are any anomalies inside the code or any major or minor bugs. Once that's done, we can go for building the application using Webex's internal function. And once the building process is complete, we will have deployable files, which we can deploy as well. If it's a TypeScript project, we need to compile that project to JavaScript. Once we've done this on our cloud script, we can do that before building the application.

So to achieve a lazy loading for a real application, what we can do is, like, we can first import the component. And also, we can mention it as lazy, in terms of routing or maybe if we are using a tab, we can also make it lazy. Like, if we are using Chakra tabs inside that, we can make a particular component lazy until and unless that particular tab is getting visible. We don't have to load that component. So in that way, we can make a particular component lazy. And if I talk about the benefit of being lazy, it's like, let's say your JavaScript component takes much time to execute, or it shouldn't be executed simultaneously with your other components. So to prevent that scenario, we can use lazy loading. So let's say we have a page which will do a heavy calculation based on something. So instead of loading it upfront, which the user may or may not visit, we can restrict the application to load that particular component by using lazy loading. And once the user visits that particular page or particular component, we can just load that component. So by doing that, what we can do is, like, we can free up the computation space initially. And eventually, our application will be much more responsive initially. On the other hand, we are not using the resource which is not at all required, because we might not know the user might not visit the particular page which contains the lazy component.

So what we generally do is, like, we create a separate CSS file for separate components. And that separate component, as in CSS, we have an option for nesting. So what we can do is, like, for a particular component, we can use a particular class with the CSS. And inside that class as a child, we can add other styling. So in that way, let's say we have a div element, and that is inside a login component. And also, we have a div element that is inside a register component. So now in a general scenario, if we just style that div, it will affect both the login component and the register component. But if we just wrap that div as a child with a parent of login and a register, it will act differently because the deep component style will reside inside the login component, and the same goes for register as well. But to do that, we have to mention a parent component, which will reside on each top-level component, now which will have a CSS class. And inside that class, we will write our own logic for other CSS design, like for a div or something.

To modify our application by using its configuration, as far as I remember, we can like we can previously modify the loading of the CSS file or the static images file. By doing that, we will be able to achieve a great load time on the application by using Webpack size. And also, using Webpack size, we can maintain our actual file size, which is going to get deployed eventually. So by doing that, we can keep a check on our file size. And if we try to compress our file size, which will force us to use the reusability of our application, we'll eventually write less code and reuse it for the proper application.

There's a weird course in physics. Why this might cause unnecessary rerenders. So in this component, I can see that first of all, it does something which is a function, which is an arrow function, which does not appear inside any other block like a useEffect or something. So if we call that function without the useEffect, it will rerender the application for unnecessary times. And also, we are going to hold an empty return function which can also cause unnecessary rerenders. I believe it should not be an empty return. It should contain something, like six elements. If we just wanted to make this component optimized and make it less redundant, we can wrap up the function inside useEffect. And I think that would be it. I don't find there's much issue with the component.

You know, from the issue in the task of interface and permission implementation, remote, and this really can be seen. So this box, we won't be fixed. Bot type. Still, I'll update. Bot type. I'm going to just try it. We can apply it. I want to find out how to do it. There is okay. So, first of all, the interface bird, which is having a fly with a void. And so, but it's supposed to be expected to return something, which is not returning anything. And that is fine. But if you ask me, I'd mention it, like, fly colon, then, open and close bracket, which is going to arrow, void, which makes it clear that it's an arrow function that expects no other argument, and it will eventually return void. And the same goes for the legs. Legs would be something like legs colon, open, close, arrow, void, which makes sure it won't take any arguments and will return void, which is nothing. And, also, on the function gate bard, there is a return type mentioned as bard, but we are not always returning the bug. That is, like, we are also throwing a new error, an unknown bug. We are not supposed to do that if we want to maintain the return type as bard, or maybe what we can do is, like, we can also mention that there will be a void as well. Like, we should expect that our return type can be frozen. So if we wanted to avoid it, we can do is, like, if the bard type is equal to and also else, the bard type equals penguin. Also, we can put another condition like else, which is going to eventually send a bard object or maybe a true error. But, again, if you want to include a true error, we have to mention void as a function written type as well instead of only bard.

What is your preference for answering that we have a component to be able to use for not crossing multiple projects? So if you want to make a usable component which is across multiple projects. So first of all, if we just wanted to make a reusable component for a single project, we have to make a pure component. It's in a generic scenario or in a proper scenario. It should not rely on state, which is not being passed as a prop. It should rely only on the internal state. So, it should be a pure component. Meaning, whatever input you give, if it's the same input given twice, it will produce the same output. That way, we can make that component pure. And now, come to the part of if it is usable through multiple projects, probably, we can make it as a micro fontent, or micro-fountain type, so that we can eventually import that component into multiple child applications as well as multiple parent applications, and that component can be reusable. So, to make it usable, a couple of things we have to keep in mind: the component should be in a pure form, and its return type should be defined. And I definitely want to use TypeScript if it's available, so that I can make the return type and the props input more typed, so that it doesn't get any type input while we are using that particular component in any other component. So, in that way, we can make sure that component is reusable across multiple projects. Yes.

Okay. So I would like to mention my correct project. That is a marketing simulation plot from a beverage company, which is AB InBev. In their particular section, we have a section called adjustment, which basically lets users adjust on a vehicle level. Let's say, it's a traditional vehicle like cinema, TV, and also on the digital vehicle like Facebook, WhatsApp, and Instagram. So it helps users to adjust their cost for a particular marketing stuff, marketing for a brand. And that adjustment kind of looks like a fee structure where we have a region, like an epic region or the EU region. Instead of that, we can have a country. Instead of that, we can have multiple brands. Also, we can have multiple countries as well, multiple brands. Instead of multiple brands, we will have multiple vehicles with their vehicle types. And that needs to be as per the application requirements, which need to be late rendered and also generated on the client's side based on user selection. And to generate that, we eventually ended up with 50, thousand data objects inside a single array. And to generate real-time in the user's application and to make it more performant and renderable without stalling the user's application, what we did is, first of all, we moved the entire app's calculations to the backend. But eventually, we found that was not suitable because we had to do real-time calculations. So we again moved the calculations back to the frontend. And now, what we have done is, JavaScript does not have any multi-threading operations or concurrent situations. To do anything concurrently, what we have done is, we implemented our worker function, which will run behind the scenes to generate our 50, thousand records and data. By doing that, we made sure our main thread is free while we are doing the calculation on the worker thread. And also, once the worker is done, we can just send a message to the main thread, and eventually, we can make it displayed. So by doing that, you're able to achieve performance and maintainability. We as we separate the code from our main app place and put it on the worker, that is an entirely different section. And by doing that, our code gets more modularity and hence, maintainability. And now, still, this thing is getting a little bit of an issue, so we are also exploring the WebGL kind of stuff, which Google has implemented recently. So we are looking forward to implementing it into our application to get more performance in the future.