Audit by **Umer Javed**

1: **ISSUE:** Wrong way to load Fonts **[Low]**

**Description issue**: some it loads fonts and some it just return null beacuse of you check it make rendering issues

**Part code:** (App.tsx line 32 to 43)

**Recommendation :** The Best practive to handle it will a funtion that return a promise that it was resolved or rejected if it was resolved then it will excute the setReady function it will unitl the promise is resolved or rejected

**2: ISSUE**: Redundant theme definition **[Low]**

**Description issue:** There is a redundant theme definition inside the App component. The theme is initially defined as const theme = extendTheme({ config }); at the beginning of the file, and then redefined inside the App component using const theme = extendTheme({ ... });.

**Part code:** (App.tsx line 50 to 66)

**Recommendation :** Remove the redundant theme definition inside the App component. You can use the initial theme defined at the beginning of the file.

**3: ISSUE:** Unused variable theme **[Low]**

**Description issue:** The theme variable is defined twice in the App component, once as a constant at the beginning of the file and once as a variable inside the component.

**Part code:** (App.tsx line 18, 67)

**Recommendation :** Remove the theme variable definition inside the App component. The theme is already defined globally.

**4: ISSUE:** Redundant code in the useEffect hook **[Low]**

**Description issue:** The loadAssets function is unnecessary for checking if the app is ready. The setIsReady(true) is always called regardless of the asynchronous function result.

**Part code:** (App.tsx line 21 to 29)

**Recommendation :** Remove the loadAssets function and directly set setIsReady(true)

**5: ISSUE:** Unused import for StartingScreen **[Low]**

**Description issue:** The StartingScreen component is imported at the beginning of the file but not used in the App component.

**Part code:** (App.tsx line 3)

**Recommendation :** Remove the import statement for StartingScreen if it is not used in the App component

**6: ISSUE:** Global State Management in a Component **[Medium]**

**Description issue:** The onAuthStateChanged listener is directly placed in the AuthNavigator component. It might be more appropriate to handle this global state management, such as user authentication, outside of the component itself. This can lead to cleaner code organization.

**Part code:** (AuthNavigator.tsx line 32 to 38)

**Recommendation:** Move the onAuthStateChanged logic to a more centralized location, possibly in a Redux middleware or a dedicated service for user authentication. Keeping components focused on rendering UI and delegating global state management to dedicated modules enhances code maintainability.

**7: ISSUE:** Redundant else block **[Low]**

**Description issue:** The else block after the first return statement is not necessary. Since the first return terminates the function, the subsequent code in the else block is not reachable.

**Part code:** (AuthNavigator.tsx line 75 to 100)

**Recommendation:** Remove the else block and directly return the JSX after the first return statement.

**8: ISSUE**: Simplify tabBarButton Logic **[Medium]**

**Description issue:** The logic for rendering the tab bar button could be simplified by extracting it into a separate component or function.

**Part code:** (BottomTabNavigator.tsx line 87 to 101)

**Recommendation:** Create a separate component or function for rendering the tab bar button. This can make the main component's JSX cleaner and more focused on defining the tab navigator.

**9: ISSUE:** Complex tabBarButton Logic Inside Main Component **[Medium]**

**Description issue:** The logic for rendering the tab bar button is relatively complex and directly placed within the screenOptions prop. Extracting this logic into a separate component or function can enhance the main component's readability.

**Part code:** (BottomTabNavigator.tsx line 87 to 101)

**Recommendation:** Create a separate component or function for rendering the tab bar button. This can make the main component's JSX cleaner and more focused on defining the tab navigator.

**10: ISSUE:** Logic for Handling Tooltip Visibility Inside Main Component **[Medium]**

**Description issue:** The logic for handling the tooltip's visibility (toggleTooltip) is placed directly within the BottomTabNavigator component. This can potentially clutter the main component with functionality that could be isolated.

**Part code:** (BottomTabNavigator.tsx line 13 to 29)

**Recommendation:** Create a custom hook, for example, useTooltip, that includes the state and logic related to the tooltip's visibility. This can help isolate the tooltip functionality, making the main component cleaner and more focused on rendering.

**11: ISSUE:** Inline Styling and Cluttered JSX **[Medium]**

