Neil Doshi

Yeah. So I am a front-end heavy full-stack developer. In a sense, I have had more than six years of experience doing front-end development. And in that particular period, I have worked extensively with React JS and a lot of complementary libraries and tools around React JS, like Redux, Flux, various UI libraries, like Material UI, and CSS. So that's mostly under the UI side of things, which I've done. I have a very good amount of experience creating or writing some backend code in Node.js. Recently, I've also worked with Nest.js. But on the front-end stuff, I have worked on Next.js around service agenda, service generation. And then on the API side, I've worked on GraphQL. I've worked on REST. GraphQL-wise, I have written GraphQL mutations and queries. On the DB side, I have written certain code and done a bit of work with Postgres and MySQL, also a bit of work with MongoDB. So in general, I'm a front-end heavy person, so I've done a lot more work in front-end development. JavaScript is my core strength. And that's why I'm more towards the front-end side of things.

Strategy to I don't mind. I missed the previous question. Yeah. React memo stuff using hooks such as use callback, use memo, removing unnecessary props from the component, having certain default values to the component props, separation of concerns in the sense having anything which is not related to the component, not written in the component but in a separate file or making API calls separate from the component renders, creating custom hooks for them separately. These are multiple ways in which I can sort of reduce the number of renders. React.memo is something we used to do earlier. So these are the multiple ways where we can reduce the number of re-renders.

Security of data in front-end applications. Right. So you need to have multiple validations in place. All the fields, all the forms, they need to be validated. If it's highly crucial data, make sure that you have your data going as encrypted using Base64 passing through the API, so that you can immediately open it in your console and check the data. You also need to make sure that not all components have all the data. For example, using the context API, making sure that only the required data is visible to the component, and none of the other data is visible to the same component. Not storing everything in local storage, not putting everything in session storage – only the needed data should be stored. Cookies need to be encrypted. Except for any private data or confidential data, it should not be in cookies. Basic field validations, as said, empty APIs should be under authentication, so API calls need to be with authentications from the UI so that no unauthorized access is there through the UI. Protected routes need to be behind authentication. There has to be a protected route so that you cannot easily access them apart from our unless validations are in place, so you can make sure that happens with proper authentication. These are multiple ways in which you can make sure that the security of data in the UI. Yeah.

Because of creating a responsive design using CSS 3 media queries. Essentially, the media queries include small, extra small, medium, and large. For larger places, the nav bar can be full, and all options in the nav bar are listed in a horizontal manner as the media width decreases. You put a media query checking for the medium size. So then immediately, you hide the horizontal nav bar, and you have a button for the side drawer which would pop up, visible once that particular media query is hit. As it reduces, you adjust the font sizes, and you adjust the alignment accordingly so that the nav bar is responsive and does not look shabby or incorrect in whatever size and format you are seeing it.

You describe how you might implement lazy loading in React apps. So lazy loading in React apps, you could basically use suspense. You could use error boundaries. And so that once you have stuff in suspense, it would load up. I could understand that this is not immediately required. And then while packaging the stuff or while creating the build, it would basically chunk the JS so that it can be loaded up automatically later on as required.

If there is an issue with the way the set state is being used with the set time out, the issue is that React batches all state changes into 1. This means that when you're trying to update the state using setState, the new state will not be available immediately. A possible solution is to use a callback with the setState function, which takes the previous state and returns the new state. This ensures that the state is updated correctly and immediately. So, instead of doing `setDotStateCounter(dotStateCounter + 1000)`, you would do `setDotStateCounter(prevState => prevState + 1000)`.

User hook purpose: The user hook is used to expose a way to mutate the counter variable, specifically to increment or decrement it. Bug in reducer function: - The reducer function is missing a switch statement to handle different action types (increment, decrement, default, etc.). - The line 'count as 0 action dot payload' seems to be a transcription error, possibly 'count as 0 action payload' which would be incorrect because it's trying to set the initial state count to 0 based on the action payload, which is not the typical way to set initial state. - The reducer function is supposed to update the state, but the current implementation does not handle the 'default' action type correctly. - The line 'state slash initial state is count to 0' seems to be a transcription error, possibly 'the initial state is count to 0' which would be correct because it's setting the initial state count to 0. - The line 'count as 0 action dot payload' is likely a transcription error, possibly 'action payload' which would be used to update the state, but the current implementation does not handle this correctly. Corrected reducer function: ```javascript case 'increment': return {...state, count: state.count + action.payload }; case 'decrement': return {...state, count: state.count - action.payload }; case 'default': return state; default: return state; ``` However, the 'default' case is unnecessary because the reducer function will return the state as is if the action type does not match any of the cases. The corrected reducer function should be: ```javascript case 'increment': return {...state, count: state.count + action.payload }; case 'decrement': return {...state, count: state.count - action.payload }; ```

Critical and the parts in React. Critical rendering parts in React applications, your approach to optimizing critical rendering parts. Critical rendering parts refer to the components and code that are rendered initially when a user interacts with an application. To optimize critical rendering parts, make sure you're using React memo to cache the results of expensive function calls, and use memo for any heavy calculations that depend on props or states. When updating a state, perform a shallow compare before updating, especially if you have a huge state to manage. Ensure that API calls do not trigger unnecessary rerenders of components. Critical rendering parts also involve pagination of data. If you have a huge amount of data to be loaded, make sure it's paginated or set up to consume continuously stream data to improve render time and page experience. Ensure that CSS implementation is correct to avoid pixelation, incorrect styling, or spacing that makes the page unusable. Additionally, have a default state in place if the API fails, and a fallback state if the API fails and the user is notified accordingly. If any value needs to be saved or updated, have a proper alert for the user to ensure correct rendering in that place.

What's an opportunity for international address applications? We have an I-18 package. So, there's already in an I-18 package where we can supply multiple translations of the strings. Instead of hard-coding the text values into the strings, we could use these translations so that when the default state is set to English and probably pass in a parameter which you can wire into your UI, and then probably you want to drop down and select the language. So, our I-18 package will automatically select the correct language and show it to the user on the UI in the respective language.

How would you and I guess in the app, how incremental migration to TypeScript would be. For incremental migration to TypeScript, we would have to get started with the base types that need to be added to the application. And each component needs to start from the atomic components, and then starting from the base design components where we make sure that all the type scripts are there because they are being used in multiple places. So that is the place that I would start. Also, importing the required type no types for the packages that are being used. For example, the date package or probably a styling package that you might be using or probably some component package that you use, and those are currently having their types in place, and they're probably available on NPM. So probably importing those and that makes things easier. That's 1. 2, starting from the base components of the atomic components, that's the place that I would probably start to update the components with the TypeScript. It's a good thing to have a storybook in place, storybook implementation in place so that we could test stuff even before we start using it in the actual applications. We could do a parallel activity, and this would not hinder the current application development. And once we are in a stable state of those, we could start slowly migrating those to the so starting from the base pair components, then going to one level of HOCs, higher-order components, and so forth till we have where we hit critical mass that we can start moving all these components into the actual application usage. That would be the approach where you start from importing the required component types or the library types that your dependencies are, 2, implementing a storybook, and then implementing the TypeScript conversion into those. And then 3, 1 by 1, replacing the components or replacing the actual JavaScript components with the TypeScript components. This goes without saying that we also set up the TypeScript config and then also enable JS temporarily until and unless we are completely moved to TypeScript.