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?

Mesognathous

If all the concerns you post are valid (ie that is really how Rx is done) then by just reading the concerns you post, I'd say: don't use it for actual production code. Or extract and refactor just the parts you need. – Leptospirosis

I'm happy with it, though I haven't released code into Production yet. I agree on your concerns with 2), those of us using it probably need to jump in there. On 4, we were using Caliburn with RXUI, but have since stopped, but I don't see anything from MVVM Light that I don't prefer or find the RXUI way acceptable. I don't think you'll find it hard to use MVVM Light with it. – Afflux

A production use of RXUI is GitHub for Windows windows.github.com – Afflux

The title question feels like a bit of a troll... – Murderous

@Cameron: WTF? How do you suggest I ask this legitimate question? Your comment sounds more trollish to me. – Mesognathous

@KentBoogaart I simply meant based on the title question alone I'd have trouble deciding to close this as either not constructive because it would cause debate, or too localized as it only applies to the current version of RxUI. As far as trolling, I don't know. It just feels like you're trying to pick a fight with that question. It feels confrontational. – Murderous

google.com.au/… would suggest that this wording is pretty standard. – Singleness

That would be a "YES" from @KentBoogaart: github.com/reactiveui/ReactiveUI/commits?author=kentcb – Singleness

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".

Barreto

Thanks Paul - this helps a lot! And kudos for your efforts with ReactiveUI. – Mesognathous

Having spent some time looking at the samples and further evaluating things, I think the main sticking points are the integration with my existing infrastructure (MVVM Light and MEF) and the lack of docs. Regarding the former, I am concerned mainly because there will be multiple ways to do things (such as log, send messages, resolve services). I already have services in place and a way of resolving them (MEF), but now it will be possible for reactive view models to do things differently. Not the end of the world, but it leaves the code base more open to bifurcation. – Mesognathous

Sry, another thing: any reason not to sign your assemblies? This has created a lot of friction for me. I used ILMerge to sign, but then found a dependency on System.Threading.Tasks (which I thought was obsolete). I had to get said assembly from github in order to sign with ILMerge. All this done behind a very restrictive corporate firewall, resulting in wasted hours. The corporate bureaucracy is not your problem, I know. However, the "done thing" with libraries is to sign them so that other signed assemblies can depend on them, so am hoping I can convince you...google groups also blocked here. – Mesognathous

Also, there's no CLSCompliant(true) on your assembly, which causes problems for any CLS-compliant code depending on it. – Mesognathous

Sorry, we'll never be CLS Compliant or sign assemblies, it's too big of a waste of time for contributors (especially signing). Signing means that everyone who opens the Solution from scratch ends up with build errors. – Barreto

Also, if you have any questions that are longer than this comment box, definitely email me, [email protected] – Barreto

@Paul Betts, you've done an amazing job with ReactiveUI. Thanks for providing this to the commmunity. – Telic

Answer 2

I am answering as someone who has used ReactiveUI in a few production systems, has had issues with the way RxUI does stuff, and has submitted patches to try and fix issues I've had.

Disclaimer: I don't use all the features of RxUI. The reason being I don't agree with the way those features have been implemented. I'll detail my changes as I go.

1. Naming. I thought this was odd too. This ended up being one of the features I don't really use. I use PropertyChanged.Fody to weave in the change notification using AOP. As a result my properties look like auto properties.

2. Doco. Yes there could be more. Especially with the newer parts like routing. This possibly is a reason why I don't use all of RxUI.

3. Logging. I've had issues with this in the past. See pull request 69. At the end of the day I see RxUI as a very opinionated framework. If you don't agree with that opinion you can suggest changes, but that's all. Opinionated does not make it bad.

4. I use RxUI with Caliburn Micro. CM handles View-ViewModel location and binding, Screen and Conductors. I don't use CM's convention binding. RxUI handles Commands, and ViewModel INPC code, and allows me to react to property changes using Reactive instead of the traditional approaches. By keeping these things separate I find it much easier to mix the two together.

Does any of these issues have anything to do with being production ready? Nope. ReactiveUI is stable, has a decently sized user base, problems get solved quickly in the google group and Paul is receptive to discussion.

Murderous

Thanks for your input (+1). However, I strongly disagree that this has nothing to do with production-worthiness. The product I am working on will one day be in maintenance, so I am obliged to consider the maintainability of that code. It won't be me (as a contractor) maintaining the code, so it's even more difficult to justify the inclusion of a framework that is poorly documented or imposes inconsistencies in the code base. – Mesognathous

@KentBoogaart I see your point. My counterargument would be that the same things (stability, active user base, etc.) would also help any future maintainers. Also, why are you considering RxUI? What feature does it give you that you want? – Murderous

yeah, exactly. It's this trade-off that I'm agonizing over: Potentially simpler code, but at the cost of a more complex API surface and dependencies with poor documentation. The main features I think I'll be using (at this point at least) are around filtering live collections and reacting to external data changes. I'm currently in the process of just trying to get RxUI into my code base so I can try it out with 1 view model. It's proving difficult though, what with unsigned assemblies and no CLSCompliant attribute. – Mesognathous

@KentBoogaart Was that comment about unsigned assemblies and lack of CLSCompliance aimed at RxUI? – Murderous

yeah. My code base is signed and has CLS compliance, uses Code Analysis, et cetera. So the lack of these things in RxUI is causing headaches. – Mesognathous

Answer 3

I use it in production and so far RxUI has been perfectly stable. The application has had problems with stability, some to do with EMS, others with an UnhandledException handler that was causing more problems than it was solving, but I've not had any problems with the ReactiveUI part of the application. However, I have had issues regarding the ObservableForProperty not firing at all, which I may have used incorrectly and did work consistently (incorrectly) in my test code as well as in the UI at run time.

-1. Paul explains that the _Upper is due to using reflection to get at the private field in your class. You can either use a block such as below to deal with the StyleCop and Resharper messages, which is easy to generate (from the Resharper SmartTag)

    /// <summary>The xxx view model.</summary>
    public class XXXViewModel : ReactiveObject
    {
    #pragma warning disable 0649
    // ReSharper disable InconsistentNaming

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private readonly bool _IsRunning;

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private string _Name;
    ....

or change your properties from the full

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _IsSelected; }
        set { this.RaiseAndSetIfChanged(x => x.IsSelected, value); }
    }

to its component parts such as

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _isSelected; }
        set 
        { 
            if (_isSelected != value)
            {
                this.RaisePropertyChanging(x => x.IsSelected); 
                _isSelected = value;
                this.RaisPropertyChanged(x=>x.IsSelected);
            }
        }
    }

This pattern is also useful where you don't actually supply a "simple" property accessor, but may require a more derived variant where setting one value affects multiple others.

-2. Yes the documentation isn't ideal but I found that after Rx, picking up the RxUI samples was quite easy. I also note that the jumps from 2->4 seem to have all come with the changes to support Windows 8/Windows 8 Phone, and having picked up ReactiveUI for a Windows Store App then the DotNet 4.5 support is excellent. i.e. use of [CallerName] now means that you simply this.RaiseAndSetIFChanged(value) no need for the expression.

-3. I haven't any feedback on the logging side as I've not elected to use it.

-4. I've not mixed and matched with others frameworks either.

There's also a list of other contributors to ReactiveUI 4.2 at http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/, including Phil Haack.

Ries