collection_notifiers 1.1.0

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

• Huge performance benefits for medium/large collections

• Best possible syntax, minimum amount of code

• Fully compatible with ValueListenableBuilder and Riverpod / Provider

• Dead simple to use

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([0]));
ref.read(listProvider)[0] = 1; // will trigger setState
ref.read(listProvider)[0] = 1; // won't trigger setState

Similarly, the Map:

final mapProvider = ChangeNotifierProvider((ref) => MapNotifier());
ref.read(mapProvider)['a'] = 1; // will trigger setState
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 an 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 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 trigger setState.