Shreshtha Srivastava

Yeah. So I have a total of 9 years of experience in IT, and in front end is around 7 years. I've been working with, uh, React, JS, HTML, CSS, JavaScript, Redux. Currently, I'm working with IBM from the last 3 years. Before that, I was working with Gofoge as a front end developer. And before that, I was working with Tech Mahindra as a core fusion developer. So, uh, in in front end development, I have around 7 years of experience, of which around 5 years is in React and Redux. So the current project that I'm working on is, uh, is an insurance domain project. We are creating a portal for the, uh, agents that are responsible for creating policies for their customers. So we are creating the portal where they can keep a track of all the, uh, uh, policies that they have created for their agents. So this is built using HTML, CSS, JavaScript, uh, React, and Redux. So we are using Redux for state management of the application. Uh, and my roles and responsibilities are to, uh, get the requirements. So we are following the agile methodology. So there is this requirement gathering session in which we are directly interacting with the clients to get the requirements. Uh, and if any doubts, we'll get the acceptance criteria for the user stories. If any doubts, we can verify that in these meetings. And once the user stories are finalized, we work for 2 2 weeks on that particular requirement. Uh, so, yeah, and so the designs are provided to us through Figma. We are responsible for reading the Figma and getting the designs and creating the UI as per those. Uh, we use Jira to keep track of certain tickets and, uh, confluence to get any, uh, API specifications or those kind of requirements from, uh, like, in all these requirements are kept in confluence for

So strategies to ensure the stability of front end features in SaaS applications with high traffic is like load balancing. We can have, uh, 2 different servers for load balancing. So, like, if 1 server is going down, we can uh, we can have a backup kind of or the user is redirected to the, uh, other, uh, load balancing server so that the application is never done and the user is always fetched with some, uh, data. Uh, other than that, we, as a front end developer, we should be enabling the cachey caching mechanism where it where it like, using which if the application is, in any case, is strong, we can, uh, like, fetch them some, uh, fallback or default UI kind of thing.

So in React application, uh, state management like, if it's a complex React application, uh, for state management, we can always, uh, use Redux. So, um, we have certain other methodologies to, um, maintain the application state, like context APIs. But if it is a complex application, we should be, uh, using, uh, Redux. So with Redux, we get the, like, application level of store. We get certain, uh, we can create actions. We can create reduce of functions, and we can, like, uh, we can, uh, dispatch actions on certain actions or, like, uh, rendering of the component. And, uh, once the action is dispatched, the reducer function is called, and then we can, uh, we can update the state. And to access the state in an application, we can use the connect red access connect method that we have. Uh, so we can connect our component with the redox connect method and fetch the values from the Redux store into our component. So the connect method uses map maps, uh, gets 2 arguments, map state to props and map dispatch to props. Map state to props is, uh, like map. There, we define what props we want our, uh, component to have. Uh, like, whatever props we, uh, are defining in map state to props, those props will be available in our component, and, uh, we can map them with the, uh, with some value that we want from the Redux store. Other one is the map dispatch to props, wherein we can define the, uh, dispatch functions that we are, uh, needing to from the Redux, uh, to dispatch certain action actions. And yeah. So yeah. Yeah. So on click let's say, like, I have a button and I on click of that, I need to make an API call. I'll make the API call. Uh, I'll get the data. I'll update the Redux store and, uh, yeah, and connect the uh, Redux and get the data. With the context API, the, uh, also, we can uh, manage this application level of state. But, uh, um, for complex applications, I I would prefer Redux.

Okay. So for React applications to, uh, to be responsive and adaptive, we can use certain libraries like, uh, we have this, uh, uh, React bootstrap that we can use to make the application responsive. Okay. So if it is about the styling, we can use Bootstrap or media queries to make it responsive. And, uh, or if if the question is asking about the how to ensure the RAM application is response and then it update without compromising the performance. So for that, uh, we can use certain like, to improve the performance, we can use certain performance enhancement techniques, like, uh, not rerendering the application again and again. But that too, uh, for that, uh, we can use the, uh, use memo, use callback hooks, and use pure components as much as required. And using keys for list values. Uh, if I'm rendering some list, I should be assigning some keys to them. That will make it more responsive. Yeah. So avoiding unnecessary reenters with the techniques, uh, will make it, uh, performant. Uh,

