Software Engineer
IG Infosystems Pvt. LtdSoftware Engineer
APISERO Global Integration Solutions
Visual Studio

Eclipse

Material-UI

React Testing Library

Jest
My name is Alok Mishra. I have been in the information technology industry for about 3 years. I started working in July 2021. Since then, I have worked with 2 major companies. One was Epicero Global Integrations. Here, I was working with international clients like Panasonic. It was a service-based company. I started my software engineering career with JavaScript-based technologies like React, JavaScript, TypeScript, and other front-end based technologies. I was working with the UI team, developing front-end features. We were also building different kinds of dashboards and ending up integrating APIs using Node and Express. When moving on to my second company, I work at which is my current company as well. It's called IG Ecosystem Private Limited. Here, I was working in a SaaS-based product with the same technology stack, which is Next.js, React.js, Node.js, Express.js, which is a full-stack JavaScript technology stack. Here, I was working along with a team of 5 people, and we were developing SaaS-based applications for big institutions like universities and colleges to make sure that their employee and payroll data, marks management, and student data management were all done in a single dashboard. We were also responsible for a different EdTech product where we sold courses for extracurricular activities for children aged 5 to 15. These were the 2 major projects that I've been working on in my current organization. All of these projects were based on the current technology stack, which is Next.js, React.js, and JavaScript-based frameworks and tools.
JavaScript technologies the JavaScript tech JavaScript engine is basically synchronous. It's a single-threaded system. So to counter that single-threadedness, we want to offload some tasks, like letting's say the calling of an API. We want this task since it can take time and can create a non-blocking operation in the event loop. We make sure that some of these tasks are asynchronous in JavaScript. Promises are a good example of asynchronous operations. We write all of our API calls in asynchronous promises so that they don't block our code, offloading them to the asynchronous part of JavaScript. Just like I mentioned for promises and other stuff, which we can offload to sub certain web APIs, which are present in the browser, which the browser also offers us.
In JavaScript, the event loop concept is a core concept where we see our JavaScript engine starts executing our code line by line. And then all of these functions which are declared are put into a callback queue. Each of these events are then taken 1 by 1 from the callback queue and put into the call stack by the event loop. The event loop makes sure the runtime of JavaScript is maintained, and it's properly executing each of the callback functions that we have in our JavaScript, which is a very common practice. We also have an event loop that also has another microtask queue, which has certain priority functions that have a priority over the set callback queue that we have. Like, for example, if there is an asynchronous function and it has done its processing, then we will prioritize it from the microtask queue, and the event loop will shift it into the call stack, and that particular function will be executed immediately, and then it will be called off of the call stack. So the event loop is responsible for putting any kind of callback function, whether it's synchronous or asynchronous, onto the call stack so that the execution flow of the code is maintained.
The benefits of using functional components over class components in React is that the number one benefit is hooks. With the availability of hooks, JavaScript and writing JSX in React has been very easy. For example, hooks like useEffect, useState, make it very easy to manage variables and perform all the rendering functions and make component composition very easy. We can also use powerful hooks like useReducer along with the context API, which also uses a useContext hook to make sure that all of our state management is done efficiently. Making all of these hooks makes the life of the developer very easy, and the life cycle is also preserved. Because behind the scenes, the hooks are already managing the life cycle components of our UI state. So as long as we are managing the hooks in the right manner and following all the rules that hooks provide, we are not disturbing any of the state management process in a typical class-based component, but we are leveraging a lot of developer-friendly user application development by using hooks. Certain hooks also give a lot of features. For example, we can make custom hooks to make sure that any custom feature which is not available in our typical JavaScript modules, we can make them ourselves. For example, I have personally made a hook called useLocalStorage to make sure that whatever cookies are being used in my application are stored using local storage. So, useLocalStorage is typically a hook which can be custom-made if an application requires it.
A Vue.js is a reactive system that can impact the performance of a large application. Basically, we can see a lot of performance issues when it comes to the typical reactivity and over-rendering of components in any front-end library, whether it be Vue.js or React.js. The strategies we can potentially employ to mitigate these kinds of issues include performance optimization. All of these things, like code splitting or dynamic imports, and making sure that all of our code is extremely optimized, so that no render is done unnecessarily. We should also use memoized functions and callbacks so that no unnecessary callbacks are created in the codebase. And, also, we should make sure to follow all the best practices to mitigate any potential re-renders, so that no memory leaks or any kind of situation occurs that causes the application to perform certain performance-intensive tasks.
In case of a CSS variable, we can make, in case of CSS, we might have we might be using certain color or background image or maybe some certain elements of CSS all around the app, making it into a variable, to ensure that all our app have a similar code structure, for CSS, and it becomes very developer-friendly to remember all of these CSS properties instead of managing individual CSS properties. The variables remember the name of the variables that are being created by them. And then on the basis of that, they can make a large-scale React app, remembering each and every operation and state that they have made. Similarly, in different components, we might need different sizes, like large, or different components of different sizes of the same components. That becomes very easy if we use CSS variables. CSS variables also provide methods for doing certain background-making and background-color versions, so that whenever we want to use some lighter, darker, or different versions of the same color in different components, we can easily do that through a simple variable tweaking, and we don't have to write hexadecimal code for each and every color change that we are doing. Through this, CSS variables can make the development process of a large-scale React application very easy. And in terms of maintainability, it makes sure that the user or the developer does not have to think a lot about colors, individual sizes, and individual properties. But, it can also be easily remembered on the basis of the variables that are being declared. And the variable name should be so intuitive that it does not make any confusion in terms of whenever we require to change them to address all the needs for a developer.
This is an update message method, which we can see. The potential pitfall method that I can see here is at the keyword of this particular function. The keyword of this particular function might create certain undefined errors that we can probably mitigate that can affect the component rendering behavior. The ideal way of declaring this is not correct, and we should always call the function using the object that we are creating in that manner so that the this keyword is assigned promptly, and it does not create any potential invoking errors.
Here in the JavaScript code snippet, we are actually fetching the data through the URL, but we are not using any kind of promises or any kind of async call to make sure that the promise is actually being performed or not, we need to use something like await or promise method so that we can actually check that then method is basically attached on a promise. But here, I cannot see any await or promise method that is being applied. This can potentially call unexpected behavior and might API call might not happen. We need to put something like async await here so that the API call is finally done and the then method can be used to fetch the response of the await after awaiting that URL. And then that response can be converted into JSON. And then the JSON can be converted into a data object. Here, the lack of await or the lack of promise might create certain errors, which we need to tackle by addressing them.
The steps that I would take to debug a memory leak in a JavaScript application requires multiple techniques. For example, we can check whether there is a lag in event delegation. If there is, unnecessary event delegation and event bubbling might result in a memory leak. Also, if there are unnecessary event listeners being attached constantly, but they're not being removed after the component is unmounted or the component is not in use, they might cause memory leaks. So that would be my first approach to find out the memory leak in the JavaScript application. The debugging process can be started by using a typical tool like React DevTools or any kind of Chrome extension, which makes sure that we can render each and every component step by step. And we can also put certain console logs to see which events are being fired at what time. After getting an understanding of which events are being fired, but their listeners are not being cleaned up, we can address those issues. We can make sure that we have all the cleanup logic in our useEffect hook, for example. In case we are using React, we should always have a return function to make sure that there is no memory leak created by useEffect. These are some of the steps that I can take to make sure there is no memory leak in a JavaScript application that uses React.
In our checkout form, it might be possible that we need to handle multiple countries with various tax rules. What we can do is make a drop-down menu and let the user select the country they belong to. Once they select the country, we can set the state of that particular country and fetch the rules. As soon as they set the state of this country, the state variable will change. And then we can make an API call in our use effect, and we can keep the dependency as that particular variable, which is being changed on the click of the countries. This particular variable, as soon as it is changed, the use effect call will be made. And then this particular call will fetch all the various tax rules for that particular country, and then we can display them on the last checkout menu that we have in our Vue JS component. And then we can ensure that the user always sees the updated tax rules according to the country they are currently in. So to reiterate, everything, I would say that we can make a drop-down menu. We can ask the user to select the country. Or if we have selected the country based on the time zone, as soon as the country is selected in our app-wide state, we can also trigger a state that makes the respective API call on the similar basis. As soon as that variable changes, we can make the use effect call and bring up the various tax rules of that particular country and show them in that component of the checkout page.
It depends on the particular complex UI layout that we need to design for desktop applications. I think my particular choice of elect will be Electron JS. That's because I am little familiar with it. I have a lesser idea about PySide and PyQT, but seeing the PyQuote, I can see that they might be responsible for more Python-based packages and libraries in their name. In their integration might be easier with Python-based libraries. So if there's a complex UI layout, since JavaScript has always been known for building complex layouts, and we can generate easily the JavaScript-based applications on our desktop using Electron. I would probably go for understanding the code base and the UI layout using the Electron JS framework for a high-performance desktop application. But Python is also known for high-performance applications. So I will have to review on the basis of the layout and whether the state changes and the layout changes are happening frequently or not. If they are not happening that frequently, we can also go with Python. But my personal preference will always be Electron JS.
The benefits of implementing a continuous integration and continuous deployment workflow in a React project is essential. As we know, in today's modern world, we need to do unit testing as well as different kinds of testing. CICD ensures that all test coverage cases are covered. We make sure that all these checks are done in our pipeline. Also, continuous integration and continuous deployment make sure that whenever we ship a feature, we don't have to think too much about deployment because it's already managed through our pipelines. All deployment will be delivered to the server immediately. And as soon as we update our pipeline and it's approved, all the tests are passed, then we can easily ensure that on our staging environment or our production environment, wherever we're launching our React app, we can see the changes instantly. Apart from this, if we don't implement CICD, we probably need to push the code from GitHub and ask our DevOps guy to make a build, then run that build by putting out commands in the machine itself, which can be cumbersome at times. But setting up a simple CICD pipeline can automate this entire process and make sure that our best practices, like attaching test coverage, attaching whether unit tests pass or not, attaching style tests, which show which code is passed or not, are followed easily with this continuous integration and continuous deployment method. It's also a very important method in the agile methodology.