**Description issue:** The JSX structure of the Home component includes inline styling and is somewhat cluttered, which may affect readability and maintainability.

**Part code:** (Home.tsx)

**Recommendation:**

Extract the inline styles into a separate style object or a style sheet to keep the JSX clean and improve readability.
Consider breaking down the component into smaller, focused components to enhance maintainability and organization.

**12: ISSUE:** Redundant useEffect and State Management **[Critical]**

**Description issue:** The useEffect hook is used to fetch user data from Firebase and update the state. However, there seems to be redundant state (UserData) and rendering logic that might not be necessary.

**Part code:** (Home.tsx, lines 36-55)

**Recommendation:** Simplify the logic by fetching user data directly where it's needed without storing it in a state variable unless there's a specific reason for doing so. Avoid unnecessary re-renders caused by state changes if not required.

**13: ISSUE:** Hardcoded Language Check **[Critical]**

**Description issue:** There's a hardcoded language check (i18next.language === 'ar') for styling decisions and layout direction. While this might be necessary in some cases, consider using NativeBase's built-in support for RTL layouts to simplify this logic.

**Part code:** (Home.tsx, various locations)

**Recommendation:** Leverage NativeBase's support for RTL layouts instead of manually checking the language for styling decisions.

**14: ISSUE:** Redundant useEffect and State Management **[Medium]**

**Description issue:** The useEffect hook is used to fetch user data from Firebase and update the state. However, there seems to be redundant state (UserData) and rendering logic that might not be necessary.

**Part code:** (Home.tsx, lines 36-55)

Recommendation: Simplify the logic by fetching user data directly where it's needed without storing it in a state variable unless there's a specific reason for doing so. Avoid unnecessary re-renders caused by state changes if not required.

**15: ISSUE:** Hardcoded Language Check [Medium]

**Description issue:** There's a hardcoded language check (i18next.language === 'ar') for styling decisions and layout direction. While this might be necessary in some cases, consider using NativeBase's built-in support for RTL layouts to simplify this logic.

**Part code: **(Home.tsx, various locations)

Recommendation: Leverage NativeBase's support for RTL layouts instead of manually checking the language for styling decisions.

**16: ISSUE:** Redundant Delay for Logout Modal **[Medium]**

**Description issue:** There's a redundant delay of 100 milliseconds (setTimeout(() => { setLogout(true); }, 100);) before setting the logout state to true. This delay doesn't seem necessary and might be a potential source of confusion.

**Part code:** (Home.tsx, line 54)

**Recommendation:** Remove the unnecessary timeout delay unless there's a specific reason for it.

**17: ISSUE:** Component Modularization and Separation of Concerns **[Critical]**

**Description issue:** Consider breaking down the Home component into smaller, focused components. Each component can be responsible for a specific part of the UI or functionality. This will make the codebase more modular, easier to understand, and maintain.

**Recommendation:**
Identify logical sections or features within the Home component.
Create separate components for each identified section or feature.
Pass props to child components to share data and functions.
Utilize functions or hooks to handle specific functionalities.
Use meaningful names for components to convey their purpose.

**18: ISSUE:** Excessive useEffects Causing Re-renders **[Critical]**

**Description issue:** The component has a high number of useEffect hooks, which may lead to excessive re-renders and impact performance. Each useEffect listens to different dependencies, potentially causing unnecessary rendering cycles.

**Part code:** (NewCalendar.tsx, lines 93-205)

**Recommendation:** Review the necessity of each useEffect and consider optimizing the component's lifecycle. Combine related state updates into a single useEffect where possible, and carefully choose dependencies to prevent unintended re-renders. This can help maintain a more efficient rendering process and improve overall performance.

**19: ISSUE:** Complex Firebase Logic Within Component **[Critical]**

**Description issue:** The component NewCalendar.tsx contains complex Firebase logic, including fetching and updating data. This logic could be extracted into separate functions or components to improve code readability, maintainability, and facilitate easier testing.

**Part code:** (NewCalendar.tsx, lines 31-203)

