Siddhesh Rane

I have been a JavaScript developer for more than 6 years now. I have over 6 years of experience, working with React and React Native frameworks, both mobile and web applications. And, also, I have worked with Node.js, for 3 years, with 3 years of experience with Node.js. I have developed all kinds of apps, with React Native, maybe whether it's freight forwarding or stock market apps or voucher-based apps, with real-time functionalities, all, I have developed so far, in my previous and current companies. And, I also worked with WebSockets, GraphQL. I have used caching libraries like React Query and Apollo GraphQL, both front-end and back-end. So I also, like, I have good knowledge of Next.js. It's about caching. It's server-side rendering. And, obviously, Redux I have been using, for over 6 years. I've used Redux Saga, Redux Toolkit. I used Redux Thunk as well. I've even tried Just Redux, which is, which doesn't require a provider. So it is good, but it is a new technology. So, yeah, I mean, I have a good experience with React, with JavaScript, basically. With Node.js. I know, like, I have worked with real-time features. I have used Express as well. I have a good, like, a good knowledge of the event loop and how it handles the single-threaded, not just application by any heavy task it sends it to, and only executes the callbacks on the single thread. So it becomes non-blocking. And, also, it works, and its performance is very good. So yeah. I mean, I understand Node.js in, pretty well, as well.

Well, I think the best approach with WebSockets is that there are many approaches. First of all, you can use the WS library in both the front end and back end. And through this, there is one HTTP session and then there is a WS session which you have to make sure is available on both sides. So the same concept is used in Apollo GraphQL and Apollo server. So we can use that as well with Apollo GraphQL and Apollo server. In the front end, we can again use the WS library to set up the session for real-time subscriptions. And in the back end, through that session middleware, we can access whatever is passed through the API, the routes, and we can use that and through the resolvers, we can handle it in the back end for Apollo GraphQL. I haven't worked with Django much, but I'm comparing it to my Node.js experience, which for an app, I've already worked with a chat app. I involved using a front end Apollo GraphQL and Apollo server. And I managed to have a session with WS, enabling WebSocket and providing the important access tokens or any authorization-related material through the WebSocket session, which is then available in the back end as well. And there we can check the authorization process through the middleware and handle it. We can then proceed with the resolvers for the GraphQL. So I think then we can just perform our back-end database operations.

I think they have a use infinite query hook, which allows you to get a few properties and like next page property, previous page properties. Like, I can't remember the perfect names of the properties, but those like next page properties, previous page properties, and total count. But those things you have to handle in your API as well. Make sure those things are available. And it allows you to reuse the property to re-fetch with different next page property, or previous page number. It also gives you how many of those things are what you will have to set in the API where how many data you want. Like, if it's a list of data and how many count of that list you want in that response at that moment of time, when on that page. So, I think use infinite query is their one, and then I think which is pretty good for pagination, because if your list is like you want both ways, like going up, so you want to only get the first 10 for now. So you can basically, if you are reloading the page, then you can remember the page. It will remember the page in the cache, and it will load those 10 for you. Then you can also, within the final query, loop it upwards or loop it downwards. You can use the next page to bring the next in parameters next in response for the previous page number to bring the previous 10 responses. So I think that's how you can use it.

Interfaces and first of all, if you have a status of an employee, let's say you have an employee site, a few employee roles there are roles of employees like admin or just a normal employee or just a clerk maybe. So you can have those statuses predefined in a property. So you'll have clerk, basic employee, admin employee. Depending on those roles, depending on that, whether it's admin, you can have a different kind of functionality you can have. Then with interfaces, let's say there is an employee interface with some common data like name, age, employee ID, and all that. And then there is an interface for admin where you have some higher level of authorization properties like can access payment information or can make calls to the CEO or something, those kind of properties, and you can extend one interface to another. So let's say you want an admin employee, you can use that employee interface and extend the employee interface with the admin employee interface. And now you will have a bigger interface with admin and employee properties both. So you can do that. I mean, that's it. Like, it helps, first of all, to provide types to any large object structure. And enums basically facilitate any kind of rule or statuses you have in the app predefined that you know are not gonna change. So you can use that for. That's how it works.

