Navin Kumar

Hi, could you help me to understand more? Yeah, so I am a full-stack developer and I have been in the IT industry for the last 12 to 15 years. After finishing my master's from the United Kingdom, I started my development career. Firstly, I did development in Visual Basic, Oracle, and Unix, creating a few applications in the accounting domain. Then in 2009, I shifted to India and started development in web technologies. In the beginning, we were developing using JSP, ASP, Active Server Pages, and Java Server Pages, and we were doing the backend stuff like integrating databases, designing databases, and querying, writing all that code. Then with the evolution, the industry shifted towards React, Angular, or JavaScript technologies because Google pushed Angular and Facebook pushed React. They were very popular, and we started working on React and Angular, and the JavaScript framework. In React, I think I did about 70 projects, and a few of them were big hits. And then, over time, hybrid codebases started to emerge, and we started developing in React Native, Ionic, and Flutter. This allows you to develop one codebase and deploy it on multiple platforms. My last job was in Malaysia, which was an on-site job, and I did that job for one year. It was in the financial domain, security, managing security for the app, writing secure code, following procedures, deployment procedures, using secure software, secure modules, and secure financial wrappers for the apps. That was a main feature of the job. Before that job, I was in a company where we developed a React app and a React Native app for a client called Home Chef app, and it's very popular now, with more than 500k downloads. Before that, I worked on a React project called BigTWeb.com, which was for a number one supplier of racecourse horses, accessories, supplements, and medicines to the racecourses in the United States. That was a big project, with 200 people working on a single project, and we were working on agile methodologies, sprint-based development, QA, and 3-4 levels of QA, including customer QA. Throughout my career, I have done about 70 to 80 projects in React Native, and Angular. Mostly, I work in React because it was the industry demand. So that's my brief background.

When debugging a React application that is not updating a view correctly when state changes, my approach starts from the backend part where I check whether we receive the response from the backend properly. Once I make sure that the response is there and correct, I then check that the error handling is right and the response is going to store or if it is required not to put into the store, it is returning the proper value, proper key and the proper structure according to the model so that it could be stored into the state or store. Once it comes to the frontend, I then see the hooks. In the hooks, we get the proper state, the keys are correct or the state name is correct, which we are getting into the state. We are pulling the state from the store. So once I make sure this, then I go into if there is any use of the use callback or use memo hook so that if we are using that, I see it is the correct implementation and it is handling the value properly. When everything is right, then I go to the frontend, in frontend, I check the logic. If the rendering is on the conditional basis, I check that whether the conditions of the React app is meeting the value so that I can see that the value is coming to the frontend. When I check the logic, I also check that the keys and values which are coming is according to the logic, according to the calculations and what output we are expecting, that output we are getting it. Then I also check that in the console, we get the proper object, key and value is right. So this is the way to debug the React app, which is not updating the state correctly.

I will go into the project, see that it is properly structured. We have the right base URL coming to the service. So I go to the service and write my function and then I check that I am pulling the right endpoint from the constants. So once I see the endpoint is right, then I test that endpoint in Postman with the proper token and the required body. So once I see that this is what I need and this is the correct response, then I come to the service and write the proper code after checking that with the model and the structure is right, which is coming to the service, which is sending data to the service. So I check that interface is right. Once that is done, I move back to the middleware. So I check that the middleware has the right function written and we are pulling the right point from the UI code so that service can be called. And once that is done, I also check into the service that error handling is done properly. So when I call the API from the front end, I get the proper answer that the API, whatever the state of the API, according to the error handler, I get the proper response and proper code. So once I come to the front end or also in the middleware, I also check that whether I need to store the values into the store. Then I put the values into the store like through an action to the state of the store. So I put the action and the reducer to the store. So I see that the reducer is written correctly and the proper state is getting updated. So once that is done, I come to the front end and check that we are pulling the state from the store correctly. The right keys are there. If needed, I put a use callback or use memo to stop the re-rendering, then I check that it is implemented correctly. So once that is done, then I come into the UI and check that the front end logic, if it is conditional, it is written correctly. And my all the values are passing those conditions. Once that is done, then I render that data on the front end. And then I go and test it on the UAT steps. And once these tests are passed, I can write like, not always, but whenever the project demands, unit test cases or E2S test cases. So once they pass, then I push the code and pass the ticket to the QA and deploy it to the tab environment.