**Recommendation:** Create separate functions or components for Firebase-related logic. For example, move the Firebase-related functions (fetTickets, getPermission, uriToBlob, submitData) into a dedicated file or helper functions. This separation of concerns will enhance code organization, make it easier to understand, and allow for better testing and maintenance. It's a good practice to keep components focused on rendering and user interaction while delegating data logic to other modules.

**20: ISSUE:** Complex Code too much Long **[Critical]**

**Description issue:** Complex Code too much Long around 1360 lines not possible to understand This logic

**Part code:** (NewCalendar.tsx, )

**Recommendation:** Complex Code too much Long around 1360 lines not possible to understand This logic could be extracted into separate components to improve code readability, maintainability, and facilitate easier testing.

**21: ISSUE:** Complex Component with Inline Styles **[Critical]**

**Description issue:** The ClubDetails.tsx component contains complex styling logic with inline styles and a mix of native-base and React Native components. While inline styles can be effective, in this case, the styling logic might benefit from external style sheets for better readability and maintainability.

**Part code:** (ClubDetails.tsx, lines 1-217)

**Recommendation:** Consider externalizing the styling logic into a separate style sheet using StyleSheet.create from React Native. This will make the code more organized, easier to read, and maintain. Additionally, having a separate style sheet allows for better reusability of styles across multiple components.

**22: ISSUE:** Repeated Code Blocks **[Medium]**

**Description issue**: There are repeated code blocks for rendering tags and activities in the component ClubDetails.tsx. These blocks could be extracted into separate functions to improve code readability and maintainability.

**Part code:** (ClubDetails.tsx, lines 52-60, 72-80, 92-100)

**Recommendation:** Consider creating separate functions for rendering tags and activities, and then call these functions in the component's render method to reduce redundancy.

**23: Issue:** Combine Similar Code Blocks for Private and Public Radio **[Medium]**

**Description issue:**
In the NewClub component, there are separate code blocks for handling private and public radio buttons. These blocks are very similar and can be combined to improve code readability.

**Recommendation:**
Combine the code blocks for private and public radio buttons to eliminate redundancy and improve maintainability.

**24: Issue:** There are so many Firebase Function in the Page **[Critical]**

**Description issue:**
There are so many Firebase Function in the Page that will cause unnecassary re-renders and readeability issues

**Recommendation:**
Seperate them to increase readeability, maintainance, avoid code complexity and make it the page to render fast as possible

**25: ISSUE:** Complex Code too much Long **[Critical]**

**Description issue:** Complex Code too much Long around 1360 lines not possible to understand This logic

**Part code:** (NewClub.tsx, )

**Recommendation:** Complex Code too much Long around 1360 lines not possible to understand This logic could be extracted into separate components to improve code readability, maintainability, and facilitate easier testing.

**26: Issue** Ambiguous Variable Name fromDatas **[Medium]**

**Part code:** (CreateCircle.txs)

**Description issue:**
The interface fromDatas is used to define the type of the formData state in the CreateCircle component. The name fromDatas is ambiguous and does not clearly convey the purpose of the interface.

**Recommendation:**
Consider renaming the fromDatas interface to a more descriptive and meaningful name, such as FormData.

**27: Issue:** Modularize Code **[Critical]**

**Description issue:**
Break down the component into smaller, focused functions to improve readability and maintainability.

**Part code:** (CreateCircle.txs)

**Recommendation:**
Separate the logic into smaller functions focusing on specific responsibilities.

**28: Issue:** So Much Mapping in Code **[Medium]**

**Description issue:**
Break down the component into smaller, focused functions to improve readability and maintainability.

**Part code:** (CreateCircle.txs)

**Recommendation:**
Separate the logic into smaller functions focusing on specific responsibilities.

**29: Issue:** Inconsistent Use of useEffect Dependencies **[Critical]**

**Description issue:**
The dependency arrays in useEffect hooks are inconsistent. Consistency in dependencies enhances the comprehensibility of the code.

**Part code:** (EditProfile.tsx)

**Recommendation:**
Ensure that the dependency arrays in useEffect hooks are consistent for improved code clarity.

**30: Issue:** Catogories InLine Mapping **[Medium]**

**Description issue:**
Catogories InLine Mapping make the code complex and cause re-renders

**Part code:** (NewAdvertise.tsx line 85 to 89)

