85 lines
2.6 KiB
Markdown
85 lines
2.6 KiB
Markdown
# Provider Fix Summary
|
|
|
|
## ✅ Problem Fixed
|
|
|
|
The `price_documents_provider.dart` was using the wrong Riverpod pattern.
|
|
|
|
## ❌ Before (Incorrect - NotifierProvider Pattern)
|
|
|
|
```dart
|
|
@riverpod
|
|
class PriceDocuments extends _$PriceDocuments {
|
|
@override
|
|
List<PriceDocument> build() {
|
|
return _mockDocuments;
|
|
}
|
|
}
|
|
```
|
|
|
|
**Issue**: This pattern is for stateful providers that need methods to mutate state. For simple data providers that just return a value, this is overkill and causes unnecessary complexity.
|
|
|
|
## ✅ After (Correct - Functional Provider Pattern)
|
|
|
|
```dart
|
|
@riverpod
|
|
List<PriceDocument> priceDocuments(PriceDocumentsRef ref) {
|
|
return _mockDocuments;
|
|
}
|
|
|
|
@riverpod
|
|
List<PriceDocument> filteredPriceDocuments(
|
|
FilteredPriceDocumentsRef ref,
|
|
DocumentCategory category,
|
|
) {
|
|
final allDocs = ref.watch(priceDocumentsProvider);
|
|
return allDocs.where((doc) => doc.category == category).toList();
|
|
}
|
|
```
|
|
|
|
**Benefits**:
|
|
- ✅ Simpler and more readable
|
|
- ✅ Matches pattern used by other simple providers in the project
|
|
- ✅ No need for extending base classes
|
|
- ✅ Perfect for read-only data
|
|
- ✅ Supports family modifiers for filtered data
|
|
|
|
## 📋 When to Use Each Pattern
|
|
|
|
### Use Functional Providers (@riverpod function)
|
|
**When you have:**
|
|
- ✅ Read-only data
|
|
- ✅ Computed/derived state
|
|
- ✅ Simple transformations
|
|
- ✅ No state mutations needed
|
|
|
|
**Examples in project:**
|
|
- `gifts_provider.dart` - Returns list of gifts
|
|
- `selected_category_provider.dart` - Returns current category
|
|
- `search_query_provider.dart` - Returns search text
|
|
- **`price_documents_provider.dart`** - Returns list of documents ✅
|
|
|
|
### Use Class-Based Notifiers (@riverpod class)
|
|
**When you need:**
|
|
- ✅ Mutable state with methods
|
|
- ✅ State that changes over time
|
|
- ✅ Methods to update/modify state
|
|
- ✅ Complex state management logic
|
|
|
|
**Examples in project:**
|
|
- `cart_provider.dart` - Has `addItem()`, `removeItem()`, `updateQuantity()`
|
|
- `favorites_provider.dart` - Has `toggleFavorite()`, `addFavorite()`
|
|
- `loyalty_points_provider.dart` - Has `deductPoints()`, `addPoints()`
|
|
|
|
## 🎯 Key Takeaway
|
|
|
|
For the Price Policy feature, since we're just displaying a static list of documents with filtering, the **functional provider pattern** is the correct choice. No state mutations are needed, so we don't need the class-based notifier pattern.
|
|
|
|
## 📁 Files Changed
|
|
|
|
1. `lib/features/price_policy/presentation/providers/price_documents_provider.dart`
|
|
2. `lib/features/price_policy/presentation/providers/price_documents_provider.g.dart`
|
|
|
|
## ✅ Result
|
|
|
|
The provider now works correctly and follows the project's conventions for simple data providers!
|