Sejal Pande

Hello. Yes. My name is Sejal Panil. I currently work as a lead front-end engineer at Apex Global. I have a professional experience of 8 years working in software grid development, predominantly in front-end development. I have had experience working in the healthcare and Fintech domains. Currently, I'm working on a Fintech product that revolves around payment orchestration ecosystems. I have experience implementing Fintech solutions into payment and orchestration, like smart checkouts, cascading, intelligent routing engines, revenue products, and so on. All these products have been implemented using technologies such as text tags based in JavaScript, React JS, storybooks, bootstrap, and Java on the back end. I have more work on the front-end side, but I have also had chances to interact with my design team, back-end team, and testing team to cover the activities that revolve around them. I also participated in the API design phase to ensure the implementation of APIs in a format compatible with the data needed on the front end. And, I am aware of Agile and Scrum methodologies. I am a certified Scrum Master, and I also conduct Scrum-related activities in my team. I act as a Scrum Master for my current development team. Additionally, I am aware of CICD and test-driven development. I have experience collaborating with product owners and stakeholders and reporting to the CTO and higher management regarding the development and evolution of the product. That is my overall experience. Thank you.

So while doing the high-level system design for a React application, the very first thing that needs to be considered is how the UI component library has to be implemented because React is a UI component library, which is mostly used to develop UI-related elements. So identifying the UI models of the project and implementing a well-written dynamic set of components is a very important thing that makes our code plug and play, and the development time is significantly reduced if we have a well-written UI code library. Then, in case of React, if we are rendering a list and rendering heavy data on the screen, it is important that we have a proper loading mechanism, and we have a shimmer UI to give a consistent user experience. And the API has a proper paging and paging implemented so that the load time of the application is reduced. And in case of caching, it is important to consider caching as well. So having a proper caching mechanism in place, for example, other disk can be utilized to implement caching to reduce the fetch time of the APIs. And then, while doing so, it is important that we consider if we have a caching database in between and the sync happens with the actual database as well. So in case of that, we can have a proper cron job scheduled which would eventually do regular updates between the caching database and the actual database so that the data remains in sync. Considering these activities would really help us to scale and boost the performance of our React application. Considering the performance, we should have good performance tooling implemented within the React project. We can use Webpack bundle analyzer to handle performance-related issues. Doing package checks, package auditing is important. So, all of these practices help us to maintain a good React code base that is eventually quite scalable and secure.

In order to ensure code quality and maintainability in the team, which uses React and TypeScript, we should have proper linters, ESLint and CSS linting tools defined and implemented in the code base that helps us to write a clean and consistent code. Because we already have TypeScript, we have strongly defined interfaces and data types that help us to have well-written code. It is a strongly typed code in cases where we are having TypeScript. Then, we can have SonarQube implemented within our code base too and identify code smells to identify if there are any redundant codes. Then, we can have regular code reviews, peer reviews to identify the code quality is maintained and avoid identifying the code base which is reusable and moving that as a part of custom hooks and reducing the redundant data. We can categorize all the code as having a separate utils file for the generic utility functions that is used across the application. We can then move all the hard-coded strings as part of a file to increase the maintainability of the code and reduce the rework in case of any changes in any kind of user-centric messages that we have in our code. And, like, this would really help us to ensure code quality and maintainability, like having proper peer reviews, code reviews, implementing SonarQube, and having ESLint and CSS linting enabled in our code base.

In order to manage the state in a large-scale React application, we can leverage a dedicated state management library. However, using the library comes with its own steps, and we have to write a lot of boilerplate code. It always depends on the use case we are targeting. In cases where state management is complex, introducing a Redux tool into our codebase will help us maintain a central state management, a global state, and a global store, making state updates quite predictable and synchronous, and it would help us maintain the immutability of the state in our React code, which is very important, so that we have a one-way, or unidirectional, flow of data as React is not bidirectional. This helps us maintain immutability. So, we can use React as a state management library to handle state in our React application in cases where the use case is complex. In cases where the use case is pretty small, introducing Redux into our React application would unnecessarily increase the complexity of our code.

