I have been using Rx for over a month now and can’t even begin at telling how beautiful it really is and how much it has simplified my life especially working with UI declaratively and without having to worry about Dispatchers, threading etc., and I ended up rewriting most of the custom controls I have build over time to support Rx. And have been a big fan of Observable pattern and WeakEventListeners again had their own limitation which I always found a bit intimidating and for me Reactive Extensions became the way to go.

Enough of my expression of love for Rx and getting back to the actual blog post. Recently (before I started on Rx) in one of the projects, I was working on (WPF), I had to build a range selector, where the user can select the range by manipulating two sliders. The control was simple enough but then I encountered the problem in the application logic. I have had few very bad experiences with Slider control while creating a video player in good old days of Silverlight 2, and have learned a lesson (the hard way) of never doing long running operations (either async or sync) on any value that might change frequently and having to do sync operation and managing the threads/dispatcher. Well it was a deja vu and a trip to memory lane with long running process on value change of the slider (in this case range selector, well twice as bad). And the long running process was actually to long to turn a blind eye, and the only way out was to stabilise the value before processing long running operation.

Well it worked fine, apart from typical glitches which are common in any async programming scenario. But even though it worked pretty well, it was still a hack with again having to managing the events subscriptions and all that for memory leaks etc.,

When I encountered Rx I went back and the whole code was changed to a very simple extension method call, so the above scenario became,

This worked fine and all other async problem glitches were resolved using Rx again but this was resolved only because the there was an event that I was listening to, on the Price; and I was asking myself can we have observable properties instead of events that I can subscribe to?

Since the application logic was in a MVVM pattern and my ViewModel/Model implemented INotifyPropertyChanged interfaces, all my properties that I would be interested in observing already had an event that I can hook up to PropertyChanged, and I can do away with ValuesChanged event so the above scenario became,

This worked perfectly but to make the process of observing a property better and generic I added some Expression pixie dust, and some reflection love and have ended up with a helper method that would do it all for you,