In an existing application, first of all, I will need to add the TypeScript library and set up the Babel properties and the tsconfig. Once that's done, I think it depends on the application. If it's a JavaScript application, let's say it's a React application with Redux, then it will have a global state, like in a reducer. So, I would make sure that the reducer properties I am using are converted to types. Then, if there are some common properties in the state, which are shared in different states, we can have a common type for that. And maybe some properties are different for a few components, we can have different interfaces that extend that common type. We could also have enums, which, if there are already some rules in the JavaScript app, some predefined values that are not gonna change and on those values certain functionality depends, so we can have enums for that. We can also use generics, which is a dynamic typing, so basically, let's say, you have in the JavaScript app a lot of data coming in, but you don't know whether it's a string, you know that it has data, let's say, in the type of maybe string or number or an array. So, you can, with generics, define a type, let's say, T for a type and that type will correspond to, let's say, it could be a string, number or an array, so you can predefine it to accept these kinds of types and that becomes a generic. So maybe that would be also a very good way to make sure the app quickly gets converted to a TypeScript app.

With Redux action creators, we can use generics because with generics, you can first of all, generics means it's dynamic typing. So, if you like, with what action creators basically are, is they are just actions that change the reducer state. So, a lot of times, those actions are very similar with just different properties. So, you don't have to write multiple actions again for updating each and every state. You can just have a generic type which could take any of that state property like it corresponds, that type T should belong to any of let's say there is a state with a name, user ID, like employee subscription and everything. So, that type T that's passed into the action creator should only correspond to any of those types, and that way, we will only need one action just to update that reducer state. So, you can pass in let's say, you are updating a state during setting the state in the reducer. For that, you will need a separate action in a normal Redux action creator, you will need a separate action for name, for user, for ID. Suppose you are doing that, then instead of that, we can have an action creator with generics that could update. You could set anything, and that T could be anything inside the reducer. You could also make it to have a function in there, so you are just setting something or you are just calculating something and then executing. So, those things also can be achieved. So, yeah, I mean that's how you can use generics.

Well, first of all, this dot state is not synchronous and here it is called one after the other, therefore you don't know which one will get executed first. So that is a bigger problem here. Then this dot state of count, again another problem that this set state introduces is a problem of closure, where the count property basically means that JavaScript returns another function and that function basically keeps the values of the outer function and the inner function, and the outer function had few variables and the inner function is now returned. The inner function will retain those values of the variables, the value of the outer function even if those variables are changed later. So that's the problem with closure, and here since it's directly using the state, this dot state dot count, there is a problem of closure that can be created here where the count value will not change even if it's updated somewhere else. The set state will take the count value which was initially, what it was initially, and will again and again use the same count value even if it's updated somewhere else. So instead of using this dot state dot count, we can use the previous property, which can be like this dot set state provides a previous property. You can use that previous property and then using the previous property, it removes the problem of closure and gives you the current state in that previous property, it gives you the current value of that count state, and you can then add plus one. If you are doing, in this dot set state, if you are trying to do two set states together, one after another, instead of that, this dot set state, I think it gives you a callback. So you can add a comma after that first object and you can have a callback function inside there, you can execute the set state, the other set state. So that will be done one after the other in a synchronous fashion. So you can do that.

The error is with the name of the screen, the home page initial route name home page. It is not there. It is not defined in the create stack navigator. It is home and details that have been defined. So if you want to define an initial route name, it has to be one of the two mentioned in the create stack navigator. So instead of home page, it should be home. That is the error.