Technique to consolidate. Okay. So for validation logic, uh, let's say, uh, I'm creating a form in React application. I have multiple, uh, elements in the form like text box, check text boxes and radio buttons or, uh, or check boxes, I can apply validations on front end as well as whatever value I'm, uh, sending to the back end. There also, the validations can be applied. So, uh, like, on front end side, if I don't, there are certain, uh, things that I can do. Let's say if I have a simple text box and I'm expecting some numbers inside that I can I can, uh, tell I I can, like, add some attribute, like, what type of input box is this? If it is a, uh, text sorry. If it is a number, I can apply some logic like on change of the input box. I can apply some logic that if it is not, uh, if the entered value is not a number, either does not allow the user to, uh, enter the number, restricting the values, uh, and restricting any other values other than number. Or, uh, uh, I can, like, show some errors, some, um, like, uh, error below the text box that, uh, this is not a valid value for this for this particular field. Uh, apart from that, I can also apply some regex, uh, to match what I'm entering and, uh, what is expected in that, uh, particular box. So this is one kind of logic. If I'm having some, uh, so yeah. So and this is 1, uh, validation that I can apply on an on the front end side. Apart from that, I can like, if it is a checkbox, I can, uh, apply whether it is mandatory or not. Or if it is not checked, don't proceed on the button click of the like, let's say I want to perform submit the form on click the button, I can, uh, I can call a function and apply some logic that that would validate the input, all the input values whether they are required or not and what values I'm entering. And then only if everything passes, then only submitting. Otherwise, uh, doing some showing some error to the user. Uh, so on the back end side also, I think, uh, whatever value you we are receiving in the payload, we can check them whether they are, uh, so that will match the key keys and the values, whether this is the expected, uh, value or not. If not, then, uh, throw some error in the API response.

So one thing that I can, uh, think of is, like, frequent meetings. Uh, so whenever we are working on any new requirement, we should be, like, first discussing it with, uh, with the whole team, the front end and the back end. Whatever we are finalizing, whether that is achievable, uh, on both the sides or not. And, uh, then, uh, then documenting all the requirements, uh, from the front end and the back end side. And then, uh, keeping a, like, uh, log or keeping a record of the requirements so that, uh, anyone can refer to them anytime. The The most important thing is the, uh, meetings, like, uh, since, uh, most of the people are now following the agile methodologies, so that in a way contributes to this very much. Uh, so having agile methodology is so one thing would be, like, we are in a, uh, uh, we we are in the requirement gathering session. Both the teams are there, and the requirement, they can clear their doubts then and there. The first thing, if during development, anything comes up, there is there is this scrum call, and we can always clear our doubts there. And then whatever, uh, data that the back end whatever like, finalizing the format in which I'll be receiving the response from the back end, That should be finalized keeping, uh, keeping the, uh, things clear between both the, uh, front end and the back end depths. So they can discuss and then finalize the things as whatever is convenient for both of them. And yeah. So yeah. And having a requirement manager or a technical architect would help, like, uh, being the bridge between the 2.

Uh, instead of, uh, if, uh, and else if we can use the set statements. That would be more performant in this case, I think. So based on the data dot type, we can apply different switch conditions and yeah. And, uh, call whatever function is required for that particular type.

So to update the state, we are, uh, we are directly accessing the, uh, state inside the test inside the set state method. So, uh, it will not, uh, update the state instantly. Uh, so what we can do is, uh, inside of the this dot set state, instead of passing the object, we can pass in a callback function and then update the state.

So to handle error tracking and reporting in React applications, we can, uh, we can, like, uh, create a, uh, a kind of go global function that, uh, that kind of, uh, access a React boundary. A react error boundary, and display any fallback UI if any error is occurring and log that value in a, uh, uh, in a, like, globally created function. So if any error, we can log it there. Or on, uh, uh, application level, I think there is 1 on, um, I so there is 1, uh, component life cycle method that is there to catch any error in a component and, uh, log it. Apart from that, error tracking and logging. One thing we can do is, like, we can create a function at the root level and, like, use the memoization techniques to memoize whatever error we are getting and log it in a file or something.