Pooja Sharma

So, I have 6 plus years of experience in web development and enhancement. Currently, I'm working in DXC technology as a software engineer. I'm working on a project called Alarm Codes, and I'm using Vue.js, version 3 with the script setup method, composition API, as well as HTML, CSS, and TypeScript. I have also crafted test cases for the same using Vitest. Additionally, I'm involved in deployment activities as well. For example, I'm currently deploying through Azure app services and CICD pipelines. In the Alarm course, we have also integrated SonarQube for code quality analysis and code quality analysis report. We check how much code coverage and code smell there are, and all these things. In addition to this, in my previous organization, I worked on a project using Vue 2 version. They also used features like mixins, Vuex for state management, and the library I18n for multilingual support and Vue Router. All these features I utilized in that project. Apart from development, I'm also involved in all the phases of the software development, like from requirement analysis to deployment. I'm also involved in training sessions and mentoring my junior resources. I've also been involved in Vue.js trainings. That's most of my experience related to my technical skills. Currently, in the Alarm course project, I was working on both the front end and back end. In the back end, we're using Java, Spring Boot, and Hibernate. I have the ability to work on multiple projects parallelly. For example, while working on the Alarm course, I was also working on another project called Guiding Star. I have the flexibility to work on different projects, and I have experience with both build tools, Webpack and Vite. In the Alarm course, I'm using Vite as a build tool, and in my previous project, I used Webpack. Additionally, I'm currently learning Nuxt.js, which is used for server-side rendering and good SEO optimizations. That's it, and I think that covers a brief introduction about me.

How would you handle input validation for data that is also being verified to a REST API? Okay, so in view there are multiple ways to do it. One is through a manual way we can do it. For example, if we are doing it for email or for a text field. Right? So there is one thing that we can do manually by checking the length of the character by using regex expressions. For example, some email. Email, we are validating. So through regex expression, we can check if that pattern is matching or not. And then text length, we can check if the type is correct. If we are expecting a string, so it should be a string. So with that type also, we can check. And there is a library also in the frontend that we can use to validate. It's easy to integrate and I have used that in a project. So there is this library called view validate which we can use to check all the inputs. So there is this directive which we can add and the messages we want to show. Right? If there is any error in the input field through that library, we can show that also. So there are two ways through which we can validate before sending it to REST APIs. So when we are making the call to the REST API, right, we can check and sanitize all our input validation. And that's how we do it. Two ways manually and otherwise we can make some use of the library as well.

Set up a communication channel between components that are not directly related but need to exchange RESTful API data. Okay, so for example, if we are using something in multiple components, it's recommended to use Vuex if the property we are using in multiple components is better to use Vuex for this. Vuex is a library for state management. That property we can keep in our state. And then after keeping it in the state, we can make use of mutations, actions, and getters. So, mutations and actions. Right? So actions are basically used for asynchronous calls. Here as we're talking about restate RESTful API data, probably we'll be using actions. And through those actions, we'll commit mutations, and mutations will mutate our property and will give you the updated data. And that updated data, we can use in our different components. So that's how we use it. And there is one more way to communicate between components that is provide and inject. So we can provide any property to and then we can inject that property in any of the components.

That we maintain state consistency across different routes and fetching data from how to ensure that Vue.js SPA maintains state consistency across different routes when fetching data from a REST API. State consistency, we can ensure it by updating that state property every time we are using that state property in any of the components. For example, there is some specific router and we are updating that state. So, that state should be updated in that particular component before we make use of the property. It's recommended to update that state every time there's a property change. So, we have to update that state every time in all the components and then make use of that state. That's how we can do it.

Do you manage component lifecycle in a way that it aligns with the data refresh cycle from the data refresh cycle from REST API? Okay. So, there are different lifecycle hooks we have created, mounted, and then updated and destroyed. So what we can do is make the call of the REST API in our mounted method. So whenever the component is loaded, right, or there is a change, we can make the call. Data refresh cycles line up with data refresh cycles from our REST API. Like, I have called REST APIs in the mounted method. So, loading right, and then we can use the mounted property. So if there is any property which is changing continuously, in that case, we can make use of watchers. If I'm not wrong, yeah, we can make use of watchers, and we can see that property is changing. Again, we can make a call to the REST API.

