Vishwajit sharma

So, hi. My name is Vishali Sherpa. I've done my engineering in 2015, and after that, I, uh, joined the IT sector, uh, as a front end developer. I have the expertise in HTML, CSS, JavaScript, jQuery, Bootstrap, and, gradually, I learned React as well. From the last 4 years, I'm particularly working on React project. So apart from React, I have an experience in NextGen's React Native, TypeScript, MongoDB, Express, Notes. So these are the things I have worked on. Uh, in the domain, uh, I have worked on. I have worked on ecommerce. I I have worked on health care domain. I have worked on, uh, HRMS domains. So these are the domains I have worked on. And, uh, you know, these are the things which I have worked on and I'm working on. So, yeah, that's a bit I have total experience of 5 and a half years in the front end development and more than 5 and a half years, and particularly in React, more than 4 years.

When should components be connected directly to application state versus receiving data from parent components, especially in large React projects? So in large React projects, deciding whether a component should connect directly to the application state or receiving data from parent's component is an important architectural consideration. So what we can do is the guidelines. The first is the global state versus the local state. Global state data needs the, uh, that needs to be accessible by many components across the application or data that should persist across various routes routes should be stored in a global state. Then we can have Redux, context API, or system. Local state is a data that is specific to particular component or a small set of components that doesn't need to be shared widely. Uh, next is the component reusability. Direct connection if a component is intended to be used in different parts of the application and requires data from the global state, it can be connect it can connect directly to the global state. This makes the component more reusable and because it doesn't depend on the parent component to pass down the required data. Then parent provided data. If a component's data needs are specific to a particular context or a particular parent component, it is often better to receive data as props. This allows the parent component to manage data and pass down what is necessary early, leading to better encapsulation and easier testing. And performance considerations must be there. Direct connection is there. Parent provided data. Separation of concerns must be there. Then testing and debugging should be there. So in conclusion, large projects of balance between these two approaches is often necessary. Key components that need to access global data or dispatch actions should connect directly to the state. In contrast, other components can remain dumb and receive data through props to keep the architecture clean and unchangingly or unmanageable. Using patterns like reduct selectors, memoization, read it reacts Context API can also help performance and maintainable maintainability regardless of, uh, approve, uh, approach choose.

What would be your approach to set up a GitHub actions workflow for continuous integration of a new feature in a React project? Setting up a GitHub actions workflow for continuous integration in a React project involves several steps. The primary goal are to automate testing, linting, and building of the project whenever changes are pushed to the repository, especially for new feature branches. So the first is to create a workflow configuration file. So in a React project, create a new directory called workflows and add a YAML file for the CI workflow. Then, uh, the next is the breakdown of the workflow file. So the name of the workflow specifies the events which triggers the workflow. Push, pull request, jobs, runs on steps, checkout codes, step, uh, install dependencies, run test, build projects, then the additional considerations like environment variables. If your project requires environment variables, we can set up them, uh, in the GitHub repository settings under secrets and variables actions or directly in the workflow file using END key. When caching the speed up, uh, to speed up workflows, you can cache node modules using the action slash cache action. Notifications set up notifications for CI status via Slack or email. Testing the workflow. Then once the workflow file is set up, push it to the repository. GitHub actions will automatically run the CI workflow on the specified events, improving the workflow, deployments, code coverage, end to end testing, security checks. So this setup provides a basic CI pipeline for React project, ensuring that new feature are continuously integrated and validated through automated testing and build processes.

If a project requires extensive use of SBG and interactive animations, animations. How would you structure your React components to efficiently manage these assets? So when working with a React project that extensively uses SVGs and interactive animations, it's important to structure your components and manage assets efficiently. 1st is you should organize the SVGs. SVG as a component. For SVGs that require interaction or animation, import them as React components. This allows for greater flexibility and you ease of use. Tools like SVGR can convert SVG files into React components, allowing you to use them directly in GSX. Then we have the centralized asset management to store SVG files in a dedicated directory, then create an index dot JS file in the SVG directory to export all SVG components. This provides a single import source, simplifying imports throughout the project. Then the component structure for animations and SVGs should be reusable SVG components. Create reusable components for commonly used SVGs with animation or interaction logic encapsulated within the component. Use props customize the SVG appearance or behavior. Then animation components for complex animations consider libraries create higher order components or hooks for animations, and then apply them to SVG components, then efficient SVG management, optimize SVG files, like, for tools like SVGO to reduce file size and remove unnecessary metadata. Consider inlining small SVGs directly to component files for better performance than lazy large, uh, you know, SPGs as lazy load for larger infrequently used SPGs implement lazy loading to improve initial load performance. VX lazy and suspense can use for this purpose. Use context or state management for interaction state and using, um, CSS in JS for styling and animations like libraries at their style components emotion. So efficiently managing SVGs and animations in the React project involves a combination of best practices, including optimizing SVGs using appropriate tools for animation, and maintaining clean separation of concerns between presentation and logic. This approach not only ensures smooth performance, but also makes the uh, project easier to maintain and extend. So in that way, we can do it.