**Recommendation:**
Make the that mapping card into seperate component

**31: Issue:** ActivityData InLine Mapping **[Medium]**

**Description issue:**
ActivityData InLine Mapping make the code complex and cause re-renders

**Part code:** (ActivityDetails.tsx line 127 to 142)

**Recommendation:**
Make the that mapping card into seperate component

**32: Issue:** Redundant Styling in DatePicker Task Section **[Low]**

**Description issue:**
In the DatePickerTask component, there might be redundant styling properties like _dark and _light as they are already applied in the parent component. Cleaning up redundant styling will improve code consistency.

**Recommendation:**
Remove redundant styling properties (such as _dark and _light) in the DatePickerTask component to maintain consistent styling.

**33: Issue:** Inconsistent Naming Convention for Function **[Low]**

**Description issue:**
There's a function named handleMemberPress, which follows the camelCase naming convention. To maintain consistency, consider renaming it to handleMemberSelection or another consistent naming convention.

**Recommendation:**
Rename the function to handleMemberSelection or another convention for consistency.

**34: Issue:** Redundant Key Extractor Functions **[Medium]**

**Description issue:**
Redundant Key Extractor Functions extra variables

**Part of Code:**
In the MyTasks component, there are two key extractor functions (keyExtractor and keyExtractor1) defined for the FlatList components.

**Recommendation:**
Remove one of the key extractor functions to avoid redundancy. Use a single key extractor function for both FlatList components.

**35: Issue:** Unnecessary Emoji Picker Rendering **[Medium]**

**Description issue:** The presence of a + sign before the expression checking isEmojiPickerOpen may lead to unexpected behavior in rendering the EmojiSelector.

**Part Code:** (ChatScreen.tsx)

Recommendation: Correct the expression to conditionally render the EmojiSelector when the state is true without the + sign.

**SUGGESTIONS:**

**Use Cli instead of Expo:**
We will use React Native CLI that provides a scalable architecture that accommodates the growth of our application. It seamlessly integrates with native modules, allowing us to leverage platform-specific features and maintain a consistent user experience across different devices than Expo
**1:**
React Native CLI seamlessly integrates with CI/CD pipelines, streamlining the development workflow. This is important for automated testing, continuous integration, and efficient deployment processes, ensuring a more reliable and consistent release cycle.
**2:**
React Native CLI ensures a consistent development environment across both iOS and Android platforms. This consistency simplifies debugging, testing, and deployment processes, reducing the likelihood of platform-specific issues.

**Enterprise-Grade Security:**
React Native CLI, along with GraphQL, allows us to implement enterprise-grade security measures. GraphQL supports fine-grained access control, enabling you to define precisely what data clients can access, thus enhancing the security of your application.

**Use GraphQL over Firebase:**
We will use GraphQL that offers a superior alternative to Firebase for enhancing app performance. Unlike traditional REST APIs, GraphQL allows us to request only the data needed for a specific view, minimizing unnecessary data transfer and optimizing network usage. This granular control over data fetching results in faster response times and a more efficient use of resources,

**1:**
In scenarios where data needs to be aggregated from multiple sources or services, GraphQL simplifies the process. It allows you to consolidate data from various backends into a single query, reducing the complexity of data aggregation on the client side.
**2:**
GraphQL has a large and vibrant community with a wealth of resources, libraries, and tools. This ensures ongoing support, continuous improvement, and a robust ecosystem that can contribute to the success and longevity of your project.

**Reduced the Overhead:**

With Firebase, the data structure is predefined, and retrieving data often involves fetching more than needed. GraphQL's dynamic querying allows you to request only the required data, reducing unnecessary data transfer and improving app responsiveness.

**Client-Specific Data Loading:**
GraphQL enables clients to specify exactly what data they need, allowing for client-specific data loading. This is particularly useful in mobile applications, where bandwidth and data usage are critical factors.

**Use Component Based Work:**
We will use a component-based architecture that enhances the reliability and maintainability of our codebase. Each UI element and functionality is encapsulated within modular components, promoting reusability and easing collaboration among team members. This approach accelerates development cycles, reduces bugs, and ensures a consistent and cohesive user interface across the entire application.

**Time Need For Production:**
3 Months Atleast