3

I am in the process of learning ReactiveUI and so far I love it but I now realise that the framework encompasses XAML (i.e. the view layer) as well, offering things like ReactiveUserControl and ReactiveView.

Why do I need, or want these? System.Reactive/ReactiveUI offer massive advantages on the Model/ViewModel side but what are the advantages on the View side, again, in the context of a WPF app? Unit testing perhaps?

Note: I like WPF, I like its data binding. All my XAML bindings are strongly-typed and easy to refactor, customise, re-skin, debug and whatnot. I learned to use but not over-use the converters so never have a prob with those either. I never felt a need to override the UserControl class. With that said, I never had a problem with the WPF itself.

If I decide to use the IVIewFor<T> implementations, will my XAML designer go nuts? Will I lose anything? Will I end up debugging memory leaks, UI stutter and strange CPU spikes? We'll be making a very large app so we go by the 'better safe than sorry' principle as we were burnt by the CAB framework before.

If I decide against, what benefits of the ReactiveUI will we lose? Would I be heathens for doing this, or is it more of an optional aspect of the framework?

So far I understand the benefits in case of WinForms or Android (it offers binding support as I understood) but not WPF. While it sure does have its quirks, I don't feel the need for another framework on top of it.

bokibeg
  • 2,081
  • 16
  • 23
  • 1
    Way too many questions in one post! – Nawed Nabi Zada Feb 13 '19 at 13:56
  • @Nawed I understand but all the sub-questions are just meant to provide an insight into information I feel is relevant to the potentially broad topic of "the purpose of `IViewFor`". Most I could find (including the docs) was 'it makes views reactive' which doesn't address any of the concerns I mentioned in my question. – bokibeg Feb 13 '19 at 15:19
  • 1
    To address some of your other concerns, implementing IViewFor itself won't cause any XAML designer issues. If you use ReactiveUserControl it can just due to the XAML designer not liking generics but that class is really optional and there are talked about ways of handling that in the docs. Memory leaks we address in our docs, DependencyProperty are notorious hence the WhenActivated mechanism. – Glenn Watson Feb 13 '19 at 17:28
  • 1
    Also this is MVVM framework is primarily focus on multiple platform support including Mobile. So everything is extremely lightweight and memory conscious. Eg our service locator is fairly dumb compared to other frameworks but it's also fast/low memory impact. Also we very much focus on opt in what you want don't take what you don't want. – Glenn Watson Feb 13 '19 at 17:30

1 Answers1

2

You would implement IViewFor<T> when you for example want to set up bindings in the view and when you want to handle activation and deactivation, e.g.:

this.WhenAnyValue(x => x.ViewModel.Name).BindTo(this, view => view.Name.Text);

this.WhenActivated(d => { /* do something */});

These methods are implemented as extension methods. Please refer to the docs for more information and examples:

https://reactiveui.net/docs/handbook/data-binding/ https://reactiveui.net/docs/handbook/when-activated/

Of course you don't have to use all features of ReactiveUI. It's perfectly fine to set up bindings in the XAML markup as usual and still bind to ReactiveObjects.

mm8
  • 163,881
  • 10
  • 57
  • 88
  • Thanks for the answer, hmmm yes I like `WhenActivated` very much in VMs.... I will check it out on the view side. – bokibeg Feb 13 '19 at 15:10
  • 1
    The other common use case is Navigation https://reactiveui.net/docs/handbook/routing/ -- IViewFor is used to determine which View matches for a ViewModel. – Glenn Watson Feb 13 '19 at 17:23