Deepak Rajkumar

Could you help me understand more about your background by giving away production of yourself? Hi. So this is Deepak Rajkumar. I've been working as a software engineer for the past 5 years. I have major expertise in the, uh, tech stackers, React JS, Mix JS, React Native, um, Tailwind CSS, and, uh, Shard CN. Uh, so post SQL MongoDB, etcetera. So I've been working as a software developer, uh, and with multiple different organizations. I've started working with the service based organization, which is, um, data analyst giant in India. After that, uh, and I've been working with I was working with them since their early stage when they had just 200 employees. Now they have scaled up to more than 6,000 employees. After that, I moved to a product based, uh, organization. It's now an IPO level organization. I I was with them, uh, till the so I was I played a major role in, uh, attending their IPO because, like, we were working on the website. I I was one of the key engineers in the website team. After that, I moved to a start up for the to keep growth in mind. And I I was one of the earlier engineers in that start up. I was started as one of the 20 engineers there. Uh, once I so now the startup within a series b stage, and I will I was an integral part of the startup from their, uh, early stage seed till their series b round. Now they have around the 2 50 to 300 employees. They were quite 2 different organizations as well. So it scaled pretty much. So now I'm looking for a change, uh, to extend my expertise in helping, uh, helping the, uh, helping the companies along with that to learn with them.

So, uh, what methodology would you use to integrate complex animations within a React Native app that also need to be reflected on a Next JS web app? Okay. So let's well, it's like so maybe let's say, uh, uh, integrating these complex animations, uh, within a React Native app and also to ensure that they're also preparing the Next. Js application, This involves a multifaceted approach, I would say. So first, we have to define the animation requirements and the constraints. Then we should use some, uh, cross platform animation libraries such as the framer motion, lottie, etcetera. Then we should abstract the animation logic. And we should synchronize the state and events across the across different platforms. Then more importantly, we should optimize the performance. So let's, uh, get into each and, uh, every part in detail. First, I would say we have to design define the, uh, animation, uh, the requirements and the constraints. Right? 1st, I integrate the common elements. So, like, determine the, uh, animations that need to be consistent across both the platforms. That is an x. Js and the React menu. This could include, maybe, the page transitions, the button effects, loaders, etcetera. And you should use some cross platform animation libraries like Lottie or Framer Motion. Framer Motion for the web and, uh, reanimated for the React Native, we can use. Maybe these libraries are platform specific, but they offer, uh, similar APIs and concepts for creating these complex animations. Maybe we can abstract the animation logic also into reusable functions or hooks, uh, that can be adapted, uh, to each library specifics. Uh, we can use something called Lottie also for complex animations because this is a library that enables the Adobe's, uh, after effect animations to be used on the web with Lottie web and also with mobile with Lottie for React Netter. So this is one such method where we can utilize that. Other than that, up after doing that, we have to abstract the animation logic as well. Right? Which is, let's say, we have to have a shared logic for animation triggers, and we can develop custom hooks for all the utilities. Uh, then the important concept is to synchronize the state and the event across events across platforms. Uh, we should have proper state management solution that is flexible enough to be shared between the React j React Native and the Next. Js. So we can use use stand or Redux to manage the state, and the event should also be synchronized. So these are the different methodologies I would use to integrate the contract animations within both React Native app, and the and that will be replicated in the next JS product application as well.

