I was at the local Xamarin user group and the topic of Mvvm came up. One of the members was answering a question and stated that Prism was the only option for MVVM frameworks for Xamarin. After choking down my disgust, I chimed in refuting the statement and listed several MVVM frameworks that work with the Xamarin platform. Among them FreshMvvm, MvvmCross, MvvmLight and topped it off with ReactiveUI.
During that same meetup, I presented Sextant which is a Xamarin.Forms navigation library built on Reactive Extensions (Rx). A library created from a blog post by Kent Boogaart on Xamarin.Forms navigation services. While answering questions on Sextant, someone asked me "Why do I think Rx isn't more popular?". Watching the pitched softball, I grinned and prepared to knock it out of the park.
I believe that Rx is not popular in the C# community because C# isn't a functional language. Even though many recent platform features are making C# more functional, C# developers don't do functional. The reality is that Rx is hard, my experience has been that most C# developers don't do hard. The learning curve is steep, the chance for mistakes high, but the payoff is well worth the investment.
If you are a JavaScript developer in today's world. Things are more inherently reactive. JavaScript promises and other aspects of the language make the subscription to observable streams more palpable. That said, I think C# developers should learn how to model asynchrony as observables. It is a common practice in a lot of other languages and is a skill that will transcend language specific constructs such as the Task Parallel Library.
I went on record recently as stating that all MVVM frameworks are created equal. What I mean by this, you chose an MVVM framework based on the features that meet your business requirements and align with your technologies. For this reason, I don't believe any framework is really the "best". We make the right decision until we unlock some hidden platform feature that forces us to start making compromises and submitting to the will of the framework. Usually, at this point in a project, I start to second guess my life choices, while I struggle to make the framework do things the way I want.
The extensibility of a framework is a selling point for me. I prefer frameworks that have an opinion but allow me to push my opinions harder than theirs. I do believe that making a decision on a framework will potentially box your entire application into doing things the way that framework dictates. So if you can provide me with functionality in a microtized manner, allowing me to consume only the bits I want, then I will test the opinions and build an application my way.
I use ReactiveUI because I think that Functional Reactive Programming is a great paradigm for managing mutable state. If you have built a modern UI application recently, you will appreciate that responding to and managing changes in application state become increasingly more complex the more features you tack onto a screen. ReactiveUI doesn't really box me into doing things the "ReactiveUI way", but using the full power of the framework is predicated on the technology of Reactive Extensions. I can pick and chose how I build my application and add as much or as little Rx as I require.
I went home that night trying to answer the question "How do I make ReactiveUI more consumable without having to convert an application to ReactiveUI?" My first Xamarin.Forms project was built on FreshMvvm because it is a lightweight framework that isn't extremely opinionated. It was selected because it provided View Model navigation and constructor injection features.
The first thing I did when I got the chance was to rub some Rx on it. FreshMvvm uses a concrete object for it's ViewModel and subsequent navigation I couldn't easily just create a ReactiveObject
and make things work. Luckily for me, the creator of ReactiveUI believes in depending on abstractions and not concretions. I realized as long as I could extend from IReactiveObject
I could harness the power of ReactiveUI and not take all the opinions of ReactiveUI.
Opened Visual Studio. File new solution (or dotnet new if you are into that sort of thing), and a few hours of Google-Fu and Code Juijitsu later, ReactiveUI.Interop was born. This library was based on my original FreshMvvm implementation, expanded to MvvmCross and Prism.
I created ReactiveUI.Interop to leverage the platform goodness in ReactiveUI in the MVVM frameworks that other developers are comfortable with. This will allow developers to opt into ReactiveUI features that will enhance your View Models without having to convert your entire application to ReactiveUI. You can now use ObservableAsPropertyHelper
, this.WhenAnyValue
and more to construct view model logic in a reactive way.
So if you've heard about ReactiveUI and Reactive Extensions, but are too committed to the framework you know and love, give ReactiveUI.Interop a try. If your preferred framework isn't implemented, create an issue on the repository and lets work together to get you reacting to state change and winning the war against mutable state!
comments powered by Disqus