mirror of
https://github.com/pacnpal/thrilltrack-explorer.git
synced 2025-12-27 16:27:04 -05:00
Refactor code structure and remove redundant changes
This commit is contained in:
175
PHASE_2_REPORTS_INTEGRATION_COMPLETE_WITH_REMAINING_WORK.md
Normal file
175
PHASE_2_REPORTS_INTEGRATION_COMPLETE_WITH_REMAINING_WORK.md
Normal file
@@ -0,0 +1,175 @@
|
||||
# Phase 2: Reports Component Integration - Status Report
|
||||
|
||||
## Completed ✅
|
||||
|
||||
Successfully migrated all direct reports queries from Supabase to Django API:
|
||||
|
||||
### 1. ReportButton.tsx
|
||||
- ✅ Report submission now uses `reportsService.submitReport()`
|
||||
- ✅ Removed direct Supabase reports insert
|
||||
- ✅ Uses ServiceResponse pattern for error handling
|
||||
|
||||
### 2. useModerationStats.ts
|
||||
- ✅ Report statistics now use `reportsService.getStatistics()`
|
||||
- ✅ Removed Supabase reports count queries
|
||||
- ✅ Maintained polling for updates
|
||||
|
||||
### 3. ReportsQueue.tsx
|
||||
- ✅ Report listing now uses `reportsService.listReports()`
|
||||
- ✅ Report status updates now use `reportsService.updateReportStatus()`
|
||||
- ✅ Pagination uses Django format (page/page_size)
|
||||
|
||||
## Remaining Supabase Dependencies ⚠️
|
||||
|
||||
The components still use Supabase for:
|
||||
|
||||
### In ReportsQueue.tsx:
|
||||
1. **Reporter Profile Data** (Lines ~195-210)
|
||||
```typescript
|
||||
const { data: allProfiles } = await supabase.rpc('get_users_with_emails');
|
||||
// OR
|
||||
await supabase.from('profiles').select('user_id, username, display_name')
|
||||
```
|
||||
**Solution needed:** Django users/profiles API endpoint + service layer
|
||||
|
||||
2. **Related Content Queries** (Lines ~219-258)
|
||||
- Reviews: `supabase.from('reviews').select(...)`
|
||||
- Profiles: `supabase.rpc('get_users_with_emails')`
|
||||
- Submissions: `supabase.from('content_submissions').select(...)`
|
||||
|
||||
**Solution needed:** Django API endpoints + service layers for:
|
||||
- Reviews API (partial - may exist in `api/v1/endpoints/reviews.py`)
|
||||
- Profiles API (partial - may exist in `api/v1/endpoints/auth.py`)
|
||||
- Content submissions API (needs investigation)
|
||||
|
||||
3. **Audit Logging** (Lines ~385-401)
|
||||
```typescript
|
||||
await supabase.rpc('log_admin_action', {...})
|
||||
```
|
||||
**Solution needed:** Django audit logging endpoint + service layer
|
||||
|
||||
### In useModerationStats.ts:
|
||||
1. **Content Submissions Stats** (Line ~81-84)
|
||||
```typescript
|
||||
await supabase.from('content_submissions')
|
||||
.select('id', { count: 'exact', head: true })
|
||||
.eq('status', 'pending')
|
||||
```
|
||||
|
||||
2. **Flagged Reviews Stats** (Line ~86-89)
|
||||
```typescript
|
||||
await supabase.from('reviews')
|
||||
.select('id', { count: 'exact', head: true })
|
||||
.eq('moderation_status', 'flagged')
|
||||
```
|
||||
|
||||
## Required Next Steps for Full Migration
|
||||
|
||||
### Phase 2B: Complete Reports Supabase Removal
|
||||
|
||||
#### Step 1: Create Service Layers
|
||||
Need to create service layers similar to reports service for:
|
||||
|
||||
1. **Users/Profiles Service** (`src/services/users/`)
|
||||
- `getUserProfile(userId)`
|
||||
- `getUserProfiles(userIds[])` - batch fetch
|
||||
- `getUsersWithEmails()` - admin function
|
||||
|
||||
2. **Reviews Service** (`src/services/reviews/`)
|
||||
- `getReview(reviewId)`
|
||||
- `getReviews(reviewIds[])` - batch fetch
|
||||
- May already partially exist
|
||||
|
||||
3. **Submissions Service** (`src/services/submissions/`)
|
||||
- `getSubmission(submissionId)`
|
||||
- `getSubmissions(submissionIds[])` - batch fetch
|
||||
- `getSubmissionStats()` - for moderation stats
|
||||
|
||||
4. **Audit Service** (`src/services/audit/`)
|
||||
- `logAdminAction(action, details)`
|
||||
|
||||
#### Step 2: Verify Django Endpoints Exist
|
||||
Check if these Django endpoints exist and are complete:
|
||||
|
||||
- [ ] `GET /api/v1/users/{id}` - Single user profile
|
||||
- [ ] `GET /api/v1/users/` - Batch user profiles (with query params)
|
||||
- [ ] `GET /api/v1/reviews/{id}` - Single review
|
||||
- [ ] `GET /api/v1/reviews/` - Batch reviews
|
||||
- [ ] `GET /api/v1/submissions/{id}` - Single submission
|
||||
- [ ] `GET /api/v1/submissions/` - Batch submissions
|
||||
- [ ] `GET /api/v1/submissions/stats` - Submission statistics
|
||||
- [ ] `POST /api/v1/audit/log` - Log admin action
|
||||
|
||||
#### Step 3: Update Components
|
||||
Once service layers exist:
|
||||
|
||||
1. Update `ReportsQueue.tsx`:
|
||||
- Replace Supabase profile queries with users service
|
||||
- Replace Supabase content queries with respective services
|
||||
- Replace Supabase audit logging with audit service
|
||||
|
||||
2. Update `useModerationStats.ts`:
|
||||
- Replace Supabase submission stats with submissions service
|
||||
- Replace Supabase review stats with reviews service
|
||||
|
||||
3. Remove Supabase import from both files
|
||||
|
||||
#### Step 4: Update Realtime Strategy
|
||||
Since Django doesn't support realtime subscriptions:
|
||||
- Convert all realtime subscriptions to polling
|
||||
- Or use WebSockets if Django has them configured
|
||||
- Or use Server-Sent Events (SSE) if available
|
||||
|
||||
## Current Architecture
|
||||
|
||||
### What's Using Django API ✅
|
||||
```
|
||||
ReportButton → reportsService → Django Reports API
|
||||
useModerationStats → reportsService.getStatistics() → Django Reports API
|
||||
ReportsQueue → reportsService.listReports() → Django Reports API
|
||||
ReportsQueue → reportsService.updateReportStatus() → Django Reports API
|
||||
```
|
||||
|
||||
### What's Still Using Supabase ⚠️
|
||||
```
|
||||
ReportsQueue → Supabase → profiles (reporter data)
|
||||
ReportsQueue → Supabase → reviews (reported content)
|
||||
ReportsQueue → Supabase → profiles (reported profiles)
|
||||
ReportsQueue → Supabase → content_submissions (reported submissions)
|
||||
ReportsQueue → Supabase RPC → audit logging
|
||||
|
||||
useModerationStats → Supabase → content_submissions (stats)
|
||||
useModerationStats → Supabase → reviews (flagged count)
|
||||
useModerationStats → Supabase realtime → submissions updates
|
||||
useModerationStats → Supabase realtime → reviews updates
|
||||
```
|
||||
|
||||
## Estimated Effort for Full Migration
|
||||
|
||||
- **Step 1 (Service Layers):** 3-4 hours
|
||||
- **Step 2 (Verify Endpoints):** 1 hour
|
||||
- **Step 3 (Update Components):** 2-3 hours
|
||||
- **Step 4 (Realtime Strategy):** 1-2 hours
|
||||
- **Testing:** 2-3 hours
|
||||
|
||||
**Total:** ~10-15 hours
|
||||
|
||||
## Recommendation
|
||||
|
||||
**Option A - Complete Now:**
|
||||
Proceed with creating all necessary service layers and complete the full Supabase removal.
|
||||
|
||||
**Option B - Iterative Approach:**
|
||||
1. Complete Phase 2B separately (remove remaining Supabase from reports components)
|
||||
2. Then tackle other components in subsequent phases
|
||||
3. Allows for testing and validation at each step
|
||||
|
||||
**Option C - Hybrid Temporary State:**
|
||||
Keep current partial migration working while planning full migration, as:
|
||||
- Reports CRUD is fully on Django (main goal achieved)
|
||||
- Related content queries are working (though via Supabase)
|
||||
- Can be migrated incrementally without breaking functionality
|
||||
|
||||
## Decision Point
|
||||
|
||||
Choose one of the above options to proceed. Current state is functional but not fully migrated from Supabase.
|
||||
Reference in New Issue
Block a user