Srushti Suvarna

Yeah. Hello, team. Uh, so I'm a front end developer with around 4 years of experience in front end development, uh, specializing in HTML, CSS, JavaScript, and, uh, frameworks such as Vue and React. And throughout my career, so having, uh, dedicated to crafting visually appealing and user friendly solutions, having worked on various projects ranging from US health care, uh, domain. That's the comprehensive health record management and many types software and the digital news platform, uh, project, uh, for the, uh, at Infosys. That's where I'm currently working on for the McClatchy company. Besides this, I have exposure to, uh, Beautify, Tailwind, uh, Casa, uh, for the UI layout, Jenkins, uh, for the, uh, CICD, get for the version control, TypeScript, and, uh, Jest and Cypress for the testing tools. And that's pretty much. Thanks.

Okay. So to ensure the TypeScript type safety in a Vue JS project, uh, we use the interfaces, the type aliases for that to ensure the type safety. And, uh, yeah, and as TypeScript in TypeScript, uh, it's better to have the, uh, variables. It provides the type safety for the static typing. So, uh, we would, uh, assign the, uh, data types to the functions, with the written variables, and each and every variable.

Yeah. What approach would you take is manage the state in a BlueJeans application. So for managing the state, I have worked on with UX and Kenya both. So, uh, and, uh, as I worked with Kenya, so I found Kenya more better than the US as it has the modular API as comparative to UX. And, yeah, we can have the subscribe method as well, and it's simpler to use than UX. And, yeah, we can use both, though. So the flow goes like we have the state, the getters, and the actions for that. And, uh, so it would be a single source of truth we can have for the, uh, for our application. In Vuex, we can have 1 module, uh, means, uh, one base file, and it that would be one state management, and that would be different modules. But here, we can have the different modules bifurcated, and we can in. And we can import it, uh, accordingly to our needs to have the code splitting and optimize the page load time as well.

To ensure that the Vue JS application's UI is responsive and adaptive to various devices. So to have the responsiveness in the UJS application, uh, I have user techniques to, uh, have it, uh, use the media queries and, uh, use the, uh, so we use the beautifier, and they are using material design UI. So even if we don't use the beautifier, we should stick to material design UI and have the typographic things, the size things defined for this much width and the means this much of the device. That's the SM or Excel, uh, medium device. This should be the, uh, typography and the, uh, typography size, and this should be the container size. So we can define it like this, and there won't be any issues with that, uh, further so that and, uh, we can check, uh, check with the Chrome DevTools and the View Dev Tools as well. So for different devices, we can even use a simulator. That's the Sauce Labs, uh, that we are currently using in our project to check and run the application, uh, thoroughly, uh, in an actually, a device, but a simulator. Yeah. So in an actual device like this.

What techniques would you apply for migrating a JavaScript project to TypeScript effectively? So, yeah, so for migrating a project so as TypeScript is a superset of JavaScript, we can go 1 by 1, changing the migrating 1 by 1 files, sir, to from JavaScript to typescript, and it would get converted accordingly as it would be having the config file for that, uh, where we can mention these files has to be changed and this doesn't have to be changed or the folder mentioned. And we can go to each and every file, and we can have the base structure first to decide it. Like, this would be the interface folder. This would be the type aliases folder if we are using the base, uh, interface that would be used for many files. Yes. So we can have the basic, and then we can start with each and every component and go through.

This this application. Okay. So, uh, if the, uh, if the, uh, page load time initial is needed much, Uh, so in case of server side rendering, we can have the page load I mean, the the main layout, the HTML, would be compiled at the server, and then it will be sent to the client. So the page load time would really increase at that time. I have worked on the server side rendering with structuring. And, uh, in, uh, React, I've implemented it using the, uh, use, uh, async data thing. So have logged in you and react for both for the server side rendering. Uh, and, uh, for the client side rendering, it would it it's like the file would be, uh, rendered on the browser, and then it the JavaScript would be compiled on the browser. So it would take time for the file to be compiled and then rendered. So there would be a lag between the page loading and the, uh, responsiveness of the element, the UI.

So here, instead of selecting every field from the users, we can have specific thing, uh, means an object pass or specific set of fields that should be extracted from the users and not the whole thing, uh, and not all the fields. So that would be a best practice that we can follow.

Firstly, uh, for the error handling, uh, we can have the error handling much better than this. We can have the status codes, uh, defined in the, uh, in a one file, and then, uh, we can use it here directly. Uh, so if this is a status code from the written from the API, then that should be the message or that should be the thing that should be rendered if we get maybe we are calling some other API or some layout. The error page is some particular error page has to be rendered or we have to redirect to to some other page. So, accordingly, the error handling can be, uh, can be, uh, optimized, uh, using these status codes, the API status codes that you would be getting. And instead of fetch, if we, uh, can use exeos, that would be better for the error handling, actually, because the, um, in a fetch, it doesn't consider the your 500 or the 402 errors as the error. It just considers the 400 errors as the error. Uh, all the other errors would be in the success as well success only. So for that, we can, uh, for better error handling and, uh, the method types as well, we can use exeos over fetch because of its, uh, structure.

So for lazy loading the components in our Vue JS application, we can, uh, we can, uh, use the import thing, uh, and, uh, yeah, it would be imported. We would be it would be an arrow function like thing. We, uh, brackets and then import, and you would be having the file path over that. So we can use the lazy loading like the, uh, this for the components in a new JS application, and the lazy loading would really optimize the page load time as we would be having the conditional rendering in the template that we have. So, uh, we don't need the all the all the components at the initial time only. Uh, so we can use a lazy loading like this. Yeah. And, uh, in view router as well, if you have the router file, we have many routes. So we don't need to, uh, don't have to import all the, uh, components at the initial lines. Like, the initial stage, we can just import the file whenever that router hits, actually. So this would optimize, and we can implement the lazy loading like this.

So what strategies would you employ to, uh, to integrate the WebSocket communication? Uh, we can use the socket. Io library, uh, that is provided from the, uh, NPM. So, uh, we can direct, uh, we can use that. And using that, we can have the WebSocket connection build up and use it methods to send and receive the data. So the WebSocket is, uh, once there is a handshake, it's, uh, once there is a handshake between the client and the server, we don't need to uh, repeatedly we don't have to repeatedly, uh, have the connection built out. Check the check if it's legit or not, the accept headers and all. So once it's done, uh, once the connection is built, it would stay alive for until we close it down. At last, that's the close thing, dot close. And, uh, this would save the time, uh, of the WebSocket, and there would be the and at the same time, this client and the server can send and receive the data.

So, uh, uh, I, uh, I I don't have the experience over the electron JS framework particularly. But as it's mentioned, like, uh, we have to integrate an electronjs framework in a web application. So, uh, uh, we can use the global CDN or the NPM install node package man we can use a node package manager NPM or Yarn for this, and we we can have the config file defined for it. And, uh, we, uh, yeah. According, um, upon the config files, we can have it, uh, injected into the main entry file that we would be having and use that, uh, in the application. Uh, for further depth, I will, uh, I would like to go into more depth and review the documentation of the electron g s and can learn about it. Yeah.