Navin Kumar

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

What is your approach of debugging a React application that is not updating a view correctly when state changes? Well, debugging starts, like I always start debugging from the backend part that firstly I check whether we receive the response from the backend properly. As you mean to say from the API, we get the response. So once I make sure that the response is there and correct, then I 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. So that's the second part. And once it comes to the frontend, then I see the hooks. So 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 use callback or use memo hook so that if we are using that, we see it is the correct implementation and it is handling the value properly. So when I go to the frontends, 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 everything is right, then I put up like whenever required in the frontend, I put up consoles, I check that in the console, we get the proper object, key and value is right. Then 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. So this is the way to debug the React app, which is not updating the state correctly.

Imagine you are tasked with fetching data from REST API endpoint using async-await in React component. Briefly outline how would you implement this feature. Well, if I am implementing a fetch data RESTful API endpoint using async-await in React, so what I will do, I will go into the project, see that it is properly structured. We are having 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 and then I test that endpoint in the 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 on the middleware. We have the right function written and we are pulling the right point from the UI code so that service could be called. And once that is done, I also check into the service that error handling is done properly. So when I call 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 into values like through action to the state of the store. So I put the action and the reducer to the store. So I see that 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. Right keys are there. If needed to put a use callback or use memo to stop the re-rendering, then check that it is the rightly implemented. So once that is done, then I come into the UI and check that the front end logic, if it is conditional basis, 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, we write unit test cases for that or E2S test cases. So once they pass, then we push the code and pass the ticket to the QA and deploy it to tab environment.

What is your strategy for version control in a collaborative project setting using Git? Well, strategy in Git is like what we follow, like if the company is using Git, like everywhere normally people use Git, like right now there's a Bitbucket, some other SVNs are also. If we are using Git, so the proper way is to do it, like there should be a main repository or there should be an environment repository that will be production, dev, alpha, beta, then there is a feature development branches in like different module branches and then in that branches we develop feature by making another branch, so say for example if we are working on login module then we are working at project underscore the login module branch, if we are working on dashboard module then project underscore the dashboard branch and from that also if we are working into a Jira ticket which is on login module then we say the branch will be login module underscore the Jira ticket and the feature slash feature is like integrating login API, then this is the strategy or this is the namespace rules which normally set by the company which give us the job and we follow that, so everybody just finish their Jira ticket according to the sprint, once it is done they push it, then we create a pull request on the Git and then we pass the message to the team leader to review that pull request, one day he reviews the pull request, he merged the pull request to the module branch, then once all the Jira tickets are finished for the day in the end then the team lead or the main technical lead merge all the Jira ticket into the module main branch, so after the end of the sprint then the our technical lead comes and merge that module into the alpha branch or beta branch or the dev branch according to this and then this is the collaborative project setting we are using in Git.

Well, how we approach error handling in React is like you have to go step by step like from base to like end. So firstly, while communicating with an API endpoint, the first step you check that 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 that we have to set up a timeout that whether if the server is not responding. Then after this much time, the API will send us some response. Then after that is done, then we check that the when we send requests to the server, then when we get the response back. So all the response codes like 2 0 2 0 1 2 0 0 2 0 1 4 0 1, all the codes has been properly handled while writing the error handling code. And once we are comfortable by handling all the states which is there from the server response like 2 0 1, 2 0 1, 4 0 1, 4 0 4, any of that, once that error handling is done and then we come to the 2 0 1 success request. So in that, what we do like we check that the logic we are implementing, say, for example, if we are going to log in into the system, then we check that the once we pass the credential, we are getting 200 response, but the credentials are not right. So according to the internal API status code, we write the error handling code that yes, this is the problem that 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 decision has been taken. So according to that error handling, we just return the response and it goes to the action or the reducer or the store or straight to the UI front end. So that is how we do the error handling with API.

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, this is not the right way of doing it.

What procedure would you follow to refactor a large Reset Redux store to improve its maintainability? Well, what procedure I can follow? Well, refactoring a large Redux store to improve its maintainability. When you think that the application is going to be big, so that planning has to be done in the start. 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. So for that, what we do is keep a provision to add another store into the React app. Or we use a different, not Redux, we use a different juice stand we use. Or we can use some, instead of Redux, some other NPM to implement, which are compatible with the React. Because, say for example, if we are not in favor of juice stand, we see that it's going to be big. And if server support, we implement the juice stand. Even if juice stand takes a little bit more memory than Redux, but the maintainability and readability is more in juice stand. Why? Because the juice stand creates a store for every module. So if we have a store for a single, single module, the readability increases. Every store, and it 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 to the account store, what is happening on to the billing store. You need not to worry. You just have a dashboard store and that improves the maintainability. So with also like, if only Redux store is there, then just declare the interfaces and declare the initials into separate, separate models. And once you have that models and everything, then you keep the actions and reducer separate, 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 reducer, which are like login reducer. So this is how like one like maintainability and readability could be there. And also like to store option at the start is another answer.

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.