amirrezaghabeli
428 lines
14 KiB
Markdown
428 lines
14 KiB
Markdown
# 📊 DI & State Management Analysis Summary
|
|
|
|
## 🎯 Executive Summary
|
|
|
|
**Overall Assessment:** 🟡 **NEEDS SIGNIFICANT REFACTORING**
|
|
|
|
Your DI and state management have **good foundational architecture** but suffer from **critical anti-patterns** that will cause maintenance and scalability issues.
|
|
|
|
### Key Metrics
|
|
|
|
| Metric | Current | Target | Gap |
|
|
|--------|---------|--------|-----|
|
|
| Average ViewModel Size | 338 lines | 50-80 lines | 🔴 4x too large |
|
|
| ViewModel Dependencies | 9 circular | 0 | 🔴 Critical |
|
|
| Providers at Startup | 25 eager | 5-8 eager | 🟡 3x too many |
|
|
| Error Handling Pattern | Anti-pattern | Proper state | 🔴 Broken |
|
|
| State Classes | 0 | 9 | 🔴 Missing |
|
|
| Test Coverage | 0% | 70%+ | 🔴 Critical |
|
|
|
|
---
|
|
|
|
## 🏗️ Current Architecture
|
|
|
|
```
|
|
┌─────────────────────────────────────────────────┐
|
|
│ main.dart (App Entry) │
|
|
│ MultiProvider with ALL 25 providers │
|
|
│ ❌ Created immediately at startup │
|
|
└─────────────────────────────────────────────────┘
|
|
│
|
|
┌───────────┴───────────┐
|
|
│ │
|
|
┌────▼────┐ ┌─────▼─────┐
|
|
│ Cores │ │ Services │
|
|
│ (2) │ │ (8) │
|
|
└────┬────┘ └─────┬─────┘
|
|
│ │
|
|
└───────────┬───────────┘
|
|
│
|
|
┌──────▼──────┐
|
|
│ Repositories│
|
|
│ (8) │
|
|
└──────┬──────┘
|
|
│
|
|
┌──────▼──────┐
|
|
│ ViewModels │
|
|
│ (9) │
|
|
│ ❌ Depend │
|
|
│ on each │
|
|
│ other! │
|
|
└──────┬──────┘
|
|
│
|
|
┌──────▼──────┐
|
|
│ Views │
|
|
│ (122) │
|
|
└─────────────┘
|
|
```
|
|
|
|
---
|
|
|
|
## 🔴 Problem #1: ViewModel Circular Dependencies
|
|
|
|
```
|
|
TendersViewModel
|
|
│
|
|
├──> HomeViewModel ───────┐
|
|
│ │
|
|
TenderDetailViewModel │
|
|
│ │
|
|
├──> TendersViewModel │
|
|
├──> HomeViewModel ◄──────┘
|
|
│
|
|
LikedTendersViewModel
|
|
│
|
|
├──> TendersRepository
|
|
├──> HomeViewModel
|
|
|
|
ProfileViewModel
|
|
│
|
|
├──> AuthViewModel
|
|
└──> AuthRepository
|
|
|
|
NotificationViewModel
|
|
│
|
|
├──> NotificationsRepository
|
|
└──> HomeViewModel
|
|
```
|
|
|
|
### Impact:
|
|
- ❌ **Tight Coupling:** Can't change one without affecting others
|
|
- ❌ **Testing Nightmare:** Must mock all dependent ViewModels
|
|
- ❌ **Circular Dependencies:** Potential infinite loops
|
|
- ❌ **Cascading Rebuilds:** One VM change triggers others
|
|
- ❌ **Memory Leaks:** ViewModels keep references to each other
|
|
|
|
---
|
|
|
|
## 🔴 Problem #2: Eager Instantiation Performance
|
|
|
|
### Current Startup Sequence:
|
|
```dart
|
|
1. App starts
|
|
2. MultiProvider creates 25 providers instantly:
|
|
├─ 2 cores (NetworkManager, ThemeProvider)
|
|
├─ 8 services (AuthService, HomeService, etc.)
|
|
├─ 8 repositories
|
|
└─ 9 ViewModels
|
|
3. HomeViewModel constructor calls init()
|
|
├─ getApprovedStates() → API call
|
|
├─ getYourTenders() → API call
|
|
├─ getFeedbackStats() → API call
|
|
└─ checkUnreadNotifications() → API call
|
|
4. User sees splash screen for 2-3 seconds
|
|
```
|
|
|
|
### Problems:
|
|
- 🐌 **Slow startup:** 4 API calls before UI appears
|
|
- 💾 **Memory waste:** ProfileViewModel created but never used on home screen
|
|
- 🔋 **Battery drain:** Unnecessary network calls
|
|
- 📱 **Poor UX:** Long loading time
|
|
|
|
### Should Be:
|
|
```dart
|
|
1. App starts
|
|
2. Create only essentials:
|
|
├─ NetworkManager
|
|
├─ ThemeProvider
|
|
└─ AuthViewModel
|
|
3. Show splash screen (< 500ms)
|
|
4. Lazy create ViewModels on navigation:
|
|
├─ Navigate to Home → Create HomeViewModel → Call init()
|
|
├─ Navigate to Tenders → Create TendersViewModel
|
|
└─ Navigate to Profile → Create ProfileViewModel
|
|
```
|
|
|
|
---
|
|
|
|
## 🔴 Problem #3: Error Handling Anti-Pattern
|
|
|
|
### Current Code (Repeated in 9 ViewModels):
|
|
```dart
|
|
// Set error
|
|
_errorMessage = result.error.toString();
|
|
notifyListeners(); // Frame 1: Error shows
|
|
|
|
// Immediately clear error
|
|
_errorMessage = null;
|
|
notifyListeners(); // Frame 2: Error gone!
|
|
```
|
|
|
|
### Timeline:
|
|
```
|
|
Frame 1 (16ms): User sees error message
|
|
Frame 2 (32ms): Error disappears
|
|
Result: Error flashes and vanishes!
|
|
```
|
|
|
|
### Should Be:
|
|
```dart
|
|
// Set error with auto-clear
|
|
_setError(result.error.toString(), duration: 3.seconds);
|
|
|
|
// OR in UI with listener
|
|
if (viewModel.errorMessage != null) {
|
|
WidgetsBinding.instance.addPostFrameCallback((_) {
|
|
AppToast.error(context, viewModel.errorMessage!);
|
|
viewModel.clearError();
|
|
});
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
## 🔴 Problem #4: No State Classes
|
|
|
|
### Current (Scattered Primitives):
|
|
```dart
|
|
// TendersViewModel has 15+ state variables
|
|
bool _isLoading = false;
|
|
bool _isLoadingMore = false;
|
|
String? _errorMessage;
|
|
String? _feedbackErrorMessage;
|
|
TendersResponse? _tendersResponse;
|
|
FeedbackData? _feedbackData;
|
|
String? _searchQuery;
|
|
List<FeedbackData> feedbacks = [];
|
|
int currentPage = 1;
|
|
int _currentOffset = 0;
|
|
int _totalPages = 0;
|
|
bool _hasMoreData = true;
|
|
DateTimeRange? selectedDateRange;
|
|
String selectedStatus = 'All';
|
|
String selectedSort = '';
|
|
// ... more fields
|
|
```
|
|
|
|
### Problems:
|
|
- ❌ No single source of truth
|
|
- ❌ Can have inconsistent state (isLoading=false but _isLoadingMore=true)
|
|
- ❌ Hard to test
|
|
- ❌ Can't easily serialize/deserialize
|
|
- ❌ No immutability guarantees
|
|
- ❌ Can't use pattern matching
|
|
|
|
### Should Be:
|
|
```dart
|
|
@freezed
|
|
class TendersState with _$TendersState {
|
|
const factory TendersState({
|
|
@Default(LoadingStatus.idle) LoadingStatus status,
|
|
@Default([]) List<Tender> tenders,
|
|
@Default([]) List<FeedbackData> feedbacks,
|
|
@Default(PaginationInfo()) PaginationInfo pagination,
|
|
@Default(FilterInfo()) FilterInfo filters,
|
|
ErrorInfo? error,
|
|
}) = _TendersState;
|
|
|
|
// Derived properties
|
|
bool get isLoading => status == LoadingStatus.loading;
|
|
bool get hasError => error != null;
|
|
bool get canLoadMore => pagination.hasMore && !isLoading;
|
|
}
|
|
|
|
// Single state variable
|
|
TendersState _state = TendersState();
|
|
```
|
|
|
|
---
|
|
|
|
## 🔴 Problem #5: Monolithic ViewModels
|
|
|
|
### Size Distribution:
|
|
```
|
|
YourTendersViewModel: 384 lines 🔴
|
|
AuthViewModel: 338 lines 🔴
|
|
HomeViewModel: 244 lines 🔴
|
|
TendersViewModel: 525 lines 🔴 (WORST)
|
|
ProfileViewModel: 102 lines 🟡
|
|
```
|
|
|
|
### TendersViewModel Responsibilities:
|
|
1. Tenders pagination (mobile)
|
|
2. Tenders pagination (desktop)
|
|
3. Feedback management
|
|
4. Filter state management
|
|
5. Sort state management
|
|
6. Date range selection
|
|
7. Search functionality
|
|
8. Optimistic updates
|
|
9. Error handling
|
|
10. Multiple API coordination
|
|
|
|
**Violates Single Responsibility Principle!**
|
|
|
|
### Should Be Split Into:
|
|
```
|
|
tenders/
|
|
├── tenders_view_model.dart (50 lines - orchestrator)
|
|
├── tenders_state.dart (40 lines - state class)
|
|
├── tenders_loader.dart (60 lines - load tenders)
|
|
├── feedback_manager.dart (70 lines - feedback CRUD)
|
|
├── tenders_filter.dart (40 lines - filtering)
|
|
├── tenders_pagination.dart (50 lines - pagination)
|
|
└── tenders_search.dart (30 lines - search)
|
|
|
|
Total: 340 lines split across 7 files (avg 48 lines each) ✅
|
|
```
|
|
|
|
---
|
|
|
|
## 🔴 Problem #6: Complex Manual State Management
|
|
|
|
### Optimistic Updates with Manual Rollback:
|
|
```dart
|
|
// 100+ lines of complex state manipulation
|
|
Future<void> toggleFeedback() async {
|
|
// 1. Save current state
|
|
final existing = getFeedbackForTender(tenderId);
|
|
|
|
// 2. Optimistic update
|
|
if (existing == null) {
|
|
feedbacks.add(optimisticFeedback);
|
|
} else {
|
|
if (existing.type == feedbackType) {
|
|
feedbacks.removeAt(index);
|
|
} else {
|
|
feedbacks[index] = optimisticFeedback;
|
|
}
|
|
}
|
|
notifyListeners();
|
|
|
|
// 3. API call
|
|
final result = await _repository.toggleFeedback();
|
|
|
|
// 4. Manual rollback on error
|
|
switch (result) {
|
|
case Error():
|
|
// 20 lines of rollback logic
|
|
if (existing == null) {
|
|
feedbacks.removeWhere(...);
|
|
} else {
|
|
final currentIndex = feedbacks.indexWhere(...);
|
|
if (currentIndex != -1) {
|
|
feedbacks[currentIndex] = existing;
|
|
} else {
|
|
feedbacks.add(existing);
|
|
}
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
### Problems:
|
|
- ❌ **Error-prone:** Easy to make mistakes in rollback
|
|
- ❌ **Hard to test:** Many edge cases
|
|
- ❌ **Not reusable:** Can't apply to other operations
|
|
- ❌ **Race conditions:** What if user clicks twice?
|
|
|
|
### Should Use:
|
|
- **Riverpod AsyncValue** (built-in optimistic updates)
|
|
- **Bloc Optimistic Pattern**
|
|
- **State machine** with rollback support
|
|
|
|
---
|
|
|
|
## 📊 Dependency Graph Analysis
|
|
|
|
### Current (Problematic):
|
|
```
|
|
┌─────────────────────────────────────────────────┐
|
|
│ ViewModel Layer (9) │
|
|
│ │
|
|
│ ┌──────────┐ ┌──────────┐ │
|
|
│ │Tenders VM│◄────►│ Home VM │ │
|
|
│ └─────┬────┘ └────┬─────┘ │
|
|
│ │ │ │
|
|
│ └────┬───────────┘ │
|
|
│ ▼ │
|
|
│ ┌───────────────┐ │
|
|
│ │TenderDetail VM│ │
|
|
│ └───────────────┘ │
|
|
│ │
|
|
│ ❌ Circular dependencies everywhere │
|
|
└─────────────────────────────────────────────────┘
|
|
```
|
|
|
|
### Should Be (Clean):
|
|
```
|
|
┌─────────────────────────────────────────────────┐
|
|
│ ViewModel Layer (9) │
|
|
│ │
|
|
│ Each ViewModel independent, shares data via: │
|
|
│ • Repositories (read/write) │
|
|
│ • Event Bus (notifications) │
|
|
│ • Navigation params (one-time data) │
|
|
│ │
|
|
│ ✅ No direct VM-to-VM dependencies │
|
|
└─────────────────────────────────────────────────┘
|
|
```
|
|
|
|
---
|
|
|
|
## 🎯 Impact Analysis
|
|
|
|
### Current Problems Lead To:
|
|
|
|
#### Development Issues:
|
|
- 🐌 **Slow feature development** (tight coupling)
|
|
- 🐛 **Hard to debug** (state scattered everywhere)
|
|
- 🧪 **Can't write tests** (VM dependencies)
|
|
- 🔄 **Refactoring is risky** (changes break other features)
|
|
|
|
#### Performance Issues:
|
|
- 📱 **Slow app startup** (eager instantiation)
|
|
- 🔋 **Battery drain** (unnecessary API calls)
|
|
- 💾 **Memory waste** (unused ViewModels loaded)
|
|
- 🎨 **Unnecessary rebuilds** (cascading VM updates)
|
|
|
|
#### User Experience Issues:
|
|
- ⏳ **Long loading times**
|
|
- ⚠️ **Errors disappear instantly** (can't read them)
|
|
- 🐞 **Potential bugs** (complex state management)
|
|
- 💥 **Crashes** (race conditions in optimistic updates)
|
|
|
|
---
|
|
|
|
## ✅ Recommended Solution
|
|
|
|
### Short-term (1-2 weeks):
|
|
1. **Remove ViewModel dependencies** → Use shared repositories
|
|
2. **Implement lazy loading** → ProxyProvider
|
|
3. **Fix error handling** → Proper error state
|
|
4. **Add state classes** → Freezed models
|
|
|
|
### Long-term (3-4 weeks):
|
|
1. **Migrate to Riverpod** → Better state management
|
|
2. **Split large ViewModels** → Follow 10-15 line rule
|
|
3. **Add comprehensive tests** → 70%+ coverage
|
|
4. **Implement event bus** → Decouple features
|
|
|
|
---
|
|
|
|
## 📈 Success Metrics
|
|
|
|
After refactoring, you should see:
|
|
|
|
| Metric | Before | After | Improvement |
|
|
|--------|--------|-------|-------------|
|
|
| App startup time | 2-3s | < 1s | 🟢 3x faster |
|
|
| Avg ViewModel size | 338 lines | 60 lines | 🟢 5x smaller |
|
|
| Test coverage | 0% | 70%+ | 🟢 Testable |
|
|
| Build time | Unknown | Tracked | 🟢 Measurable |
|
|
| Memory usage | Unknown | Optimized | 🟢 Lower |
|
|
| Developer velocity | Slow | Fast | 🟢 Faster |
|
|
|
|
---
|
|
|
|
## 🚀 Next Steps
|
|
|
|
1. **Review** this analysis with your team
|
|
2. **Prioritize** which issues to tackle first
|
|
3. **Create tickets** for each refactoring task
|
|
4. **Start with** ViewModel dependencies (highest impact)
|
|
5. **Add tests** as you refactor each ViewModel
|
|
6. **Measure** improvements with analytics
|
|
|
|
|