So, how would you perform end-to-end testing on a project developed simultaneously for web, iOS and Android within a Monorepository with XJS and React Native. Let's check that, ok. So, end-to-end testing for a project that is developed simultaneously for web, iOS and Android with Monorepository, ok. So, the end-to-end performance testing, right, which is E2E testing, which is on a project that developed simultaneously for web, Android, iOS within a Monorepo. Maybe that with the XJS or web application is, maybe we can, so we should use, first thing is we should choose right tools for it. There are tools like Cypress, Selenium or Puppeteer, right. These are excellent tools for web applications. These tools, maybe they can simulate user interactions on the web browsers and assess the behavior of the application as well. For mobile end-to-end testing, for React Native in particular, we can do something called Detox. This is for both iOS and Android, right. And something called Appium, that is also a powerful tool for simulating the user interaction on mobile devices. And there are a few unit testing frameworks as well, such as the Test Cafe, that can be used across mobile and web platforms. And the step-by-step process would be, we should first set up a testing environment. Maybe we can use something called Docker. The Docker containers for the web apps, backend services to ensure consistency across environments because we can use, we can have the same backend for both the React Native and the XJS application. If we dockerize it, it will be easier for the testing. We should utilize some emulators for Android and simulators for iOS for mobile testing as well. That is also possible. The major part would be to write the platform agnostic test cases. So maybe, and also, if needed, we can implement some platform-specific tests as well. And we should have optimized execution, like selective testing and parallel testing. And then we should maintain the test data and the box as well. So the cross-function collaboration is also important in it, I would say. So we should involve the quality analyst in the development phases as well. If we have proper documentation and knowledge sharing over the course of the project development, it will be easier to manage that, I would say. So by this comprehensive approach, this ensures the application delivers a consistent and bucked pre-user experiences across the web, iOS, and other platforms. And I would say we should also regularly revisit and refine the testing strategy based on the new learnings and technologies available on the market.

How do you optimize the bundle size of a React Native app to improve the load times and the performance of a shared Next JS web platform? Okay. So So optimizing the bundle size of a React Native app to improve the load times and the performance, especially in the context of sharing a code base with the Next. Js application or web platform within a mono repository. It requires an holistic approach that targets both general optimization strategies and the platform specific tactics aspect. So let's let me roll out some key strategies to consider. 1st, just analyze the bundle size. Uh, so maybe let's, uh, use let's use some analysis tools. Let's say for the webpack, we can use some tools like webpack, bundle analyzer, or Next. Js's built in analytics. These can help in identify which libraries or modules are adding the, uh, like, most to the bundle size. For React Native, we can use tools like, uh, React Native bundle visualizer to understand the composition of the mobile app bundle. So that's one, uh, good approach. Next is we can use something called, uh, optimize the shared dependencies. Uh, we can use tree shaking and, uh, dedupe dependencies. So for tree shaking, in sense, we can ensure the code and any shared libraries between xjs and react handle support tree shaking to eliminate unused code. Next, uh, the dedupe dependencies, which is in a mono repo, we can ensure that there is a single version of any shared dependency to avoid the dedu the duplication in the bundles. Then, uh, we can code split and dynamic we can have dynamic imports and code splitting. So Next JS, you'll utilize dynamic imports with the next dynamic next slash dynamic for splitting the web app's code into smaller chunks that loads on demand. React Native does not support dynamic imports in the same way as web apps, but we can use techniques like lazy loading of, uh, assets or splitting the app into multiple bundles if supported by the platform or the build tools. Next is we can optimize the image and the assets. So, uh, we can use some image compression tools and modern formats like WebP for mobile and, uh, web to reduce the size of image assets. Then we can dynamic loading. Uh, we can load images dynamically, uh, based on the screen resolution and device type to avoid over fetching high resolution images when unnecessary. Right? That is one other thing. We can utilize efficient libraries and frameworks. For common functionalities, consider using lighter alternatives to heavier libraries. For instance, if you're using Lodash, input only the function we need, or we can switch to a native JavaScript implementation. So we can optimize React Native specifics. So native modules, uh, headless engine, we can enable the headless engine for React Native, which can improve the shorter times. And we can lean on service and rendering and static generation for the next JS application. We can strategically, uh, cache, uh, cache it to improve the performance as well. So these are some of the, uh, optimization techniques I would follow.

