Provider Fix Summary

✅ Problem Fixed

The price_documents_provider.dart was using the wrong Riverpod pattern.

❌ Before (Incorrect - NotifierProvider Pattern)

@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)

@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

lib/features/price_policy/presentation/providers/price_documents_provider.dart
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!

2.6 KiB Raw Blame History