collection_notifiers 1.0.0

ChangeNotifier/ValueListenable wrappers for collections with optimized notification

collection_notifiers

The wrapped collections with ChangeNotifier & ValueListenable interface for optimized notification and simpler/efficient syntax.

Why?

It's a hassle when working with collections and updating the state. Most of the popular state management packages do not come with a built-in solution for collections.

collection_notifiers eliminating the boilerplate and unneeded rebuilds by calculating the difference very efficiently(Collection equalities are not used).

It's fully compatible and ease to use with ValueListenableBuilder or popular packages like Riverpod / Provider via ChangeNotifierProvider.

Typical comparison would be:

Riverpod:

final setProvider = StateProvider((ref) => <E>{});
/// Always triggers [setState]
/// Always creates shallow copies
/// Verbose syntax
onAdd: (value) => ref.read(setProvider.state).update((state) => <E>{...state, value});
onRemove: (value) => ref.read(setProvider.state).update((state) => <E>{...state..remove(value)});

Riverpod with collection_notifiers:

final setProvider = ChangeNotifierProvider((ref) => SetNotifier<E>());
/// Does not trigger [setState] if there is no change
/// Never creates shallow copies
/// Terse syntax
onAdd: ref.read(setProvider).add;
onRemove: ref.read(setProvider).remove;

Operators are also overridden:

final listProvider = ChangeNotifierProvider((ref) => ListNotifier<int>([1]));
...
ref.read(listProvider)[0] = 1; // won't trigger setState

Similarly:

final mapProvider = ChangeNotifierProvider((ref) => MapNotifier<String, int>({'a' : 1}));
...
ref.read(mapProvider)['a'] = 1; // won't trigger setState

So what you have is, having significant advantages while paying no real cost.

Implementations

Collection	Status	Notifier
Set	Completed	SetNotifier
List	Not Fully Optimized	ListNotifier
Map	Completed	MapNotifier
Queue	Completed	QueueNotifier

Ask if there is any specific collection you need, pull requests are also welcome!

Element Equality

Element equation(== operator) must be handled by you beforehand. For that case, code generation(freezed, built_value etc.) or equatable strongly recommended.

Notes

• collection_notifiers do not handle any Exception 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.

Mentions

There is a very similar package listenable_collections, but repo was a little inactive, and probably I'll choose different path over the time. Thanks them, I borrowed some concepts.