How does TypeScript enhance error detection over plain JavaScript in the development process? So TypeScript enhances error detection and, uh, overall development experience in several key ways compared to plain JavaScript. 1st is the static type checking. TypeScript introduces static typing to JavaScript, meaning types are checked and compiled time. This helps cache type related errors the code runs, unlike JavaScript where such errors may only appear at runtime. In JavaScript, the above error would only manifest when the function is executed, potentially leading to run time errors. TypeScript catches this mistake during the development. Then the enhanced ID support and auto completion typescripts type system allows for richer IDE support, including accurate auto completion, inline documentation, and type inference. This lets to improve developer productivity and reduced errors caused by incorrect function usage or property access. Then the type inference. TypeScript can infer types even when they are not explicitly defined. This helps detect errors while minimizing the need for verbose type animation. Structural type system. Type suit uses a structural type system which checks the of types based on their structure rather than explicit declaration. This is particularly useful when dealing with context objects and ensures that object properties matches expected structure. Then optional and union types are there with type with TypeScript supports, which helps model more complex data structures and potential values leading to better error detection. The interfaces and type aliases, uh, that that that promotes consistency and reduces the likelihood of error, strict and null checking, uh, like undefined and, uh, that, uh, null compile time error detection. Then TypeScript, uh, type system provides a robust framework for detecting errors at compile time, improving code reliability, maintainability, and overall development efficiency. By catching errors early and providing better tooling support, TypeScript helps developers write safer and more predictable code compared to plain JavaScript.

How do you structure your GitLab CICD pipeline to efficiently handle multiple feature branches as well as staging and production environments in a project? As well as well as staging and production environments in a project. So structuring a GitLab CICD pipeline to efficiently manage multiple feature branches along with staging and production environments in a real project involves setting up a well defined pipeline with different stages and jobs. So the basic pipeline structure is, uh, you should create a basic pipeline structure, stages, and jobs. Build stage is there. Install dependencies, artifacts, test stage is there. Run test and linters to ensure code quality. Only the this job requires for branches and tag deploy stage, define different end deployments jobs for staging production environment. These jobs should only run for specific branches of tags. Then environment only when manual environment specific configurations to handle different configurations for staging and production. You can use environment variables, store sensitive information security in GitLab, CICD variables, and handling feature branches. For feature branches, the pipeline should build, test, and possibly deploy to a staging environment for testing. You can automate deployments to temporary developments or sub domains if necessary, dynamic feat environments, monitoring and rollback, monitor deployments and have a rollback mechanism in place. GitLab provides an environment dashboard to track deployments and rollbacks, then approval and notification using GitLab's built in approval system for production deployments, set up notifications for pipeline status updates. Then the best practices should be testing in CICD, security, documentation. So by following these, uh, steps, we can set up a robust GitLab CICD pipeline that efficiently handles multiple feature branches, staging production environment, ensuring a smooth and controlled development and deployment process.

Uh, can you describe what happened in the schedule for handle data is called with null or undefined argument? How would you factor this? Uh, in the data. No undefined argument. Okay. So if if the null or undefined, uh, data would be passed, then data dot trim because data dot trim a function specific to strings only. So in case of null or undefined, it will give you an error. So what we can do, we can optional chaining here. So data question mark dot trim. So if the data would exist, then and only trim function should apply. Otherwise, it should not apply. So that's the, uh, most important, uh, thing which we can do here. Null and undefined would should not be counted. If else condition can be logic, otherwise, the most, uh, beautiful thing is using optional chaining.

Okay. In the SaaS, could you explain the use of and and identify the potentials that might have missed another dot button inside the scope? Okay. So inside the container button is there, uh, and hover of that button color is background color is, uh, converted to dark blue. So and is just like, uh, you know, uh, the CSS, uh, hover, uh, class or hover effect to add in the, uh, SaaS we use. And so in any component, uh, if the end is there, so it would be applied to that immediate parent component only. In that case, the button is the immediate parent component. So what would happen if we nest another button inside the scope? If we nest another button, then that hover effect would be applied to that nested, uh, who, uh, you know, button also. So in that case, it will be a CSS it would be an issue to nest another button. So we should not nest another button inside that scope because the hover effect will be apply automatically applied to that, uh, button also, which we may not want.

Present a pattern or approach for ensuring the maintainability of CSS styles in a large React application using SASS. Maintainability, uh, maintaining CSS ties in a large React application can become challenging as the project grows. So using SaaS with a well structured approach can significantly improve maintainability, scalability, and consistency. Here's a pattern what we can follow. The first is the modular file structure. Organize your SaaS files in a modular and hierarchical structure. This helps in maintaining a clear separation of concerns and make it easier to find and update the styles. Next is, uh, what we should do is using variables. Define CSS, uh, assess variables for colors, font, spacing, etcetera, in a variable dot SCSS file, uh, that decentralizes the values and make it easy to update them across the entire applications and make sense and functions. Use make sense and functions to avoid repetitive code to handle complex styling logic. Store these in, uh, underscore mixins.scssandunderscore functions.scss, and component level style should be there. For each react component, create a corresponding SASS file in the components folder. This keeps components styled, scope, and organized. Next is BM naming convention, block element modifier, naming convention to maintain a clear and consistent style across the project. Then teaming, manage manage themes in the themes folder. This allows you to switch themes by simply changing the imported theme file. Then global styles and utility classes, uh, should be kept in a separate files, uh, and included as needed. Then importing the SaaS files in your SaaS file, import all the SaaS files in a logical order. Then what we can do is linking and style guidelines and documentation. So by organizing your SaaS files in a modular structure using consistent naming conventions like BEM and leveraging SaaS features like variables, mixins, includes, and functions, you can significantly enhance the maintainability of CSS files in a large React application. This approach not only improves readability and scalability, but also facilitates easier debugging and collaboration among team members.

Describe the approach you would take to use sketch design files to automate the component regeneration process. So in a component regeneration process, we can sketch the design using Figma. Uh, Canva tool is there. So there are multiple tools. I don't have an idea about it.

Where you had optimized the react application on this. So I have used, uh, react lazy loading for optimizing the, uh, first FCP and LCP. Then I have used image optimization, images, uh, have been used, uh, for, uh, optimizing, then optimizing the web pack in the week. I have used the roll up roll up burners I have used. So these are the things I have used.