Kaushik Parmar

Hello. My name is Koushi, and I'm from Ahmedabad, Gujarat in India. I have a total of 8 years of experience in front-end development. For the past 3 years, I have worked for a product-based company on Angular and Node.js. Then I moved to a service-based company where I worked with DLTS and related libraries, as well as the Node.js framework. In total, 8 years of experience, I have 3 years as a technical lead. In this role, I led a team of 7 developers, including front-end and back-end developers. My responsibilities included developing modules and features, defining project technologies, and designing project architecture. I also guided team members on how to achieve features and complete tasks on time. We worked in a distributed team remotely, and since the COVID pandemic, we have continued to work remotely as developers. That's my introduction.

In real cases, if we want to implement a form without using any library, people definitely use libraries that provide in-built features. But in my scenario, when I'm implementing any form, I think first if the library is required or not. If we have only 2 fields or 3 fields or maximum 5 fields, why don't we require an external library? It increases the burden on the bundles when the final production build is happening on React or Angular. So, it saves to increase the performance. Let's say, we don't prefer libraries all the time. That is my approach for implementing the form. And if you want to implement the form efficiently, we can use in-built methods. We can use onSubmit and determine whether it's a post or get method. And in the input elements, we can utilize methods like onChange detection whenever people are typing. And when the status is changing of the input, we can define our function for validating that input. Or we can use regex for specific types of text validation if you want. For example, phone number format. If you want to implement it, we can utilize a regex pattern for implementing that format. That is the approach from my end. How to implement the form efficiently directly, and if you want to bind it with this state, then definitely we need to bind the onChange method with some predefined function, sorry. onChange is a predefined method, and we have to bind it with our custom function. So we have to use the useCallback method to catch the function definition, to memorize the function definition using the useCallback method. We can pass their dependency in the area, and it will memorize that values. So it will increase the performance. And in another way, all the input on change will be run with those methods, and we will use all those methods. And if we have a state bound with the input value, then the state also should be managed to minimize the rerendering of the component using useMemo, or we have to wrap our entire component with the memo, and it will increase the performance of that component for specifically a form component. So there are lots of ways using step management as well. We can do a lot of things. This is only for real how to implement a form efficiently.

For unit testing in a stateful component, we can use a real testing library where some inbuilt functions are provided for testing the components. We can even test the separate function of the component. And in a list, we can write our test case, and we can access that function by importing the component. And we can provide our input for that purpose. All the functions we are providing or which we are defining in the component should be independent or loosely coupled, not tightly coupled, with the dependency. So we can provide external dependencies, or we can mimic the input for that function for testing purposes. And if we are defining the component for testing purposes, then we have to take care that the component is also loosely coupled. Props are a means if we are defining props for that component, then they should not be dependent on each other. We have to manage it so that we can test it in a unit testing, and it should handle single responsibility. Otherwise, it will be hectic to write these cases. In that case, if it is taking lots of props and multiple dependencies, then we have to find a complex way to test it. So we have to define a proper way for testing purposes.

But in React, if you want to build a reusable library of components, then definitely, let's say we have a component folder and where we are building the shared component or component that will be used throughout the application and reused throughout the application. And those components will be inside a shared components folder. And we will manage and develop the component. Like, it will take as many props as possible. And based on the props, it will change its behavior instead of just implementing the static features and static behaviors, based on the props. So it should behave based on the props, not directly, just handling everything internally. So that is the main thing, how to implement the component, and we should take care of the performance as well for that component. That will be the first scenario, and it should be reusable and testable. So we should take care of some principles, like SOLID principles and the DRY principle for not repeating code and reducing code redundancy. And some other design principles, where keys and Yagni are also brought up, and we need to take care of those. So if any feature is not required, we should not implement it. It should be implemented only when it is required in the product. So that is the design principle we need to take care of. And the structures should be outside, in the main directory in SRC in the project, not in a nested format, but on the highest level of the directory. All shared components will be implemented there. Components will be added there. One more thing is to export those components. So every time we have to import one component, we can include an index.ts file in that folder, and we can import all the components and export them as a module, and where all we are importing as a library. So we can import it with a single path instead of importing every file, every component file, one by one. Otherwise, in that file, it will show a bunch of imports for thousands of components. So it's better to export it with this index file and just import it in curly braces.

So in traditional approach, we were implementing each and every CSS for the components of React or building the HTML UI. So in this, Tailwind follows utility-first approach, which means it provides inbuilt utility functions. The utility-first approach is pre-defined. You utilize the pre-defined classes and minimize the redevelopment of CSS. So, while using such libraries like Tailwind CSS or Bootstrap, we have pretty pre-built classes, CSS classes, which we can utilize. And we do not need to build from scratch. We do not need to write our CSS from scratch. Almost everything, like 90% of CSS, has been covered in that. And those libraries, like Tailwind CSS, are very minimized, recompiled, and minified, which takes less time for loading while loading the app in the browser and using the request. So, this is the utility-first approach. You can use the utility-first approach for using Tailwind CSS. So, we have the 10-minute CSS first. It will be first for using the inbuilt classes for defining our UI pages using HTML and CSS.

So, in my project, I have used style component and Tailwind CSS as well. Let's talk about Tailwind CSS. If I'm writing any CSS in Tailwind, I use a pretty different class. We can use mixing, where we can create our class, which will be used later for extending the existing class as well. Whenever we're following Tailwind CSS, they have already predefined classes for everything, for height, width, and some card-related or dropdown-related CSS. They have already built it. This provides better reusability and scalability. We can use the in-built classes for extending as per our requirement. We can build a custom theme as well, predefined global themes for customizing the predefined classes. And those custom classes will be used throughout the app. We can define it through a common CSS file built on the top of the src folder. That's the way to implement reusable CSS with Tailwind.

