To explain the idea behind ReactiveCollections, let's look at this completely ficticious conversation between Alice and Bob:
Alice: Well, what's ReactiveCollections ?
Bob: Glad you ask. Do you know Reactive Extensions ?
Alice: Of course, it's a framework to model and compose asynchronous events. Great stuff by the way.
Bob: It is. But I like to see Rx as a way to model change over time.
Alice: What does change?
Bob: Whatever you like, for example the state of some variable in an object.
Alice: I see. So, ReactiveCollections uses Rx to notify about the state of some collection? Isn't that just like an ObservableCollection? There's a CollectionChanged event on it, couldn't we just use that?
Bob: Yes and no. See, an ObservableCollection still uses an internal mutable state to represent its current content.
Alice: Why is that bad?
Bob: You have to synchronize access to it. You have to lock the collection every time you read or write to it.
Alice: Oh that's ok, I just put lock(items) everywhere and I'll be fine.
Bob: You could just do that. But blocking is so uncool in times of async/await. Moreover, are you really going to block your UI-thread? And why wouldn't you want to allow mutiple readers.
Alice: There's always ReaderWriterLock...
Bob: ...and it's fun to share ReaderWriterLock instances between readers and writers throughout your whole application.
Alice: No it's not. So, I guess that's where Immutable Collections come into play.
Bob: Yes! While we model change of state in a collection with Rx, Immutable Collections model the state itself! And whenever you got hold of some current state of some collection, you can do with it what you want - it's immutable, you cannot break anything.
Alice: So, let's say I need a simple list in my application...
Bob: ...just create one:
var list = new ListReactiveCollectionSource().
Alice: ListReactiveCollectionSource? What's Source?
Bob: It's like TaskCompletionSource or CancellationTokenSource. You basically have a ReactiveCollectionSource that you use to modify the collection...
Alice: ...and like a CancellationTokenSource, ListReactiveCollectionSource has a property that I can give out to consumers of the list?
Bob: Exactly:
var list = new ListReactiveCollectionSource();
var rc = list.ReactiveCollection;
Alice: As I see, rc implements an IObservable of something. What happens if I subscribe to it?
Bob: Your observer will be notified of the current state of the list immediately, which is an ImmutableList in this case.
Alice: Cool. And since it's just an asynchronous sequence of ImmutableLists, I may as well just skip the first state if I'm only interested in the second...
Bob ...yes...
Alice ...or take the first 5 changes in a list...
Bob ...yes...
Alice ...and await it...
Bob ...absolutely.
Alice I see there's more in Immutable Collections: ImmutableDictionary, ImmutableSortedList...
Bob: ...and there's corresponding clases in ReactiveCollections.
Alice: What if I wanted to filter, project or sort such a ReactiveCollection. You know, like in LINQ.
Bob: You can!
Alice: So, that's all good, but at the end of the day, I have to display my filtered, projected and sorted collection in my cool new app. But my UI only can bind to a good old ObservableCollection.
Bob: Just call
var oc = list.ToObservableCollection
to your ReactiveCollection and you'll be there.
Alice: Now I want to clone this repository and start playing with it.
Bob: Go ahead, thanks for your interest!