Is ReactiveUI Production Ready?

Question

I've been looking into the feasability of using Reactive UI in production code. Some of the features are really appealing, but I have concerns about taking a dependency on this library. These include:

1. Whacky naming and conventions. For example, protected members starting with lower case, and the RaiseAndSetIfChanged method depends on your private member beginning with an underscore. I understand Paul Betts (ReactiveUI author) has a Ruby background, so I guess that's where the odd naming stems from. However, this will cause a real issue for me, since standard naming (as per Stylecop) is enforced throughout my project. Even if it wasn't enforced, I'd be concerned by the resultant inconsistency in naming that this will cause.

2. Lack of documentation/samples. There is some documentation and a lonely sample. However, the documentation is just a series of (old) blog posts and the sample is based on V2 of the library (it's now on V4).

3. Odd design, in parts. For example, logging is abstracted so as not to take a dependency on a specific logging framework. Fair enough. However, since I use log4net (and not NLog) I will need my own adapter. I think that will require me to implement IRxUIFullLogger, which has a metric crapload of methods in it (well over 50). I would have thought a far better approach would be to define a very simple interface and then provide extension methods within ReactiveUI to facilitate all the requisite overloads. In addition, there's this weird IWantsToRegisterStuff interface that the NLog assembly depends on, that I won't be able to depend on (because it's an internal interface). I'm hoping I don't need that...

   Anyway, my concern here is the overall design of the library. Has anyone been bitten by this?

4. I'm already using MVVM Light extensively. I know Paul did a blog post where he explains you can technically use both, but my concern is more around maintainability. I suspect it would be horribly confusing having both intermingled in one's code base.

Does anyone have hands-on experience with using Reactive UI in production? If so, are you able to allay or address any of my above concerns?

Answer 1

Let's go through your concerns piece by piece:

#1. "Whacky naming and conventions."

Now that ReactiveUI 4.1+ has CallerMemberName, you don't have to use the conventions at all (and even then, you can override them via RxApp.GetFieldNameForPropertyFunc). Just write a property as:

int iCanNameThisWhateverIWant;
public int SomeProperty {
    get { return iCanNameThisWhateverIWant; }
    set { this.RaiseAndSetIfChanged(ref iCanNameThisWhateverIWant, value); }
}

#2. Lack of documentation/samples

This is legit, but here's some more docs / samples:

• http://docs.reactiveui.net/ (this is the official ReactiveUI documentation, a work in progress but definitely where you want to start)
• https://github.com/reactiveui/ReactiveUI.Samples
• https://github.com/reactiveui/RxUI_QCon
• https://github.com/play/play-windows

#3. "I would have thought a far better approach would be to define a very simple interface and then provide extension methods within ReactiveUI to facilitate all the requisite overloads"

Implement IRxUILogger instead, it has a scant two methods :) ReactiveUI will fill in the rest. IRxUIFullLogger is only there if you need it.

"In addition, there's this weird IWantsToRegisterStuff interface "

You don't need to know about this :) This is only for dealing with ReactiveUI initializing itself so that you don't have to have boilerplate code.

4. "I suspect it would be horribly confusing having both intermingled in one's code base."

Not really. Just think of it as "MVVM Light with SuperPowers".