So, in solid principle, this is the open, close principle, which means the class would be open for extension and closed for modification. So in this goal, I can see that it is in two classes, rectangle and area calculator. So in rectangle, let's say we have two properties, width and height. And in area calculator, we have a calculate method for rectangle, which is modifying it. Okay? So in the area calculator class, which is modifying it, so we should restrict this part. Like, it is a rectangle. The area calculator is modifying rectangle plus, and the principle says that the close principle it says modification should not happen with the existing class. We can extend it. So we have to implement an abstract class, and that abstract class will implement that method in another while extending in the another class. So we have to define the structure of rectangle in a way that it is an abstract class, and that abstract class will have a method like calculate, height by something. And that abstract method will be implemented for the extension purpose in the area calculator. So that is the way we can implement this open close principle.

So, in this call, I can see that the API is being called, and the API is handling the response. The failure case is not being handled. So we have to manage it and take care of both success and failure. We can add a catch method after then. So anytime if it fails, the catch method will trigger some error. It will show in Toast that something went wrong, and we can handle the error in that way. Or we can implement the error at the interceptor level. Let's say we are using the Axios library for HTTP requests, and XEO has a request and response interceptor feature available. We can implement it for intercepting the responses. When the response comes from the server, we can check whether it's a success or a failure, or we can check the status code to see if it's a failure because of authorization or a token has expired. In that case, we will show a specific error, such as "you don't have authorization for this thing" and our token has expired. And we need to redirect the user to the login page. So they will log in again and come back to the page. Another status code can also be implemented in the interceptor for response purposes. So every time we don't need to implement a catch method for handling responses unless there is a specific case. For all common cases, it should be handled in the HTTP interceptor. That is the best way. And we can even handle the request as well. So when our request goes from the application, we can modify that request. For example, adding the bearer token in every request that goes after login.

So in my application still now, I have worked with enterprise-scale applications still now and small applications as well. But in any case where there is a large application, we can utilize existing state management libraries, which are proven for managing states. Like, the toolkit is available for managing the state. MobX is also an option. And in recent scenarios, we can see recoil and some other libraries are also available. We have to select based on our requirement. So most of the projects utilize Redux and the Redux toolkit for recent enterprise grid applications, and MobX is also a second preference because they handle state management internally, like handling mutations. So in fact, when we are operating on any existing state, it should be operated on a draft, not on the existing direct state. And we should operate on a draft, and the draft will be updated on the main state. We can even utilize Emer JS or immutable JS for that purpose for handling mutations. In the background, it is not affecting the performance. That is the case. And I have good knowledge on both Redux Toolkit and MobX. In one project, I have used Redux, which was a large project for ops and steering with a Fintech company. Redux was also a successful state management tool at that time. There are a lot of features and less learning code in Redux or Redux Saga, but there is a lot of learning code for any developer to understand all the features, all the scenarios, how it works, and the data flow as well. As simple the flow is, the developers can understand easily, and a simple bug cannot take more time for fixing it. Otherwise, I have seen that in Redux, when any bug comes, developers take more and more time for fixing it because of the debugging capability. They are providing their inbuilt tools. Still, it takes a lot of time for debugging the application. So my approach always goes for a simple tool that uses state management well, provides better statement management, and provides a debugging tool when we are getting any bug, whether it is in production or in development. But it should be open for debugging purposes, and we have to configure our application in that way that any kind of bug is coming. We have to fix it, and this way should be predefined for debugging. So I would prefer that kind of state management tool.

In my projects, I have worked until now. All the projects we have used Node.js and React.js or Angular.js. Okay? I have not worked with any other project having Python in the background, in the backend, so I cannot answer. But a few things I can mention is whether it is Node.js or Python, they are the ones we can implement a server-side technology using any framework or any programming language, and the method will remain the same by the predefined endpoints with Python or Node.js, and those endpoints will be utilized by the application for following the API purpose. And the server handles that big case in that way and gives us the response on the front-end side to bind and integrate the data in our React application. So that is the way we can utilize the API, and we can integrate the API, whether it is Python or whether it is Node.js or.NET.

So in a risk pool API, when we are building, we have to take care of some features like encryption. We have to implement encryption. In our frontend side, we can send the HTTP request through a compression method like gzip, and it will encrypt the request. And in the entry platform, we will receive it in the compressed form as well. So we have to use a compressed middleware there, Express Less Comparison Middleware. And we can use that part in building the API for securing the endpoints and data. We can implement access control, cross-site scripting protection with this for Zarif. We can mention which URL will be whitelisted, and only whitelisted URLs will be able to follow our application. So we can secure our risk pool APIs in that way. And another is implementing using the Helmet. We can do that to provide a lot of features for implementing the security of our APIs, whether it is in Node.js or React application. Okay? So that is the one thing we can configure our server for rate limiting purposes. The number of calls happening on the server. So if it reaches the limit, like for example, we have implemented rate limiting, like 1,000,000 API calls. So it will handle those requests only. If it reaches the limit, then the server will stop handling those requests because of the daily meeting. So if anyone is attacking with multiple requests, we can save our server from going down. And one more thing we can secure our React application is we can deploy a login page on a specific server, not the entire application. And once the login is successful with the API, then we can navigate to the original application. That is the one way I have done in my application. So we can secure the frontend application in that way because humans cannot read that code directly, but it is machine-understandable. So that is the reason we have to secure our application code so that machines cannot understand it. On the other hand, we can authorize people after logging in. So that is the security principles we can implement on React and the methods for securing risk pool APIs as well.