How jackbaum33/we-wrappers-app-codebase works
1. Overall shape
- This is a React Native + Expo mobile app for social accountability around daily tefillin wrapping.
- The main architecture is a thin mobile client backed by Firebase services, with an additional serverless functions layer and a small admin panel entry point.
2. Application entry and runtime boundary
- The top-level runtime starts from App.tsx and index.js, with app configuration in app.config.js and Expo build settings in eas.json.
- The README describes Expo Router-style routes, but the actual tree also shows a src/navigation layer, so the architecture should be drawn as a client-side navigation shell that resolves authenticated vs unauthenticated flows.
3. Navigation and auth gating
- src/navigation/AuthNavigator.tsx and MainNavigator.tsx divide the app into two major user states:
- unauthenticated entry into welcome/sign-in/sign-up
- authenticated access into the main app
- The auth boundary is driven by Firebase auth state and user context, not by a backend session layer.
4. Global state and cross-screen coordination
- src/context/UserContext.tsx centralizes the current user profile, auth-dependent data, and likely app bootstrap state.
- src/context/RefreshContext.tsx suggests a lightweight cross-screen refresh trigger used to sync screens after writes such as wrap submissions, profile edits, or notification changes.
5. Feature screens as the main UI surface
- src/screens contains the functional areas of the app:
- onboarding/auth: Welcome, SignIn, SignUp, Splash
- core activity: Home, Wrap, Streak, Progress, Activity
- social: Friends, Chats, Chat, Groups, PostFeed, Post, Profile, UserProfile
- competition/accountability: Bracket*, ChainDetail, BrowseBrackets, Compete, Leaderboard
- settings: ProfileSettings, SocialsSettings, NotificationsSettings
- These screens are the primary boundary between user interaction and Firebase data operations.
6. Shared UI components
- src/components contains reusable presentation and modal layers:
- BracketTree for bracket visualization
- StreakCalendar for streak history
- NotificationsModal, UpdateModal, WhatsNewModal for overlays and app lifecycle prompts
- ErrorBoundary for rendering fault isolation
- These components are likely reused across several screens rather than owning data themselves.
7. Firebase client layer
- src/firebase is the application’s data-access boundary.
- It is split by domain: auth, wraps, brackets, chains, chats, friends, holidays, notifications, plus config.
- This is where the app talks to Firebase services such as Auth, Firestore, and Storage, keeping screen components from directly coupling to backend APIs.
8. Data domains and likely flows
- The README describes the core user data model around users, with streak counters and wrap totals.
- The Firebase modules imply distinct collections or document groups for:
- user identity/profile
- wrap submissions
- streak and progress tracking
- social relationships and chats
- chains and brackets for accountability/competition
- notifications and holiday metadata
- The main read/write flow is: screen → firebase module → Firestore/Storage → context refresh → UI update.
9. Media upload path
- The wrap feature likely includes photo capture or selection on-device, then upload to Firebase Storage under a user-scoped path.
- Firestore appears to hold the metadata and counters, while Storage holds the actual image assets.
- This split is important for architecture diagrams because the app uses both a structured data store and an object store.
10. Serverless backend
- functions/index.js indicates a Firebase Cloud Functions backend.
- This layer is probably used for privileged tasks such as notifications, derived updates, moderation/admin actions, or scheduled bookkeeping that should not run on-device.
- It is the main backend boundary separate from the mobile client’s direct Firebase access.
11. Admin surface
- admin_panel.html suggests an auxiliary web-based admin interface.
- This is not part of the main mobile user flow, but it is an important operational boundary for management tasks and likely interacts with the same Firebase backend.
12. Assets and presentation
- assets/ contains static app assets such as icons, images, or splash resources.
- These support the Expo app shell and are separate from user-generated wrap images stored in Firebase Storage.
13. Security and deployment assumptions
- The README’s Firestore and Storage rules show a per-user authorization model: users can write their own user doc and upload their own wraps.
- That means the architecture is strongly centered on Firebase security rules rather than a custom API gateway.
- Deployment/runtime is Expo-managed for the client, Firebase-managed for backend data, auth, storage, and serverless execution.
14. How to draw the diagram
- The simplest accurate diagram is:
- Mobile app shell
- auth/navigation
- feature screens
- shared components
- app state contexts
- Firebase client layer
- auth, firestore, storage access modules by domain
- Firebase services
- Auth, Firestore, Storage
- Cloud Functions
- server-side automation and privileged workflows
- Admin panel
- separate operational interface
- The key boundary is between user-facing screens and the Firebase-backed domain/data layer.
Main entry points: screens Screens · MainNavigator.tsx Main flow · wraps.ts Wraps API · config.ts Firebase config
Components 18
Mobile app
Expo React Native client shell, navigation, screens, shared UI, and local state.
- App shell · Top-level Expo app entry and runtime bootstrap.
we-wrappers-fresh/App.tsx - Navigation · Routes between unauthenticated and authenticated app states.
we-wrappers-fresh/src/navigation - Auth flow · Welcome, sign-in, and sign-up entry path.
we-wrappers-fresh/src/navigation/AuthNavigator.tsx - Main flow · Primary authenticated navigation stack.
we-wrappers-fresh/src/navigation/MainNavigator.tsx - User state · Current user profile and auth-dependent bootstrap state.
we-wrappers-fresh/src/context/UserContext.tsx - Refresh state · Cross-screen refresh trigger after writes and updates.
we-wrappers-fresh/src/context/RefreshContext.tsx - Screens · Primary user-facing features: onboarding, activity, social, competition, and settings.
we-wrappers-fresh/src/screens - Shared UI · Reusable visualizations, modals, and fault isolation.
we-wrappers-fresh/src/components - Assets · Bundled icons, images, and splash resources for the mobile app.
we-wrappers-fresh/assets
Firebase layer
Client-side data access modules and the Firebase services they target.
- Firebase config · Firebase app initialization and service wiring.
we-wrappers-fresh/src/firebase/config.ts - Auth API · Authentication and user session operations.
we-wrappers-fresh/src/firebase/auth.ts - Wraps API · Wrap submissions, metadata, and media upload flow.
we-wrappers-fresh/src/firebase/wraps.ts - Social APIs · Friends, chats, chains, brackets, holidays, and notifications data access.
we-wrappers-fresh/src/firebase - Firebase Auth · Managed authentication provider.
- Firestore · Structured app data store for users, wraps, social data, and progress.
- Storage · Object store for user-uploaded wrap images and assets.
Serverless backend
Cloud Functions and operational surfaces outside the main mobile flow.
- Cloud Functions · Privileged backend automation and derived workflows.
we-wrappers-fresh/functions/index.js - Admin panel · Separate web-based operational interface.
we-wrappers-fresh/admin_panel.html
Connections 25
- App shell → Navigation: boots · App startup enters the client navigation shell.
- Navigation → Auth flow: unauthenticated · Routes new or signed-out users into the auth flow.
- Navigation → Main flow: authenticated · Routes signed-in users into the main app.
- Auth flow → User state: sign-in state · Auth flow reads and updates current user state.
- Main flow → User state: profile data · Main app depends on the current user profile and bootstrap state.
- Main flow → Refresh state: invalidate · Screens trigger cross-screen refresh after writes.
- Main flow → Screens: hosts · Navigation stack renders the feature screens.
- Screens → Shared UI: reuses · Screens share modal, calendar, bracket, and error boundary components.
- Screens → Auth API: auth actions · Welcome, sign-in, and account screens use auth operations.
- Screens → Wraps API: wrap data · Activity and wrap screens submit and load wrap records.
- Screens → Social APIs: social data · Friends, chats, groups, profiles, brackets, and notifications use domain APIs.
- Shared UI → Refresh state: refresh hooks · Shared overlays can participate in refresh-driven UI updates.
- Auth API → Firebase config: uses · Auth module is configured through the Firebase bootstrap.
- Wraps API → Firebase config: uses · Wrap uploads and metadata use the Firebase bootstrap.
- Social APIs → Firebase config: uses · Domain data modules use the Firebase bootstrap.
- Firebase config → Firebase Auth: connects · Client configuration initializes managed authentication.
- Auth API → Firebase Auth: reads/writes · Auth module talks to the Firebase Auth service.
- Wraps API → Firestore: reads/writes · Structured wrap and progress data live in Firestore.
- Social APIs → Firestore: reads/writes · Social, competition, and notification data live in Firestore.
- Wraps API → Storage: uploads · Wrap photos are stored as objects in Firebase Storage.
- Cloud Functions → Firestore: privileged updates · Serverless code can maintain derived records and automation.
- Cloud Functions → Storage: asset workflows · Backend jobs may process or reference stored media.
- Admin panel → Cloud Functions: operations · Admin interface is a separate operational surface over the same backend.
- Admin panel → Firestore: manage data · Admin panel likely reads or edits shared operational data.
- Assets → App shell: bundled into · Static assets support the Expo app shell.