SortedView in 3.x

[erri120]

Sorted views used to exist in 2.x (https://github.com/Cysharp/ObservableCollections/tree/2.2.2) but got removed when moving to 3.x. How should sorting be done in 3.x if you want similar behavior to sorted views in 2.x?

[dsisco11]

I would also like to know, this project has no documentation other than the README which leaves us with very little information.
The 3.x update changed the README to remove references to sorted views and added mentions of sorting related to ObservableList, but there isn't any information about the correct way to use this new sorting functionality compared to the old sorted view system.

Am I supposed to add change event hooks to every observable list and then call list.sort() for each change event?
I have doubts because resorting after every change sounds like a potential performance problem...
But If that strategy is what's expected, then why weren't we also given a class that automatically implements this setup?

The real issue here is just communication.
We had a big feature (sorted views) removed and weren't given any information about how to migrate to the system which replaced them.

[neuecc]

I apologize for removing functionality due to significant changes.
When modifying the internal architecture to be notification-based,
we determined it was impossible to create generic index and filter functionality for SortView, so we removed it.
While it's still possible to create application-specific implementations,
I believe you can prepare your own SortedView from notification events.

[dsisco11]

I am currently working on a sorting view class but the provided synchronized-view interfaces make it very hard.
ISynchronizedViewList<T> doesn't expose any of the events for the underlying collection, was this an accidental oversight?

Another problem is that the only other generic interface we are given is ISynchronizedView<T, TView>, and while this exposes the events it also requires always knowing both types, which makes it impossible to use in some contexts.
Can we get some more isolation within the interfaces?

I think adding another interface like ISynchronizedCollection<T> to just expose the eventing would suffice.
Or you might alternatively separate the type casting functionality from ISynchronizedView<T, TView> into an interface named something like ITransformingView<TSrc, TView>, then revert ISynchronizedView<T, TView> back to ISynchronizedView<T>.