collection_notifiers 1.0.4 collection_notifiers: ^1.0.4 copied to clipboard
Collections with implementation of ChangeNotifier/ValueListenable for minimum rebuild and better syntax
collection_notifiers #
Wrapped collections with ChangeNotifier & ValueListenable interface for optimized rebuilds and better syntax.
Features #
-
Best possible syntax, minimum amount of code
-
Huge performance benefits for medium/large collections
-
Fully compatible with ValueListenableBuilder and Riverpod / Provider
-
Dead simple to use
-
Lightweight
Riverpod/Provider without collection_notifiers
#
- Always
triggers setState
- Always
creates copies
Verbose
syntax
final setProvider = StateProvider((ref) => <E>{});
onAdd: (value) => ref.read(setProvider.state).update((state) {
return <E>{...state, value}; // a new copy created
});
onRemove: (value) => ref.read(setProvider.state).update((state) {
return <E>{...state..remove(value)}; // a new copy created
});
Riverpod/Provider with collection_notifiers
#
- Triggers
setState only when needed
- Creates
zero copy
Terse
syntax
final setProvider = ChangeNotifierProvider((ref) => SetNotifier<E>());
onAdd: ref.read(setProvider).add; // does not create copy
onRemove: ref.read(setProvider).remove; // does not create copy
Operators are also overridden, List
:
final listProvider = ChangeNotifierProvider((ref) => ListNotifier([1]));
ref.read(listProvider)[0] = 1; // won't trigger setState
Similarly, the Map
:
final mapProvider = ChangeNotifierProvider((ref) => MapNotifier({'a' : 1}));
ref.read(mapProvider)['a'] = 1; // won't trigger setState
Implementations #
Collection | Status | Notifier |
---|---|---|
Set | Completed | SetNotifier |
List | Completed(see notes) | ListNotifier |
Map | Completed | MapNotifier |
Queue | Completed | QueueNotifier |
Open issue if there is any specific collection/method you need.
Element Equality #
Element equation(== operator) must be handled by you beforehand. For that case, code generation(freezed, built_value etc.) or equatable are highly recommended.
Notes #
-
collection_notifiers
do not handle anyException
because it may cause confusing development experience and sneaky bugs. -
Methods with overridden logic, always mimics default implementation. Hence, no additional
Exception
is also produced. -
Methods that requires collection equalities(like
sort()
,shuffle()
etc...) always trigger setState.