collection_notifiers 1.0.2

Collections with implementation of ValueListenable/ChangeNotifier for minimum rebuild and sugared 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 to update the state, eliminates 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

• Always triggers setState
• Always creates shallow/deep copies
• Verbose syntax

final setProvider = StateProvider((ref) => <E>{});

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:

• Does not trigger setState if there is no change
• Never creates shallow/deep copies
• Terse syntax

final setProvider = ChangeNotifierProvider((ref) => SetNotifier<E>());

onAdd: ref.read(setProvider).add;
onRemove: ref.read(setProvider).remove;

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

So at the end, what you have is 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.