ignlg
Handling asynchronous comparator
Is there a way to handle asynchronous custom priority comparator? If not, is such a feature planned for the near future?
Interesting idea, @federicospini . I will be more than happy to add it to the roadmap.
The feature could be: Heap.js should support a comparator that returns Promise<T>, awaiting the response before continuing the sorting algorithm.
Would this be enough? Do you have specific use cases?
I think that to support a comparator that returns Promise<T>, awaits the response before continuing the sorting algorithm should be enough. My use case: I have a stream of graph nodes. They arrive unsorted and with duplicates. I need to sort them and remove duplicates. Furthermore a node can be emitted iff all of its parents have been already emitted. Such a comparator call for asynchronous implementation since nodes can be millions and must be stored to the disk for testing duplicates and parents.
Cheers
Hi Ignacio, do you have any idea how long will it take for you to close this issue? Bye
Hello @federicospini, as I want to keep the sync core as efficient as possible, I have been sketching some ideas on how to add async functionalities without penalizing the performance. Hopefully I will find time to add it sooner than later.
Thanks for reaching out and sorry for the late reply.
Due to the profound implications of using an async comparison function, I made a fork of the Heap class called HeapAsync, which is independent. I haven't found an efficient way to handle both flows, sync and async, with the same codebase.
The implementation looks good. I am rewriting tests to adapt them to be async.
The main current pain point to migrate tests is the lack of Array.sort(), which is used widely to compare Heap internal states with an async comparison function.
The current branch of HeapAsync: feature/heap-async.
Please, @federicospini, if you could check that it works in your usage case, it would be super nice. I know this issue is quite old, so maybe you have lost interest already.
I will continue testing for a while and release it if there is no negative feedback about it, as it does not affect the original implementation in any way.