So, can you devise a strategy to maintain feature parity across web, iOS and Android if you have separate UA requirements using React Native and Next.js? So, yeah, maintaining feature parity across web, iOS and Android platforms while accommodating separate UI requirements with React Native for mobile apps and Next.js for web apps within a shared codebase on Monorepo. This involves a strategy combination of shared business logic, platform-specific UI layers and it also has to have a coordinated development practices. Maybe I'll give you a strategy like how to achieve this. First is we have to have a shared business logic with platform-specific UIs. So, there's something called we have to centralize the business logic that is extract and centralize the core business logic, utilities and state management into shared modules that can be imported by both your React Native and the Next.js applications. This ensures consistency in functionality across platforms. Then we should have a platform-specific UI layers like we can implement platform-specific UI components and styles to cater to the unique design and user experience guidelines for each platform. This can be done by leveraging React Native for iOS and Android and React with Next.js for the web using conditional imports or directory structures to separate platform-specific code. Then we can design system and component library. We can have unified design systems. We can develop a design system with UI components and design tokens that are consistent across platforms, adjusting for platform-specific wherever necessary. We can use tools like Storybook that can really help in managing the system. Then we can have adaptive components. We can create adaptive components that can adjust their layout and functionality based on their platform. We can use React and React Native's platform detection capabilities to apply platform-specific properties or enter alternative components whenever needed. We can implement feature flags and we can use feature flags to manage the rollout of new features across platforms. This allows for A-B testing as well and has the ability to quickly revert changes if issues are detected. We can have centralized feature management and we can have cross-functional teams as well. We should automate the testing and have proper CACD for that. More importantly, it would be always nice to maintain proper documentation and communication across the teams. The feedback loops and the analytics and user testing will always help and based on that we can anytime advance the code base, we can do that.

How would you employ lazy loading in a Next JS app to improve performance on mobile platforms where the same code base is used for a React Native app. So employing lazy loading in Nextiva's application to improve its performance, uh, especially on mobile platforms, involving strategical so this involves loading resources and components only when when they are needed. Right? So this can reduce the initial load times and resource conception, which is crucial for, uh, mobile users. Right? While Next. Js and React Native have different mechanisms for implementing lazy loading due to their distinct environments, which is web versus mobile. Right? Sharing a code base between them focused on optimizing performance to similar conceptual approaches. Let's see how it's differs for the Next. Js app. So lazy loading in Next. Js is we can dynamic, uh, we can use something called dynamic inputs of components. Next. Js supports dynamic imports out of the box with next slash dynamic. This is useful for splitting the code at a component level, uh, loading components on demand. This approach allows users to defer the loading, uh, defer loading the noncritical components until they are actually needed, uh, which can significantly improve the initial load times. Uh, then we can optimize the images with the next slash image. The next slash image component automatically optimizes the image for load times and performance. This also support lazy loading, uh, by default. Uh, then, uh, this majorly ensures that images are only loaded when they are needed or when they enter the viewport. That is the major part of it. Then we can conditionally loading the components based on the platform. Uh, for shared components that have different importance or relevance across platforms, we can consider conditional loading based on the platform, whatever components is required. And whenever we have shared code bases, there are 2 things to be considered, which is we should have shared business logic. Uh, we should isolate the business logic state management, and I will be able to function the shared files or packages that don't rely on the platform specific APIs or components. And we should abstract platform specific implementations as well. And, uh, we can pretty much rely on the environment deduction functionality of Next. Js or React Native, uh, and we can use polyfills wherever necessary. So these will, um, uh, help in, uh, this as well. And at the end, we have to have proper performance monitoring and analysis tools in place, like maybe Lighthouse or Webpage test and React Native performance tools as well. So by, uh, these techniques, we can apply lazy loading. And by considering the unique aspects of each platform with a shared code base, we can significantly enhance user experience and performance on mobile apps as well. With Next. Js as well as, uh, we can maintain the efficiency using, uh, the React Native as well.