What is your strategy for version control in a collaborative project setting using Git? Well, strategy in Git is similar to what we follow. If the company is using Git, the proper way is to have a main repository with different environments like production, dev, alpha, beta. Then, there are feature development branches in different module branches. In those branches, we develop features by making another branch. For example, if we're working on the login module, we're working on the project underscore login module branch. If we're working on the dashboard module, we're working on the project underscore dashboard branch. If we're working on a Jira ticket for the login module, the branch will be login module underscore Jira ticket. The feature slash feature is like integrating the login API. This is the strategy or namespace rules set by the company, which we follow. So, everybody finishes their Jira ticket according to the sprint. Once it's done, they push it, then create a pull request on Git. We pass the message to the team leader to review the pull request. The team leader reviews the pull request, merges it to the module branch, and then merges all the Jira tickets into the module main branch. After the end of the sprint, the technical lead merges the module into the alpha branch or beta branch or the dev branch according to this. This is the collaborative project setting we're using in Git.

Well, how we approach error handling in React is like you have to go step by step, from base to end. So first, while communicating with an API endpoint, the first step is to check whether your internet is working or not. If the internet is working and you are not getting any error over there, then you move on to the next point, which is to set up a timeout to check whether the server is not responding. Then, after this much time, the API will send us some response. Then, after that is done, you check that when you send requests to the server, you get the response back. So, all the response codes, such as 202, 201, 200, 204, 401, all the codes have been properly handled while writing the error handling code. And once you are comfortable handling all the states which are there from the server response, such as 201, 202, 401, 404, any of that, once that error handling is done, then you come to the 201 success request. In that case, you check that the logic you are implementing, say, for example, if you are going to log in into the system, then you check that once you pass the credentials, you are getting a 200 response, but the credentials are not right. So, according to the internal API status code, you write the error handling code that yes, this is the problem - whether the credentials are not correct, whether the user is not allowed, whether the subscription has expired, whether the user is not paid for the service. So, those decisions have been taken. So, according to that error handling, you just return the response and it goes to the action or the reducer or the store or straight to the UI frontend. So, that is how we do the error handling with APIs.

How would you implement a feature toggling system in React for controlled rollout in new feature? Implement a feature toggling system in React. Well, whenever we develop a new feature, so firstly, as I told earlier, we follow the Git and we follow the naming convention of the sprint and JIRA tickets. Once those is done, when the sprint is done, then we come to the main module, so that is done. So when all the development is done, then we follow the QA process, how many bug tickets are there? Then we create the branches and everything on the basis of the bugs and we finish it. Once the module becomes stable or the feature becomes stable, then we do the dev testing at the alpha stage. Once that is done, then we follow the deployment processor to the beta or the dev stage. So that is where the client is come. So toggling system in the React control rollout will be like, we have environment set, like this is the dev environment, this is the alpha environment, this is the beta or this is the production environment. So we just set whenever we deploy, we just set that the React code should follow this environment and then those environment variable get up in the React and we follow the production. Then we like say the environment is production, then it follow all the end points and everything from the production. So this is how like once the feature, if we say that we have the two like straight branches set up so while deploying also we just like deploy the newly built branch on the main server. So once we see that on the main server, everything is right and fine. So if we find that on main server after putting the code live, we have some issue, we straight away just stash the changes and roll back to the previous branch and the old code is there. So then we try to fix it back on the beta or alpha stage, then we again follow the deployment procedure. So this is how the toggling of the controlled rollout of new feature handled on any React app. Bye.

Given this Redux action creator, identify what might be wrong in terms of synchronous action, dispatching the response and approach to handle asynchronous scenario. So this function is fetching the data and returning dispatch, calling an API data and the response is converting to the JSON. Then the response is dispatching to action fetch success with the payload data and catching the error on the fetch error in the action with the payload error. So given this, the Redux action creator, identify what might be wrong in terms of synchronous action, dispatching the purpose of approach handled asynchronously. Oh, wait, and async is not there. I think that's the issue. Yeah, I think that's the issue. We should then return. Yeah, async and await is not there, asynchronous scenario. This is not asynchronous scenario. This is normal API calls when we were using the jQuery and then that thing is there. There is no asynchronous here.