To integrate a third-party JavaScript library into a usage spec while ensuring it does not affect the performance of API calls, we would take the following step: First, we install the library, then create an instance of it. After making use of the library instance, we need to make sure that we are destroying the instance of that particular library. For example, in a component where we are using some library, we have to destroy the instance of that library after making use of it. This way, it will increase the performance because it will release the memory of that instance, which is occupied by the library instance.

It's been why the data test might not be displayed as expected in the view JS component. Yeah. Because we are making the API call, but we are not waiting for the result here. Like, await is missing here. So, it will not wait. Right? It will move to the next step. So it will show the component without setting this item's property. And, after that API, so that's the reason we are not waiting for the API response.

Common design pattern is used. What is it and how does it contribute to cleaner? Good. In this one, the JavaScript function or common design pattern used is the Singleton design pattern. We are using it because once my work creates a book, it will return data, and then we are again making the call. Okay. We are. I think the Singleton design pattern we are using because once my work creates a book, it will return data, and then we are again making the call. Closures. I think this concept is called closures because we are making use of the create book function as a parent method. So after executing that itself, it will return us, then we are again calling the internal method, my book dot read, and it will do so. Maybe closures are also related to the Singleton design pattern we are using or I think this is composable also.

time-efficient strategy to migrate a large-scale vanilla JavaScript application to Vue.js considering consistent interaction with existing okay so suppose we have an application right large-scale application in vanilla JavaScript so what we can do is analyze the code first and for CSS and JS we can create a separate file where we will keep our CSS and styling everything so we'll try to common link the common things right we'll try to fetch out and we'll try to keep that in a separate file like we'll create CSS variables and all those things only when CSS variables will make the changes of those colors and all and then in other classes and selector sites we can use those properties and you're asking Vue.js considering interaction with existing so yeah the first thing which we will do is we'll create components there okay different components for example if you're using any pattern input or if you're using any selector so we can create separate components for example and then we'll import those so first thing which we will do is like we will consider consistent interaction with existing large-scale apps so yeah what we will do is we will create components and we will install Vue.js in the application we will install Vue.js and we'll create separate components we'll try to import those components and for routing and all we will take care and UI through CSS and we'll common functionality will try to keep it in a separate file and if there is a parent child component we will make use of props if there is child to parent communication we will make use of emit events so for restful APIs we will try if there is some common data right so that we will do through restful APIs we will call through actions and if we are only calling those APIs in a specific component then we'll call those APIs in a separate component XDS library also XDS library configuration will keep in a separate file and routing also will define all the routes in a separate file like we use Vue router there so all the paths and everything will define there and if there is any there is any authorization authentication involved so that also we have to take care like our back-end should be authenticated so for that we can use the JWT token or something that so that the JWT token we will send from the front-end to the back-end and in the back-end we will check that if that is it will fetch out all the user groups and rules from that token and it will check for the access if it is okay or not so that's how we do it

When creating custom events in the UJS that synchronize with updates from our system, there is a 1 sync attribute which we attached with the elements. So it will automatically sync and custom events in the JS tab synchronize with updates. Or else we can make the elements synchronize with the updates by using the, what do we say? Like, if there is any property, right, which is updating, first of all, there is that sync attribute which we attached in the elements and synchronize with the updates. So if there is any property which is updating, so we can keep a track on that property. Like, we can watch for that property, and then we can make the necessary changes.

Third-party version custom component development consumes this from APIs. 3rd-party plug-ins; we will just install them and use them, those plugins. And once that is done, we will destroy the instance of that plugin. Custom component development, we can import that custom component in our actual parent component. And then in that parent component, we can, for example, have an input select. Right? And that select box is loaded through some data. So, in the parent component, we will import that select component. And in that select component, we have some data we are loading. Right? There are some options to select. So, that can be done in the mounted option. In the mounted, we will wait for the API to return us a response. Once that is done, we will load the data of that selected component with the data we fetched from the RESTful API. That's how we use it. In fact, third-party plug-ins: we import them, we use them, and then we destroy the instance of those plugins.