given this react native function there seems to be a performance issue when updating the state can you explain what's causing the performance problem and how you might resolve it so there is a count set count use state which for let i equal to 0 i less than pi i plus plus and we are set inside the loop there's a set count of previous count equals previous count plus 1 okay so I think the performance issue in this scenario is how state updates are being handled within a loop when we use something called something like set count of previous count plus 1 inside a loop react batches these updates together when they occur in event handlers or life cycle methods for performance reasons however because we are using we are basing each update on the previous state each call to set count doesn't immediately execute instead it schedules an update to the state when react eventually processes these updates they all essentially use the same initial state and apply their updates based on it causing redundant re-renders and not achieving the intended result effectively efficiently so in this case I'm trying to increment I think we are trying to increment the count state by one five times in a loop right however due to the asynchronous nature of state setters in react and the batching behavior of react this might not see though we might not see the increments happen as we expect if we rely on the previous state within the loop so each iteration of the loop doesn't see the increment from the previous iteration at all because the state updates are asynchronous and batched so how to resolve it so the key to resolving this issue is to avoid setting state in a loop directly instead calculate the new state we want to set based on the loop and then send the state a single time with the final value this reduces the number of re-renders and ensures that the state updates are more efficient the solution would be so we can use something called a set count of previous count equals previous count plus 5 directly if the increment so this is the general best practice I would say if the goal is to increment the count by just one five times we can do this calculation outside the state setter function and operate the state once by how whatever however I mentioned it earlier but if the increment amount or logic is more complex and depends on each iteration of the loop we would calculate the total change first then apply it once so this approach significantly improves performance by reducing the number of re-renders and ensuring that the state is updated correctly in a single operation

This code is a part of Next. Js application. Despite being functional, it might not follow best practices regarding the solid principles, which principle is at risk and how you might improve the code. So there's a code, const to fetch data, e asynch off, const data equal await fetch/apis/data.const to JSON equal await data dot JSON. Render the data here, implement logic here, error handling here. Okay. So I think the provider, the the pseudo code for an access application illustrates a function that seemingly handles fetching data, converting it to JSON, rendering, implementing some logic, and error handling all within a single async function. Uh, although it's functional, this design, um, violate, uh, like, violate the single responsibility principle, which is the SRP principle, I would say. Uh, let's look at the issue. The function appears to violate this, violate the SRP principle, which states that, uh, module class or function should have one and and only one reason to change. But the code provider indicates that the function is responsible for everything, which is fetching data, processing the data, rendering business logic, and error handling as well. So how to improve it? In terms, we can refactor these into separate functions. Uh, to add it to the single responsibility principle, we can refactor the code into separate functions, each with a a single responsibility. So maybe we can have something called a fetch data function. So that function is only for fetching data from from an API. We can have something called process or transforms the data function. Uh, then we should have a separate render data function. Uh, then we should have an a error handler function as well. We can use everything together. After defining the above mentioned functions, we can compose them in a more structured way where each function is called when appropriate and error handling is more centralized here. Like, we can have something called, uh, async function handle fetch and render. Inside that, we'll have a try catch block. So we can, uh, inside the try block, we can fetch the data. We can process the data. We can render the data by triggering each and every specific functions. And in the catch block, we can have the error handler. So by following this approach, this not only makes the code more maintainable, uh, by, uh, uh, completely following the SRP principle, but also improves the readability and which just makes it easier to test and, uh, test each function separately.

How would you troubleshoot and resolve persistent memory leaks in a React Native mobile app that is part of a 3 in 1 repository including Next.js? So, yeah troubleshooting and resolving persistent memory leaks in a React Native mobile app. So, as you mentioned it is already a part of a 3 in 1 repository which also includes Next.js. So, here we should identify, isolate and fix the leaks, right. So, maybe first step is to identify the memory leak. So, we can use some profiling tools to monitor the app's memory usage first. For React Native, we can use tools like React Developer Tools or Android Studio's Profiler or Xcoach instruments which can help identify memory leaks. We can look for steadily increasing memory usage that doesn't decrease even when expected like after leaving a screen, right. We can, if the React Native app targets Android, Leak Canary is a useful tool for detecting memory leaks. It automatically notifies us of memory leakages after screen rotations or when the app gets into background. Then we can isolate the leak source. So, we can start by examining components that persist throughout the app's life such as the navigation, global state managers or long-living singletons. We can use profiling data to guide us towards components that might be the source of the leaks. We can review the lifecycle methods as well. We can check for the global eventlessness and the subscriptions where it happens. If we are, since our repository includes Next.js application as well, right, so we should review the shared repository or the shared utilities files or the services we are using that might be common across both the web and the mobile platforms, right, because more probably there we have to check the subscriptions wherever the memory leak happens. And once we find it, we will be fixing the lifecycle, we will be resolving the leaks like we will be fixing the lifecycle issues, we will be optimizing the state management and the context and we should look into the memory leak patterns in the shared code. So once we resolve it, we should make sure it's not repeating again, right, we should have a continuous monitoring and testing practices in place as well. So by this, we can systematically identify, fix, address and by fostering a proper development culture which aware of the performance-based practices, we can significantly mitigate these memory related issues in the React Native app, even within a multi-platform repository.

