feat: Migrate staff profile features from Data Connect to V2 REST API
- Removed data_connect package from mobile pubspec.yaml. - Added documentation for V2 profile migration status and QA findings. - Implemented new session management with ClientSessionStore and StaffSessionStore. - Created V2SessionService for handling user sessions via the V2 API. - Developed use cases for cancelling late worker assignments and submitting worker reviews. - Added arguments and use cases for payment chart retrieval and profile completion checks. - Implemented repository interfaces and their implementations for staff main and profile features. - Ensured proper error handling and validation in use cases.
This commit is contained in:
Achintha Isuru
@@ -26,6 +26,7 @@ and load any additional skills as needed for specific review challenges.
|
||||
- Ensuring business logic lives in use cases (not BLoCs/widgets)
|
||||
- Flagging design system violations (hardcoded colors, TextStyle, spacing, icons)
|
||||
- Validating BLoC pattern usage (SessionHandlerMixin, BlocErrorHandler, singleton registration)
|
||||
- **Verifying every feature module that uses `BaseApiService` (or any CoreModule binding) declares `List<Module> get imports => <Module>[CoreModule()];`** — missing this causes `UnregisteredInstance` runtime crashes
|
||||
- Ensuring safe navigation extensions are used (no direct Navigator usage)
|
||||
- Verifying test coverage for business logic
|
||||
- Checking documentation on public APIs
|
||||
@@ -205,6 +206,7 @@ Produce a structured report in this exact format:
|
||||
|------|--------|---------|
|
||||
| Design System | ✅/❌ | [details] |
|
||||
| Architecture Boundaries | ✅/❌ | [details] |
|
||||
| DI / CoreModule Imports | ✅/❌ | [Every module using BaseApiService must import CoreModule] |
|
||||
| State Management | ✅/❌ | [details] |
|
||||
| Navigation | ✅/❌ | [details] |
|
||||
| Testing Coverage | ✅/❌ | [estimated %] |
|
||||
|
||||
@@ -43,10 +43,11 @@ If any of these files are missing or unreadable, notify the user before proceedi
|
||||
- Import icon libraries directly — use `UiIcons`
|
||||
- Use `Navigator.push` directly — use Modular safe extensions
|
||||
- Navigate without home fallback
|
||||
- Call DataConnect directly from BLoCs — go through repository
|
||||
- Call API directly from BLoCs — go through repository
|
||||
- Skip tests for business logic
|
||||
|
||||
### ALWAYS:
|
||||
- **Add `CoreModule` import to every feature module that uses `BaseApiService` or any other `CoreModule` binding** (e.g., `FileUploadService`, `DeviceFileUploadService`, `CameraService`). Without this, the DI container throws `UnregisteredInstance` at runtime. Add: `@override List<Module> get imports => <Module>[CoreModule()];`
|
||||
- **Use `package:` imports everywhere inside `lib/`** for consistency and robustness. Use relative imports only in `test/` and `bin/` directories. Example: `import 'package:staff_clock_in/src/presentation/bloc/clock_in/clock_in_bloc.dart';` not `import '../bloc/clock_in/clock_in_bloc.dart';`
|
||||
- Place reusable utility functions (math, geo, formatting, etc.) in `apps/mobile/packages/core/lib/src/utils/` and export from `core.dart` — never keep them as private methods in feature packages
|
||||
- Use feature-first packaging: `domain/`, `data/`, `presentation/`
|
||||
@@ -72,7 +73,7 @@ If any of these files are missing or unreadable, notify the user before proceedi
|
||||
The mobile apps are migrating from Firebase Data Connect (direct DB) to V2 REST API. Follow these rules for ALL new and migrated features:
|
||||
|
||||
### Backend Access
|
||||
- **Use `ApiService.get/post/put/delete`** for ALL backend calls — NEVER use Data Connect connectors
|
||||
- **Use `ApiService.get/post/put/delete`** for ALL backend calls
|
||||
- Import `ApiService` from `package:krow_core/core.dart`
|
||||
- Use `V2ApiEndpoints` from `package:krow_core/core.dart` for endpoint URLs
|
||||
- V2 API docs are at `docs/BACKEND/API_GUIDES/V2/` — check response shapes before writing code
|
||||
@@ -87,7 +88,7 @@ The mobile apps are migrating from Firebase Data Connect (direct DB) to V2 REST
|
||||
- **RepoImpl lives in the feature package** at `data/repositories/`
|
||||
- **Feature-level domain layer is optional** — only add `domain/` when the feature has use cases, validators, or feature-specific interfaces
|
||||
- **Simple features** (read-only, no business logic) = just `data/` + `presentation/`
|
||||
- Do NOT import from `packages/data_connect/` — it is deprecated
|
||||
- Do NOT import from `packages/data_connect/` — deleted
|
||||
|
||||
### Status & Type Enums
|
||||
All status/type fields from the V2 API must use Dart enums, NOT raw strings. Parse at the `fromJson` boundary with a safe fallback:
|
||||
@@ -169,7 +170,7 @@ Follow these steps in order for every feature implementation:
|
||||
- Create barrel file exporting the domain public API
|
||||
|
||||
### 4. Data Layer
|
||||
- Implement repository classes using `ApiService` with `V2ApiEndpoints` — NOT DataConnectService
|
||||
- Implement repository classes using `ApiService` with `V2ApiEndpoints`
|
||||
- Parse V2 API JSON responses into domain entities via `Entity.fromJson()`
|
||||
- Map errors to domain `Failure` types
|
||||
- Create barrel file for data layer
|
||||
@@ -266,7 +267,7 @@ After completing implementation, prepare a handoff summary including:
|
||||
As you work on features, update your agent memory with discoveries about:
|
||||
- Existing feature patterns and conventions in the codebase
|
||||
- Session store usage patterns and available stores
|
||||
- DataConnect query/mutation names and their locations
|
||||
- V2 API endpoint patterns and response shapes
|
||||
- Design token values and component patterns actually in use
|
||||
- Module registration patterns and route conventions
|
||||
- Recurring issues found during `melos analyze`
|
||||
|
||||
@@ -22,8 +22,8 @@ You are working within a Flutter monorepo (where features are organized into pac
|
||||
- **State Management**: Flutter BLoC/Cubit. BLoCs registered with `i.add()` (transient), never `i.addSingleton()`. `BlocProvider.value()` for shared BLoCs.
|
||||
- **DI & Routing**: Flutter Modular. Safe navigation via `safeNavigate()`, `safePush()`, `popSafe()`. Never `Navigator.push()` directly (except when popping a dialog).
|
||||
- **Error Handling**: `BlocErrorHandler` mixin with `_safeEmit()` to prevent StateError on disposed BLoCs.
|
||||
- **Backend**: Firebase Data Connect through `data_connect` package Connectors. `_service.run(() => connector.<query>().execute())` for auth/token management.
|
||||
- **Session Management**: `SessionHandlerMixin` + `SessionListener` widget.
|
||||
- **Backend**: V2 REST API via `ApiService` with `V2ApiEndpoints`. Domain entities have `fromJson`/`toJson`. Status fields use typed enums from `krow_domain`. Money values are `int` in cents.
|
||||
- **Session Management**: `V2SessionService` + `SessionHandlerMixin` + `SessionListener` widget. Session stores (`StaffSessionStore`, `ClientSessionStore`) in `core`.
|
||||
- **Localization**: Slang (`t.section.key`), not `context.strings`.
|
||||
- **Design System**: Tokens from `UiColors`, `UiTypography`, `UiConstants`. No hardcoded values.
|
||||
|
||||
@@ -55,7 +55,7 @@ Detect potential bugs including:
|
||||
- **API integration issues**: Missing error handling, incorrect data mapping, async issues
|
||||
- **Performance concerns**: Inefficient algorithms, unnecessary rebuilds, memory problems
|
||||
- **Security vulnerabilities**: Hardcoded credentials, insecure data storage, authentication gaps
|
||||
- **Architecture violations**: Features importing other features, business logic in BLoCs/widgets, Firebase packages outside `data_connect`
|
||||
- **Architecture violations**: Features importing other features, business logic in BLoCs/widgets, Firebase packages outside `core`, direct Dio usage instead of `ApiService`
|
||||
- **Data persistence issues**: Cache invalidation, concurrent access
|
||||
|
||||
## Analysis Methodology
|
||||
@@ -64,7 +64,7 @@ Detect potential bugs including:
|
||||
1. Map the feature's architecture and key screens
|
||||
2. Identify critical user flows and navigation paths
|
||||
3. Review state management implementation (BLoC states, events, transitions)
|
||||
4. Understand data models and API contracts via Data Connect connectors
|
||||
4. Understand data models and API contracts via V2 API endpoints
|
||||
5. Document assumptions and expected behaviors
|
||||
|
||||
### Phase 2: Use Case Extraction
|
||||
@@ -108,7 +108,7 @@ Analyze code for:
|
||||
- Missing error handling in `.then()` chains
|
||||
- Mounted checks missing in async callbacks
|
||||
- Race conditions in concurrent requests
|
||||
- Missing `_service.run()` wrapper for Data Connect calls
|
||||
- Missing `ApiErrorHandler.executeProtected()` wrapper for API calls
|
||||
|
||||
### Background Tasks & WorkManager
|
||||
When reviewing code that uses WorkManager or background task scheduling, check these edge cases:
|
||||
@@ -140,7 +140,9 @@ When reviewing code that uses WorkManager or background task scheduling, check t
|
||||
### Architecture Rules
|
||||
- Features importing other features directly
|
||||
- Business logic in BLoCs or widgets instead of Use Cases
|
||||
- Firebase packages used outside `data_connect` package
|
||||
- Firebase packages (`firebase_auth`) used outside `core` package
|
||||
- Direct Dio/HTTP usage instead of `ApiService` with `V2ApiEndpoints`
|
||||
- Importing deleted `krow_data_connect` package
|
||||
- `context.read<T>()` instead of `ReadContext(context).read<T>()`
|
||||
|
||||
## Output Format
|
||||
|
||||
Reference in New Issue
Block a user