Ajay Yadav

Yeah. So I'm having a background as a front-end developer and having 3.7 plus years of experience in front-end development, mainly working with React JS and also having worked on Next JS. I have worked on CSS libraries, and frameworks like Bootstrap, Tailwind CSS, and Material. I have worked in different architectures, creating scalable applications and organizing my code so that business logic and main CSS styling files and the HTML part are in separate files. This will be in the same folder but in different files, making it look very clean and organized. I have worked on many projects. My first project was for a Canada-based client, and I was responsible for building it from scratch and delivering it to the client completely. It is also live and has been for over 10 years. I have worked with the US Bank team, where I started their first project and helped my colleague set up the architecture of the US big storage module. I have also worked with the Texas-based startup called ESG World. ESG World was launching their first product, and I took ownership of the project in the middle of it. As soon as the project resumed, I took complete ownership and worked with the client for 1 to 5 years, managing a team of 4 members. I was directly engaging with the client, gathering requirements, and discussing all the requirements with the client. I also gave him deadlines every Monday and provided demos as soon as we completed sprints. We were also managing the product, and I was responsible for creating tickets and moving all the tasks to the Kanban board on the agile methodology. After successfully onboarding the top 5 oil and gas industry veterans of Texas on their project, I started working with the Amnic team. It's a startup by the ex-cofounder, and we built the architecture and attribute design pattern and the Tailwind CSS. We implemented Storybook and Cypress for testing as well. Then, in January, I joined another company called Acodas, and I was given the responsibility for their new prototype project, which is a Phoenix-based project. My responsibility was to successfully deliver the phase 1 of that project, and I have successfully delivered it on time. All my projects are on GitHub.

We go to debug complex issues efficiently in a React Redux app. To debug complex issues efficiently in a React Redux app, we first get to know the issue from the top layer deck. Okay. What's going to happen is that on the file, the issues are getting missed. And then we start debugging that. If it's about the breaking of the page, then we'll cancel out the states and check what state is not getting there. And nowadays, we'll be writing up the test cases. As we know that we already have the dependencies of JEST 2 testing libraries, and we start writing up the test cases. We also sometimes take the approach of TDD, test-driven development, and we initially start writing up the test cases for the file. And from there, we get to know that if any of the test fails on changing any file, then we'll know where the issue is going to happen, because it fails there, and we can easily track it. And other than that, we use console logs on the page, where it is, and we figure out the issue on which component all. Basically, we track down the exact tab where the issue is going to happen.

In large scenarios, I would choose data through context for state management in React, especially with performance in mind. In Linux and other environments, Redux and context API are both used in different settings when our project is very large scale and needs to be handled. There are a lot of big models, and those models are complex. Then, in the Rajesh Kapoor project, Redux is a king, we can say. If we are managing states, using the data only on a module basis, like 2-3 modules, then we can use the context API differently. If this context is being used by the complete application, it will be used in the index or app file. But if we have 2-3 modules, we can also implement the context API only for those modules, so that the other modules will not be affected by the dead context. However, when it comes to the context API, data comes to that other index, context API, like deduct, is a much better way to use it because it will not make a project extra complicated. But when we implement the context API, we have to optimize after that. We have to optimize a lot of our components because it will make the component re-render 2-3 times unnecessarily. So if we are implementing the context API, then we have to write additional code to memoize some functions.

How do you decide between the style CSS modules or style component in React app? Okay. In-line styles, CSS modules. Inline styles are having their priority most whenever we are using them. And, like, if you can say that, if you are writing classes in class names and styles in class names, so those are all the inline styles that we are giving them. But when we are separating our code, the HTML part, the business logic, and the CSS part, then it is always better to modularize the CSS. So we can separate the CSS modules of every component, and it will make our code better maintainable and scalable and easily readable. And style component is when we want our components to be having elements, and those are those are ought to be controlled by us. So there, we will be implementing a style component for our React applications. And basically, CSS modules is a winner because I think that will give us the much better scalability of our project. And CSS in-line styles are getting the attribute class name and giving it to them so we don't have to look out for many different files to look or write our CSS files.

JavaScript scope is like this to command the JavaScript scope when integrating with the REST API. Like, so we have to look out for the scope of the state that we are going to use. As you know, if you are writing this application in and integrating the REST API, if you are using Redux, then it is because it has one store, and it will be wrapping up the whole of the project. And so it will be globally available to whichever component wants that state. But when it comes to calling of the REST API and creating the REST API in the same component, we will be using the internal state. So, if you are not passing it to the state, which is having the result of the REST API, if we are not passing that to the child component, then we are using it in the parent, then that state, the JavaScript scope of those data will be restricted to that parent only.

I didn't see that the user interface remained consistent across different parts of the React application. If you want our user interface to remain consistent over different parts of the application, then we will be at the time of declaring the routes. So, we will be having a blank route lapping on our own complete route. So, we will be providing it with the structure, okay, that if we want a left sidebar, the middle part of the screen, or even the right sidebar. So, we will be implementing that structure on a main route level, route wrapper, and there, we will be implementing the children or left children or right children as an outlet. So, if the left children, the middle outlet. So, it will be only whenever the route inside the route, like, routes slash dashboard is having that element dashboard. So, that will be comes directly into the space, whichever the outlet being provided to. Like, we are having a left sidebar, and in the middle, we are passing that outlet as a child. So, whenever the dashboard or the about us page, whatever page will be come, so these all will be shown in that particular area only. So, we can maintain our interface the same throughout our data.

