collection_notifiers 1.0.0+1

Collection Notifiers for better performance and syntax

Wrapped collections with ChangeNotifier & ValueListenable interface for optimized rebuilds and better 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 reduces the boilerplate that required update the state while eliminating unneeded rebuilds by calculating the difference very efficiently.

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) {
  return <E>{...state, value};
});
onRemove: (value) => ref.read(setProvider.state).update((state) {
  return <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([1]));
...
ref.read(listProvider)[0] = 1; // won't trigger setState

Similarly:

final mapProvider = ChangeNotifierProvider((ref) => MapNotifier({'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	Completed(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 are 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.
• Methods that requires collection equalities(like sort(), shuffle() etc...) always triggers setState.

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.