Imran Khan

Hello. My name is Simtar. I am a senior front end engineer. And for the last 4 years, I've been working remotely at early stage startups based in all over the US and Canada. My primary work experience has been on the front end with React JS based tags like React, Redux, TypeScript, JavaScript, and Next. Js. I can also handle back end to an extent. On the back end, my primary tech stack has been with Python, Postgres, AWS, and a few other, uh, infrastructure platforms like Render and Heroku. My last role was as a consultant for a US based startup called Altius Intelligence, where, uh, uh, we were building a social investing app, which allows users to compete with their friends, uh, based on their stock portfolio performances. I built the entire app, uh, front end and back end. The front end was built with React Native and Expo for both iOS and Android. Before that, uh, my role was, uh, that of a senior front end engineer at a startup based in LA. Uh, and we built a number of, uh, ideas and use cases at that start up. The first one was a reviews widget, uh, generator, which people can, uh, generate and embed in their website to showcase reviews about the products. The second product that we built there was an influencer marketplace where brands can search for influencers, uh, to promote their social media campaigns. Before Syncy, um, I worked at a startup called Sinatra based in Arizona, MT. Sinatra at Sinatra, I built a food ordering app using React Native and also a Vine ecommerce using React JS, TypeScript, and Python task for the back end. Before Sinatra, I used to work at a data analytics startup in Bangalore called Mammoth Analytics, where I took care of the entire, uh, full stack development, uh, and other internal tools development as well.

So in a React ecommerce application, uh, to manage state across multiple sessions, uh, I would map the index DB, uh, by adding a Redux store to the React application. And, uh, the Redux store will be the single source of truth of which the React application will access, uh, in order to display the UI. So whenever the user comes back to the application, they see that UI, uh, which they left, uh, or based on the route that they came back to. And the Redux, uh, store will then be saved or mapped directly, uh, in sync with the Index DB, uh, so that the Redux road persist even if the user, uh, refreshes or goes away from the session or the session ends for any reason, the user can always come back and see their application UI in the same, uh, state because, uh, it has been persisted in the index table. In addition to that, uh, the React application can further be enhanced by adding some middlewares like Redux Saga, uh, if it's a complex application. If not, then something like Redux Thunk should do as well, uh, which would allow to handle side effects more efficiently and outside of your, uh, Redux functions, uh, where, uh, the Redux Tang or the Redux, uh, Saga can take care of running the side effects like input outputs to the index DB.

So, it depends on whether you want Tailwind to be the primary CSS utility within the project or Ant-design to take reference. But what I'm understanding from this question is that some Ant-design components are used in the React project which primarily uses Tailwind CSS. So in that case, Tailwind CSS would have a theme config of itself. The Ant-design components can be configured to use that theme so that the look and feel of those components matches the rest of the project and those components doesn't seem out of the place within the project. And then since Tailwind CSS is the primary one, it can then be used to further modify the Ant-design components. So what we can do is we can import the Ant-design components in some wrapper components. And these higher-order components will then add Tailwind CSS to those components in order to match them with the rest of the existing React project. And then these wrapper higher-order components are then used elsewhere however needed. If some props need to be passed to change their appearance, then that could be taken care of as well in the higher-order component.

So it depends on what kind of experience you want to, uh, offer to your user. Uh, what you can do is you can keep collecting that dynamically incoming data from the Node. Js API, and, uh, the user can choose to load more via a button or some pagination components. Right? Another option would be to implement an infinite scrolling list so that when as, uh, as the user scrolls, the user doesn't even realize, and the data is always, uh, always keeps populating, uh, right as this goes. Uh, if that's the desired behavior or would lead to a better user experience for this particular use case, then that should be the best option. If not, if you want to give user, uh, the control to update the UI and be, uh, aware of which state the UI is in, you can allow the user to input some, uh, some sort of input on the UI like a button or some, uh, a load more button or a patch animation component, uh, so that they can, uh, load the new data themselves. Uh, right, or you can let the user know that there is some new data in this case, uh, by showing some sort of UI indicator like a red dot, uh, of some sort. And yeah. So these are a few strategies to handle dynamic, uh, data for large list. And as the user scrolls in, it could be infinite scrolling. It takes out, uh, a, uh, prerendered list out of the DOM and populates it with new one. And when those users scrolls back, it takes out the, uh, later ones and populates the previous ones, uh, to keep the DOM light. And, uh, in case of pagination, there is no need to worry because, uh, at a certain time, only a certain amount of components or elements in a list are displayed on the screen. So, uh, the DOM will always be light and without clutter.

So, that would be an uphill and mundane task because state is the core of any React application. And if the state is spread out very much throughout various components, it would be difficult to keep track of and equally hard to maintain the React application. So there should be some sort of effort made to unify all of the state under one umbrella using any method that seems feasible with respect to business requirements, the resources available, and the time and budget for the project. The state can be combined and put in one place either using the React context API or using some sort of utility like Redux, primarily for managing application-wide state. And then Redux can then further be paired with a lot of middlewares like React Redux and Redux Thunk to further improve state management and make it easier to do it in such a big application. And within the components, there would always be some state that remains anyhow, and that can be taken care of by using the useReducer hooks in React so that there are not a lot of state variables within each component. Instead, just one that accesses the state exposed by the common state exposed by the useReducer hook.