So in case of using SVGs and interactive animation, what we can have is we can have the SVGs either locally stored or we can host them on a CDN somewhere, and we can fetch the SVGs from the CDN and reduce the bundled size of our React code. And in case of interactive animation, we can leverage different types of React hooks, such as use layout or use ref, to handle interactive animation. We can leverage these React hooks to manage them efficiently and introduce complexity to the code that is being written inside the component. So, using a CDN would help us to reduce the size of our application instead of storing all of them in our local folder inside the assets, and interactive animations could be handled using different React hooks that we have. Either implementing them as custom hooks or using traditional default React Hooks could also help us to simplify the way the animation is being handled.

So, to use GitHub action workflows to ensure continuous integration, firstly, would be to have a proper gitignore file so that we do not introduce unnecessary code getting committed to or pushed to our gate, and that would be the first step. Secondly, implementing a strict pull request policy in the master branch. Then creating feature branches or demand should be a practice for all the features being implemented. And setting git push on the feature branches. And once the git code is pushed, we can have a rule, a GitHub action being set to merge the code from the feature branch to run a check on the code that is being committed to the feature branch to identify any unwanted code or invalid code. Then, during the merge of the feature branch to the master branch, we should have a CICD pipeline running that triggers certain actions after push or merge. That would first check all dependencies by running an NPM install, then run a check on the NPM dependencies to see if there are any malicious dependencies being installed. Secondly, we can have the NPM test running to verify if all tests are running successfully, then running a code smell using SonarQube. The SonarQube will give us a code quality report that will help us identify the code coverage. And after that, we can have a proper deployment that would be triggered to the environment that is supposed to deploy the code to. So, yeah, that could be the possible GitHub action workflows.

So, in this case, the and operator that is being used here acts as a conjugation, I would say, which says that the hover applies to the button. So, in case of any class, any form element, HTML element with the class name as button, is a whole word, then the background color of that element with the class button will change to dark blue. And in case we introduce one more class or dot button inside the scope, then that would actually conflict with the two. And the last one would take priority in that. And also, like, whatever element has the class button would have the CSS of a hover being applied and the background color being applied and changing whenever it is hovered. So, yeah, in case if there are the same two classes with the same name as button, then the last one would take precedence.

So, the use effect here is setting the value of the variable value using the use state after an interval of 1,000 milliseconds, and the dependency array is empty. So in this case, because it is empty, this would be called recursively causing a memory leak. And the third important thing to note here is that we should avoid using state updates inside useEffect because it causes performance issues.

To maintain the CSS styles in large scale application using the SaaS, you should leverage CSS modules, which helps encapsulate the CSS specific locally to the component, avoiding conflicts in CSS. We can then use style components or the block element modularity to help local, component-scoped CSS, avoid conflicting CSS, and maintain the code, having a minified version of the CSS that is not redundant. So, yeah, we can use this design pattern of BEM or CSS modules to increase the maintainability of the CSS. In case of SASS, we also have mixins and variables, and we can create those and import them into our project. We can also implement the OOPS concept within the SaaS-based CSS, which increases the maintainability of the CSS being written.

So, to create a reusable form component in the lab, we can first identify what possible types of elements a form can have. Say, an input field, which can be of type number, which can be of type text, which can be of type password, radio buttons, checkboxes, drop downs, multiple checkboxes, multi drop downs, selectable drop down boxes, and those elements can either be single or they can be grouped. Firstly, preparing a list of all possible elements that can exist in a form, implementing them using our TypeScript-based video, which can have a name, a unique name to that element. What is the type? Say, an input drop down, a radio button, a checkbox, or so on. Then, a value property, then we can have an object inside it called a validator. Inside that validator, we can have different sub-attributes, like, if it is required, if it has a pattern check. If it has a pattern check, we can define a regex there. Then, in case if the field is valid or not, is valid, false, and true, and a validation message field, which could be a validation specific to that form field. And we can use that object and pass that object to the reusable form component. And using that object, the form could be rendered dynamically using the data that is being passed. And to handle the CSS, we can either implement the form using the global application look and feel. For the element inside the form, we can have another object inside our form object, which could be style, which can have their own element-specific class names and CSS, which can be handled to manage the look and feel. And we can have a state variable called validator, which would set the state in case if the form has a property with valid faults. Then the state would be updated every time on change of the field. And we can display the validation errors on the screen using that. That also we have a very good React form, like, as a library that can also be used to implement forms in React.

We can create a mock data that's a mock of the Figma API, and we can create a mock render component of React, pass that mock API data to the render mock component method, and verify with expect criteria accordingly to check if the component is being rendered accordingly or not.