Examining the following React code snippet for a functional component, can you spot the issue with how the state is being updated and suggest a solution without modifying the function's signature? So examining the React code snippet, a functional component, can you spot the issue with how the state is being updated and suggest a solution without modifying the function's signature? Yes, straightaway this increment function is straightaway written that setCounter, counter plus one, setCounter, counter one, but what we can do that we can take one setCounter function and then once the state is updated then we can use the callback function in the single setCounter function and we take the previous state and we add one value to the previous state and then just finish it, so this is how that counter will become from zero to one and zero to two, because if you do like this is not the right way of doing it.

What procedure would you follow to refactor a large Redux store to improve its maintainability? Well, the procedure I would follow is to plan ahead when the application is expected to be big. So, in the start, we should have a provision that every year when we start, we put a provision there that if the scale of the application becomes high, then how we will handle that. For that, what we do is keep a provision to add another store into the React app. Or we use a different state management system, not Redux, we use a different one. Or we can use some other NPM package to implement, which are compatible with the React. Because, say for example, if we are not in favor of Redux, we see that it's going to be big. And if server-side rendering is required, we implement a different state management system. Even if it takes a little bit more memory than Redux, but the maintainability and readability is more in a different state management system. Why? Because it creates a store for every module. So if we have a store for a single module, the readability increases. Every store provides the compatibility that one store, one module store can be called into another. So maintainability also is there because you can, you do not have to be worrying about the whole store and how many states are there, how many init states are there. You have to just worry about the dashboard store. If the dashboard store needs something from login store, you just call that login store, take that value and you are done. You need not to worry about what is happening on the account store, what is happening on the billing store. You need not to worry. You just have a dashboard store and that improves the maintainability. So, if only Redux store is there, then just declare the interfaces and declare the initial states into separate models. And once you have those models and everything, then you keep the actions and reducer separate. And whenever you are updating something in the store or you're trying to get the store, you just keep, just pull only that action, say for example, you are concerning about the actions in the module. So you just call the login actions and you want to update the state through the login reducer. So this is how like maintainability and readability could be there. And also, using a different state management system at the start is another option.

Outline how you would configure Webpack for a React application to optimize bundle size and improve load time. Yes. To optimize the bundle size and improve the loading time, number one, all the deprecated module, all the unused module has to be taken off. We have to check it. We try to use the most current version of every npm package wherever we can, and it is compatible with the others. So that's the second point. We try to concise the code, not too many raw code is there, not too much commented code should be there. That will reduce the bundle size, and also if there are images, then images should be vector. If there are videos, they should be on that resolution, not that two big files. If we can, we can put all the images, videos, somewhere on the S3, and we use that into the app through the S3 URLs. That would drastically reduce the bundle size, and it will drastically improve the load time. So these are the configuring the Webpacks. You have to check that every Webpack is compatible with another, not a lot of warnings, or there are some errors, sometimes the developer leave to ignore it because the code runs even if the error is coming. Those things should not be there. Yeah, but that is also one point that bundle could not be made if any error is there. That is also one point, but sometimes developer ignore very severe warnings. So that should have been taken care of. These are how you can outline and optimize the bundle size in a React app.

How would you use Zest to mock the API call React application test suite for robust integration? Zest is a unit test framework. So when you write the Zest code, there are certain ways. You just declare the dummy JSON data and dummy data in the JSON file into the Zest. So once you write the unit test, in that unit test you just use that function as a call and it returns that data. So this is how when you write unit test cases for robust integration, this is the normal practice you do writing the unit test in Zest. Sorry, Zest is not a unit test. It is the Jasmine I just talked about. So Zest is a something, how would you use Zest to mock API call in React application to test suite for robust integration? So Zest is basically a module in the React app test suite for robust integration testing. This answer is, what I normally do when I mock the API call, I just create a dummy JSON file, create a mock API and mock endpoint. And then we just call that and we connect one function which is returning some part of that JSON file. And it has the data according to our logic, that JSON file. And once we hit that, we take the data, do our calculations, pass it to the store, put it up into the front end and do our logic part. So that's the best answer I can give.