. So for time zones, for handling time zone and all the difficulties that comes with them, which are a lot, we should use some sort of base time within a database across our application and only in the UI that time is converted to the preferred time zone of the user. So for example, in a database, we can maintain a Unix timestamp and then on the front end, which would be our area of play, in React, we can convert that Unix time to user's local time. To handle this conversion, we can use some popular libraries like Moment.js to handle the dates and time and there would be a lot of consideration to be given to scenarios of deadlocks and locking a particular time zone or a slot, because once a user selects a slot, that slot should be disabled for a while for other users, otherwise, if this user, by the time they book that slot, that slot might have already been booked by other users, but this user was the first one to start booking that slot. So once a user starts booking a slot, we show that slot as disabled temporarily until there is a resolution of whether the slot is finally booked or abandoned or canceled. And since we are maintaining a common timestamp, the Unix time in our database, we just need to handle that behind the scenes, only the UI shows the local time so that there would be no confusion of handling any particular time slot across multiple users.

So in this class, there are a few functions like the fly, gather data, process it, and render data. And we define a new instance and immediately render the data. But, uh, I cannot see what data there is available within this class. So probably we need to define the data first and make sure that it's common across all the functions that they use and have the right permissions to use.

So in this class component, uh, the component did update life cycle hook. Uh, life cycle method runs whenever the component updates, and the component might update based on the state that is the updated, uh, state. Right? And once you set the state, uh, the updated state to true, which means the component has been updated. And so the component did update will run again, which will then again set the updated to true, and then it will keep on going in that loop always. Yeah. So in this case, uh, to avoid, uh, an infinite loop, we should have a condition to check the value of updated. And if that, uh, value has a is true, then you just return, uh, instead of updating it again. Right? So, uh, when component did update this call, first, you check if updated this stops, uh, state of updated is true. If it is, then you just return and you don't do anything to ensure that it doesn't go into a loop.

So, to handle real-time data streaming, there could be a few approaches we could take. The primary approach is an in-house socket-based streaming, wherein the backend streams over some sockets, and then the frontend application listens on some channel in that socket for that data, and then updates the React state with that new data that keeps flowing in. And in order to avoid the UI lagging, there could be some sort of control or some sort of time delay after which the new data is added, if it is happening to a lot of places. Or we could have a common Redux store, which has all the state. So whenever the new data is being streamed in through the socket, you can just update the Redux store and the entire UI, wherever that state is used in a Redux application, React application will get that updated state because it has subscribed to the store. And if the in-house custom-built socket streaming is not performing, you can always go for third-party solutions which have been perfected to the utmost limit to offer real-time and fast streaming. And some solutions that come to mind are PubNub. I've used PubNub at a number of jobs that I've worked, and PubNub is really good for streaming and handling the incoming stream of real-time data. Then PubNub also works really well with functional components in React and Redux. It has very well-documented SDKs, which perform really well and are compact in size as well. So using PubNub, you can handle incoming data stream and then do the updates to your Redux store, which then renders the new UI.

So in a real time data analysis application, uh, using GraphQL, if you are if, uh, we are using a provider such as Hasura, then Hasura has a feature where wherein, uh, this there are there could be subscribers, which are UI, and the back end database post updates to all the UI that has subscribed to a certain data or table. So, uh, the real time data can just, uh, instead of pulling, uh, the data is pushed to the front end application, uh, by Hasura if that, uh, is the GraphQL provider that you use. Yeah. And using that, you can, uh, basically, uh, just handle, uh, incoming live data and, uh, build your UI. As we are building it for data analysis, you might want to use some good charting library like the material UI x charts, uh, which are really good and really performant and, uh, has a nice appearance and animations as well.

So it depends on what kind of UI is being rendered. Is it like a 3 d, uh, render or like in, uh, a canvas drawing. So it really depends on, uh, what's the exact use case and requirement in that scenario. If, uh, the rendering needs to be a 3 d rendering, then you could go for some 3 d rendering libraries in the browser like WebGL, uh, uh, based on, uh, Open GL, uh, to render your 3 d UIs. Uh, you could also take a look at some sort of Lottie files and if you can generate the Lottie files on the go, uh, and, uh, create those 3 d, uh, or even 2 d renderings with Lottie files. If it's a canvas based rendering or drawing, then you would need a good canvas library, uh, which, uh, then you can easily use to render the parts, uh, on the UI. And it doesn't necessarily have to be either or. It could be in combination to a 3 d rendering, So you could use a canvas library as well as a 3 d rendering and use them in tandem with each other. Uh, if the rendering is, uh, in a different environment like a VR or AR, then we can use some browser compatible libraries for ARKit or VRKit, uh, to create those renderings based on the data that's coming in.