If it's already an DRF, if it's an API route, then we will have to use server-side rendering, I guess, because if I could just use the database directly, that would have been like we could have fetched the data from the server side, from a server component itself by using, by directly connecting with the database. But here you are saying that there is an API, so I think we will have to use a server-client component with any kind of hook to get the data from the API. So in that sense, I would suggest using React Query or any caching library. Let's say we are using React Query and since you are saying that it is fetching a large data set, so I would suggest, since it will be a huge list of data, I hope there is pagination in it, so we could use an infinite query or any pagination query and we could reduce that amount of data, like for every page, maybe, depending on how much data is there, we could divide it by, we could already make that possible in the API itself, where it, let's say, if it's a data of 1000, then maybe we would give only 50 for each page or 100 for each page. So that way, I think, first of all, we will be reducing the amount of data being fetched in the front end and also that data will be cached with React Query. So if the page doesn't change, the page number doesn't change or the user doesn't want to see any other data from that list, then you don't need to go and bring the data again and again. The React Query cache will provide it in case the user wants to, we can also provide a functionality where the user could specify a particular page in the front end itself, in the Next JS component where the user could specify a page and he will jump to that page immediately. So in that sense, the data cache will get updated to that page data. So I think we could handle it. I think we will have to use, like, I don't know what DRF is, but if it's API based, then I think we will have to use client components if it was directly connected to database and we could have used server components and directly got the data from the server itself, from the database itself. Yeah, so I think that's, that would be good.

The situation is successfully optimized. They react with performance in terms of both memory. First, the best way to optimize is Hermes. You have to use Hermes, which allows you to optimize and makes the app faster with the Hermes engine in Android. With the app itself, we can use React Native to animate it because it allows you to have animations on the UI thread directly. Instead of the JS thread, it helps you to have animations on the UI thread itself. So React Native basically has a JS thread and a UI thread. The JS thread connects through to the UI thread through native bridges, which kind of delays the process. So, within a normal animated library, which comes prepackaged in React Native, that's the problem – it has to go through a bridge to connect with the UI thread. So, instead of that, we could use React Native and the reanimated library, which also allows us to use worklets. Worklets are basically something that directly works on the UI thread, and the computations are faster, so we can use that as well. Then, you can also use the native driver property in some animations to make it faster to work on the UI thread. That's what the native driver property means. We could also use image caching libraries like React Native Fast Image to optimize the performance. Again, instead of scroll views, we have flat lists because most big apps have lists. So, it's better to use flat lists instead of scroll views because they are already optimized to only show the data that the user is seeing right now on the screen. The rest of the data is not really rendered on the screen, so that helps in performance optimization. Other things, like, I didn't know those things were enough in terms of optimization, but there is a saying that you don't use inline styles a lot. Use a style sheet because it's already optimized for better performance. I don't know how much it affects, but yeah, I mean, that's a good one – using a used style sheet property to write your styles and separate them out instead of having inline styles. So, that could be a good way to optimize it. Apart from that, I think native driver has already been spoken about. So, I think this should be enough. Yeah.

I have never worked with a Django application. I have worked with Node.js applications and the common vulnerabilities that you find with web applications are obviously, first of all, is authorization. So the best thing I would say is Veeam normally uses JWT or any kind of authorization, salt-based authorization, which makes sure that it encrypts any kind of user info and then decrypts it perfectly at the backend side. Then we could, in terms of security, again, it's important to have an SSL certificate where, whenever you are putting it, let's say DigitalOcean or anything, you can basically create your SSL certificate. Then I think HTTPS is obviously always used, never use HTTP for your servers. Apart from that, I mean, if you're using SQL, then make sure not to directly use SQL in your queries to avoid SQL injection. I think the best way is to use some kind of database layer, maybe Drizzle or Equalize, but make sure that you don't have anything in the frontend that exposes your API route that connects to the database. It doesn't expose this, let's say an input is there, and if someone puts an SQL in it and it directly goes and hits the database route, that is something that you have to avoid. So, I think you can have a middleware where you can have those kinds of checks where you can avoid, basically, any kind of SQL injection or authorization through JWT or any sort of method. So those things, you have to take care of in the middleware. Again, other security problems, I mean, those are the ones, I have dealt with, I remember. So, I think those will be enough, probably. Thank you.