Okay. Then the Linux connected. Z component's embed identifying explain the mistake while trying to dispatch data is connected. Identify and explain the mistake when trying to dispatch an action to data storage. So it will, we have our directly linked this dotbox. Dispatch, but we haven't any of this function because it's a class. So the constructor and super props need to be here. So as we have written the this step prop dispatch method in here, we've been taking a type and payload of the action. But we don't have any props. The props is not accessible to this user profile component, because we have not even initialized it with the construction function. Because the construction function and the parameter it has as a props, then only we can be accessible those props in the this component. It has to have this constructor method in this. So that is being missing now from this code. So just to because it then it will not call this dot or drop the dispatch, and that will not going to update. If it's not dispatched, so the data will also not be updated in the store as well.

Let's remind the React work you say function component. This is a bug that prevents the component from functioning correctly. So underneath you have to come. You see. And then that component from functioning correctly. Can you identify the bug and if function correctly? Okay. Alright. It is a studio user state, and we have defined with 0. Use a useEffect. Const interval equals okay. SetInterval. Alright. Set seconds to second plus 1. On returning, it will clear out the clearInterval function. So it's having the second state and setSecond method completely. It's a set interval on every second. It is going to update the seconds. So firstly, it is not a custom hook. So if you are confused that if it is returning the seconds return the second seconds, so for that, it's first have to be the custom hook. And for that custom hook, the name of the function should be start with the use. So it should be like useTimerComponent. This should have to go to maintain, to get the fastest seconds out from this. We have to use this custom hook with the name useTimerComponent.

When the face condition, they need to skin. How would you reflect it? Okay. React architecture. Okay. If we have to restructure architecture as well. Okay. Refactor it. So if we have to scale our application on a larger scale, so we first are going to use Redux, and we will be implementing the Redux files based on the components. We will create the action files according to the component and the reducer files according to the similar component name so that whenever we are in our Redux, we will have to maintain the Redux folder, and we will be maintaining the inside the Redux store folder or Redux folder, we will be having this one folder for the actions, one folder for the reducers, and another file for the store, which will be have integrating all the reducers. And so to easily maintain those actions and reducers separately so that whatever the size of that Redux project gets increased. We'll be having a lot of files for this actions. We will be having separate files for every component actions so that in future we will easily be able to add another file so that it will not get hampered or it will not have any effect on another file as well. And same as the reducer, we will be creating separate files for the reducer as well. So and we will be having like we will get the naming convention reporting on the files from the start on from the starting only that gets x z component and get the naming should be like x like that only. Or we can have the architecture in a way that like the big z 8 is having this like we believe we break the component architecture also in that way only the pages and that module folder. Then in module folder, those sub pages that will also have their own folders. And inside the folder, in every folder, every component or like every component, we will be having the name with the component, and then it will have the it is your CSS file, separate CSS file, the main business logic file, TS file, and the HTML part, TSX file. And we will be having if we are having this Redux, so we'll be having the action and reducer file also on the same component folder only. So whenever we will grow the scale or we will be reducing or removing any of the module. So it will be very easy for us to just comment it out or just scale it up by this architecture.

To utilize a multi-language reactive teaching effectively, to localize some multilevel language applications, we will be implementing some libraries that will handle the multilanguage file. And we will also maintain all the sentences and constant values in a separate file. So, for example, we would have a constant folder, and it will have separate constants for routes, so that it will be easy to maintain and change later in the project. And same as if we are having some tagline in the dashboard, we will put it into the same constant file only, so that whenever it is being used in three to four places, we will just go there and update our language. And when we will be using those multi-language libraries, it will also be very handy for us to easily manage them.

To deploy it. Profile. That will put the performance of React to improve. To improve the performance of the React application, we will be implementing the dynamic loading and lazy loading concept, which we have so that the bundling bundle of the date application as soon as you are browsing any of the page. So it will only download that small chunks and small bundles only, whatever is required, not necessarily load those other pages. So we will be implementing lazy loading and suspense to control the fallback of the UI. Like, basically, the lazily loading, so it will be must to have this dynamic import. And on the route level only because as soon as this route strikes, it will first check on the route level on load where the route is being of when the in the SPS. So we have implemented the create with the rendered with the route, documented, the route. So it's a single-page application. And then from the app.tsx, it will render the app.tsx, and there we do have a wrapping up the whole application inside the route. So this will check the routes first. So first, we will be breaking up the route in the modular fashion. So if like at widget that we are having over this xvj.com, allowed dashboards at widget slash about us. So it will be if the dashboard does not change, so we will make up our routes in our module efficient. So if the dashboard does not change, so it will first remove half of the routes of the dashboard. So we will have all the complexity with the logins. And when it will reach like x y zed and it there is having like only 5, 6 routes. So x y zed and all those 5, 6 routes will also be noted because we have dynamically imported our component and have implemented the lazy loading and suspense to give us the fallback UI. So it will be very easy. We can easily maintain and improve the performance of our React application. And on the task component level also, we will be implementing this. We can also implement this lazy loading so that only that portion of that component will render whichever is in the focus. And we believe we will employ like implement techniques like use memo, use callback, and some other functionalities, optimized code so that it will have the good performance of our data application.