Package selection guidance compiled from public package information, community data, and project usage.
A Dart package that provides an Ordered Set implementation supporting multiple items with identical priority. It maintains insertion order for elements with the same priority, enabling predictable and efficient sorting in applications requiring ordered collections. Ideal for use cases where duplicate priorities are expected but order preservation is essential. The package is lightweight, compatible across all major platforms, and integrates seamlessly with Flutter projects via pub.dev.
Use cases
Priority-based task scheduling
Maintaining ordered logs with duplicates
Implementing priority queues with tie-breaking
Managing event sequences with equal urgency
Custom sorting in data pipelines
Real-time data processing with order constraints
Key features
Supports multiple items with same priority
Preserves insertion order within equal priorities
Cross-platform compatibility
Lightweight and easy to integrate
Efficient lookup and insertion
No external dependencies
Suitable for
Developers needing ordered collections with duplicate priorities
Applications requiring deterministic ordering
Flutter apps with complex data sorting needs
Systems managing time-sensitive or priority-driven workflows
Engineers building custom queue or buffer systems
Considerations
Not suitable for high-frequency updates due to performance trade-offs
Limited to single-key ordering (no multi-level sorting)
Requires manual handling of priority changes
Best suited for moderate-sized datasets
Does not support reverse iteration natively
May consume more memory than standard sets when many duplicates exist
Original README
Original README snapshot from the linked source repository. Visit the repository for the latest content.
ordered_set
A simple implementation for an Ordered Set for Dart.
It accepts either a comparator function that compares items for their priority or a mapper function
that maps items to their priority.
Unlike Dart's SplayTreeSet or
SplayTreeMap classes, it allows for
several different elements with the same "priority" to be added.
It also implements Iterable, allowing you to
iterate the contents (in order) in O(n) (no additional overhead).
In order to assist the creation of Comparators, the Comparing class can be used:
// sort by name lengthfinal people = OrderedSet.comparing<Person>(Comparing.on((p) => p.name.length));
// sort by name descfinal people = OrderedSet.comparing<Person>(Comparing.reverse(Comparing.on((p) => p.name)));
// sort by role and then by namefinal people = OrderedSet.comparing<Person>(Comparing.join([(p) => p.role, (p) => p.name]));
Note that you could instead just create a MappingOrderedSet instead:
final people = OrderedSet.mapping<num, Person>((p) => p.name.length);
// ...
Mapping vs Comparing
There are two main implementations of the OrderedSet interface:
ComparingOrderedSet: the simplest implementation, takes in a Comparator and does not cache
priorities. It uses Dart's SplayTreeSet as a backing implementation.
MappingOrderedSet: a slightly more advanced implementation that takes in a mapper function
(maps elements to their priorities) and caches them. It uses Dart's SplayTreeMap as a backing
implementation.
In order to create an OrderedSet, however, you can just use the static methods on the interface
itself:
OrderedSet.comparing<E>([comparator]): creates a ComparingOrderedSet with the given
Comparator.
OrderedSet.mapping<K, E>([mapper]): creates a MappingOrderedSet with the given mapper
function.
OrderedSet.comparable<K, E>(): if E extends Comparable<K>, this is a simpler way of creating
a MappingOrderedSet with identity mapping.
OrderedSet.simple<E>(): if E extends Comparable<E>, this is an even simpler way of creating
a MappingOrderedSet with identity mapping.
Querying
You can [register] a set of queries, i.e., predefined sub-types, whose results, i.e., subsets of
this set, are then cached. Since the queries have to be type checks, and types are runtime
constants, this can be vastly optimized.
You can then filter by type by using the [query] method (or using [whereType]; which is overridden).
Note that you can change [strictMode] to allow for querying for unregistered types; if you do so,
the registration cost is payed on the first query.
Contributing
All contributions are very welcome! Please feel free to create Issues, help us with PR's or comment
your suggestions, feature requests, bugs, et cetera. Give us a star if you liked it!