How ahmedshaban-blip/enjezmobileappversion works
1. Overall shape
- This is a React Native + Expo mobile app with a classic layered structure: entry files at the root, shared infrastructure in src/config, global state in src/context and src/hooks, navigation in src/navigation, feature screens in src/pages, and reusable UI in src/components.
2. App bootstrap
- index.js and App.js are the root entry points.
- They likely initialize the app shell, mount global providers, and hand control to the navigation layer.
- app.json, eas.json, Babel, Tailwind/NativeWind, and Expo config files shape build/runtime behavior rather than business logic.
3. Navigation and route boundaries
- The app is split into auth, client, and admin areas.
- src/navigation/UserDrawer.jsx suggests a drawer-based shell for signed-in users.
- src/components/layout/ProtectedRoute.jsx indicates route gating based on authentication/role, so navigation is the main boundary between public and protected flows.
4. Authentication and session state
- src/hooks/AuthContext.jsx and src/hooks/useAuth.js manage auth state and expose it to screens.
- src/context/LoadingContext.jsx handles app-wide loading state.
- Auth drives access to the client and admin sections, and likely controls whether the app shows login/signup, a splash/loading state, or the main drawer experience.
5. Backend/data layer
- src/config/firebase.js is the main backend bootstrap and aligns with the README’s Firebase Auth + Firestore architecture.
- src/utils/firebaseHelpers.js centralizes Firebase read/write logic so screens/components do not talk to Firebase directly.
- src/config/supabase.js exists as a secondary backend config, but from the tree alone it looks auxiliary or legacy rather than the primary datastore.
6. Domain modules: client experience
- src/pages/client/* contains the user-facing product flow: home, services, service details, booking, booking details, confirmation, profile, about/contact, and “how it works.”
- src/components/client/* provides screen-specific building blocks such as headers, hero sections, categories, popular services, booking items, and service detail panels.
- This is the core browse → inspect → book → track lifecycle.
7. Domain modules: admin experience
- src/pages/admin/* contains operational screens: dashboard, add service, and agent bookings.
- This is a separate control plane from the client flow, intended for managing listings and booking operations.
- In an architecture diagram, this should be shown as a distinct role-based branch off the authenticated app.
8. Shared UI and composition
- src/components/common/* holds reusable features that span multiple screens: auth card, booking form, service card, chatbot, logo/header, and loading spinner.
- src/components/ui/* contains low-level primitives like Button and Input, which are likely used throughout the app.
- src/components/layout/* provides shell-level pieces such as auth layout, navbar, sidebar, and protected-route wrappers.
9. Booking and commerce flow
- The booking process is encapsulated in BookingForm, BookingItem, booking pages, and confirmation pages.
- The README mentions PayPal via WebView and an offline payment option, so payment is an external step inside the booking pipeline rather than a separate backend service in this repo.
- Booking status management appears to be a key data model: pending, confirmed, completed, and cancellation.
10. Recommendations and personalization
- src/components/client/RecommendationSection.jsx and the README’s “Picked Just for You” feature indicate personalized service ranking.
- This likely reads from booking history via Firebase and surfaces recommended services on the home screen.
- The recommendation logic appears to be a UI-facing feature backed by app data rather than a separate service.
11. AI and notifications
- src/utils/aiService.js and src/components/common/Chatbot.jsx show an AI-assisted support or discovery feature.
- src/config/notificationService.js suggests push/local notification integration for booking or status updates.
- These are cross-cutting integrations that sit beside the main booking and auth flow.
12. Design system and styling
- The app uses NativeWind/Tailwind-style utility classes, plus React Native Expo components and likely React Native Paper based on the README.
- tailwind.config.js and nativewind.config.js define the styling system, while assets/ supplies logos and screenshots.
- This means UI composition is utility-driven rather than heavily bespoke per screen.
13. Primary end-to-end data flow
- A user starts at the splash/auth layer, authenticates through Firebase, enters the role-appropriate navigation shell, browses services, opens details, creates a booking, and then tracks/cancels that booking from the client area.
- Admin users follow a parallel authenticated path to manage services and inspect bookings.
- Most state changes ultimately flow through the Firebase helper/config layer, with contexts coordinating loading/auth UI state.
14. What to show in an architecture diagram
- Show three top-level zones: public/auth, client app, admin app.
- Put contexts/hooks as cross-cutting services feeding both app zones.
- Put Firebase/Firestore/Auth as the primary backend dependency, with PayPal WebView, notifications, and AI/chatbot as secondary integrations.
- Keep components/layout/ui as the presentation layer under each screen group, not as separate business subsystems.
Main entry points: App.js App.js · client Client home · common Common UI · firebaseHelpers.js Firebase helpers
Components 20
Public/Auth
Entry, splash, and authentication flow before protected app areas.
- index.js · Native app entrypoint.
index.js - App.js · Root application bootstrap and provider setup.
App.js - SplashScreen · Initial loading or splash screen.
src/components/SplashScreen.jsx - Login/Signup · Public authentication screens for sign-in and account creation.
src/pages/auth
Client App
End-user browsing, booking, profile, and tracking experience.
- Client home · Home, services, details, booking, profile, and informational screens.
src/pages/client - Client UI · Screen-specific components for browsing and booking flows.
src/components/client
Admin App
Operational screens for managing services and bookings.
- Admin tools · Dashboard, service management, and booking oversight for operators.
src/pages/admin
Shared App Layer
Reusable layout, state, hooks, and UI primitives used across flows.
- Auth state · Authentication state and session exposure to the app.
src/hooks/AuthContext.jsx - Loading state · Global loading coordination for app-wide busy states.
src/context/LoadingContext.jsx - ProtectedRoute · Role and auth gating for protected navigation.
src/components/layout/ProtectedRoute.jsx - UserDrawer · Drawer-based navigation shell for signed-in users.
src/navigation/UserDrawer.jsx - Booking form · Shared booking capture and submission component.
src/components/common/BookingForm.jsx - Common UI · Reusable app-wide UI such as auth cards, cards, chatbot, headers, and spinners.
src/components/common - Layout UI · App shell pieces such as navbar, sidebar, auth layout, and protected wrapper.
src/components/layout - Styling · Tailwind/NativeWind configuration and utility-based styling layer.
tailwind.config.js
Backend
Primary data and backend integration layer.
- Firebase · Primary auth and Firestore backend bootstrap.
src/config/firebase.js - Firebase helpers · Centralized read/write helpers around Firebase operations.
src/utils/firebaseHelpers.js - Supabase · Auxiliary or legacy backend configuration.
src/config/supabase.js
Integrations
Secondary services and external capabilities alongside the core backend.
- Notifications · Push or local notification service for booking updates.
src/config/notificationService.js - AI service · AI-assisted support or discovery logic used by chatbot features.
src/utils/aiService.js
Connections 24
- index.js → App.js: boots · Native entry starts the root app.
- App.js → SplashScreen: shows · App may begin with splash/loading experience.
- App.js → Auth state: provides · Root bootstrap wires authentication state.
- App.js → Loading state: provides · Root bootstrap wires global loading state.
- App.js → UserDrawer: routes to · Authenticated users enter the main navigation shell.
- Login/Signup → Auth state: updates · Login and signup mutate session state.
- ProtectedRoute → Auth state: checks · Route guard reads auth and role state.
- UserDrawer → ProtectedRoute: wraps · Signed-in shell sits behind protected access.
- UserDrawer → Client home: navigates · Drawer exposes client screens.
- UserDrawer → Admin tools: navigates · Role-based branch to admin screens.
- Client home → Client UI: uses · Client screens compose dedicated UI blocks.
- Client home → Booking form: books · Booking flow submits through shared booking form.
- Client home → Common UI: uses · Client screens reuse common UI elements.
- Admin tools → Common UI: uses · Admin screens reuse shared UI components.
- Admin tools → Firebase helpers: manages data · Admin flows operate through centralized backend helpers.
- Booking form → Firebase helpers: writes · Booking submissions persist through helper layer.
- Client home → Firebase helpers: reads · Client listings, profiles, and bookings read from backend helpers.
- Firebase helpers → Firebase: calls · Helpers delegate to Firebase services.
- Firebase helpers → Supabase: optional · Secondary backend config exists alongside Firebase.
- Common UI → AI service: chat support · Chatbot and support UI can invoke AI features.
- Common UI → Notifications: status alerts · Shared features may trigger booking notifications.
- Layout UI → Styling: styled by · Layout and shell components use utility styling.
- Client UI → Styling: styled by · Client-facing UI follows the shared design system.
- Common UI → Styling: styled by · Reusable components rely on the same styling layer.