Given your experience with various development platforms, what alternative to the Xpo platform would you suggest for mobile features integration and why? Yeah. So I would say, uh, we can use some, uh, instead of expert, we can use something called the React Native CLI. Right? This is this has the direct integration with the native code. So this React Native CLI provides flexibility to integrate directly with the native code. Uh, so if that is the case, we don't have to, like it requires custom radio models or the use of third party radio library is not supported with the expo. And, uh, we have wider package combinations. There are no expo, SDK limitation. Developers have broader access to the entire React Native ecosystem if we use the React Native CLI, the the OG CI. Right? And, uh, we there are performance consideration as well because by we are avoiding an extra expo layer on top of the React Native app. Our app will become slightly better, uh, efficient. Uh, it has better will have better performance because we are removing an extra expo layer on top of it. Um, so but we have to consider a few things before moving to it, uh, moving away from expo. Uh, first is the initial setup and configuration. If you have set up already the see, the actual CLI setup requires more, uh, uh, initial and initial configurations than x four. And the build and deployment complexity also we should, uh, consider because x four's managed services, uh, handles the more aspects of the developer side. If you're going we're going out with the CLI, we should take, uh, more into it. The learning curve is also steeper for the CLI. We can consider other alternatives, like, we can use Flutter, uh, which is done by Google, I think. Uh, it's a strong computer to be active. We can go ahead with, uh, their suite of products. It uses Dart instead of JavaScript as based language. And we can consider something something which is the native development as well, which is you can use Swift for iOS and Android Studio, Kotlin or Java for Android. Uh, we can do that. But everything, it depends on the project's requirements and the complexity of the project and what exactly, uh, is expected out of the project.

Can you share a specific experience where you had to handle cross platform layouts and styling issues between the web and mobile interfaces using NixJS and a React Native? Yeah. So, yeah I have faced a similar issue once in my experience. So, which is, let's say, so I'll give you an example for that. Let's say the project goal is to develop a product catalog feature that needs to be consistent across web and mobile platforms. The interface, which should include a grid of products, each product displayed in a cart with an image, title, price, and a buy button, right? So the challenges faced, what are the challenges I faced are the responsive layout, because the web version uses CSS grid to display products in a multi-column layout that are just based on the screen size. But React Native, however, does not support CSS grid. It uses flexboxes or layout. And the styling consistency. CSS for web app and the styling approach in React Native have different syntax and capabilities. For instance, let's say the power states common in web interfaces need alternative interactions used in the mobile app, right? Let's say the web version benefits from NixJS image component for optimized loading. React Native requires different strategies for efficient image handling. So these are the specific experience I have, like the cross-platform layouts and styling issues I faced. So what are the approaches I used to address these challenges? Let's say the first one is the adopting a flexible layout system. For the web, continued use of CSS grid with media queries to adapt the layout for different screen sizes. For mobile, use flexboxes to achieve a similar responsive grid layout. In unified, if you use a unified styling solution, let's say I've introduced a design system that defines common design tokens like colors, spacing, topography in a platform agnostic way. For instance, we can use something called JavaScript objects that can be interpreted by both the platforms, the JSONs like. So we can use something called style components for the web and style components for React Native also to implement the same similar style. For handling images for web, we can use NixJS image for optimized image loading. For mobile, we can use something called fast image library for React Native. Then platform-specific code branching, we have the .native.js for React Native and .js for the NixJS. We can write the platform model to different code paths and to separate it from the major code logic. One of the lessons I've learned is a design system is key. You should have a proper design system in place, well-defined one. And we should have a separate plan for platform specifics. We should leverage the community solutions like the style components like that. And we should have a continuous testing in place. So by this way, we can mitigate all the issues by handling the cross-platform layout and styling issues.