v8.3.1

housekeeping: ship v8.3.x (#1673)

v8.2.1

macOS

• Stefan Moonen contributed a patch that adds bind support to macOS for NSControls

Windows Forms

• Sebastian Richter contributed an epic changeset that closes off a bunch of long outstanding issues with Windows.Forms and ReactiveUI. We now ship ReactiveUI.Events.WinForms.

Where to get it

You can download this release from nuget.org

8.0.1

Elijah Reva noticed a net461 regression that affected Windows Presentation Foundation and Windows Forms. During the netstandard refactor we missed renaming a compilation symbol which resulted in PropertyChangedEventManager.DeliverEvent being used when setting reactive properties. WeakEventManager should not be used on these platforms and this hotfix disables it.

Thank you Elijah for sending in this the hotfix - check your email for an invitation to the GitHub organization!

As part of this release we had 8 commits which resulted in 3 issues being closed.

Windows Forms

• #1620 fix: disable WeakEventManager for net461 build (#1617)

Windows Presentation Foundation

• #1620 fix: disable WeakEventManager for net461 build (#1617)

Housekeeping

• #1626 housekeeping: resolve broken build due to NET45 compilation symbol
• #1625 housekeeping: pin xamarin.forms version used by eventbuilder

Where to get it

You can download this release from nuget.org

8.0.0

Hello ;-)

We never want to do a release this big ever again. A lot of time and effort went into this release from dedicated folks in the community.

One of the biggest factors in this release was that Microsoft changed their toolchain three times over and ReactiveUI was in the centre of that change. Dear Microsoft, never again please. We're happy with the end result however please take a peek out how the source code of ReactiveUI is now structured on the fileystem and how we multi-target multiple platforms using single projects and Directory.build.prop. Life for maintainers that target multiple platforms with dotnet is much better now than ever before. We were able to eliminate so much msbuild technical debt.

Big thank-you to Olly Levett who did the bulk of the conversion. Mate - you are like Mike Rowe - you did the dirty job and if you take a peek at Prism, MvvmCross and other upcoming projects you'll see that they followed your lead. Be proud of what you have accomplished.

Thank-you to Oren Novotony for your guidance, Immo Landwerth for your educational guidance on netstandard and David Kean who helped immensely with troubleshooting Visual Studio 2017 stability problems we encountered way back in the early days during this time of epic change. Rob Relyea please keep the communication channels open with the community because how we release software will be changing within the next month or so to a continuous delivery model. The ReactiveUI community has grown, we have new maintainers and our testing automation has matured to a point where will be releasing faster from this point onwards because we can. Consumers of ReactiveUI will no longer need to use our MyGet feed.

ICYMI - At MVP Summit, the community met with Microsoft and with their support and encouragement we forked control of System.Reactive. Head on over to this blog post for specifics as to what this means for the future of Reactive Programming on .NET.

You may or may not know this but ReactiveUI is maintained by unpaid volunteers. We put up a big marketing front but at its core is a couple of passionate folks. Open-source as it is today is unbalanced and broken. If you’re relying on open-source software for your business and you haven’t secured your supply chain, you’re negligent. For the longest time the software industry has talked about open-source software in the terms of user freedom, but we have never stopped to think about the cost. The cost is too high. Lana Montgomery, thank-you for sponsoring Geoff's attendance to LinuxConfAu where it was confirmed that this is indeed a cross ecosystem and industry wide concern.

It has been amazing and humbling experience seeing other maintainers of dotnet projects also come to the same realisation as us. Due to their observations they are now implementing measures to restore the imbalance of open-source software. For any maintainers still on the fence about this topic please open a conversation with us on our slack channel and we'll share with you ideas and guide you through your setup. ReactiveUI is now a vibrant community of developers from 22 timezones that supports the projects they depend on. Reactive programming in .NET is now financially subsidised to the tune of $7,580USD per year by community crowdsourcing and corporate sponsorship. We are on track to exceed $10,000USD by the end of 2018.

❤️ Thank-you for your support. What you have authored below is the essence of opensource. We do this stuff for others like yourself, we trade favours, we find things that annoys us & we fix it. Helping out transforms the relationship dynamic. If you have an idea, dig in and do it. https://t.co/uMPSqg9ex3

— 𝓖𝓮𝓸𝓯𝓯𝓻𝓮𝔂 𝓗𝓾𝓷𝓽𝓵𝓮𝔂 (@geoffreyhuntley) May 2, 2018

Thank-you to our backers who are making sustainable open-source a reality:

<img src="https://open...

7.4.0

As part of this release we had 8 commits which resulted in 3 issues being closed.

All Platforms

• #1336 fix: ViewModelViewHost memory leak
• #1298 fix: ViewLocator can now throw null reference exceptions

Windows Phone, Store and Universal

• #1299 fix: ViewLocator can't resolve views specified by UWP RoutedViewHost

Where to get it

You can download this release from nuget.org

7.3.0

As part of this release we had 17 commits which resulted in 17 issues being closed.

All Platforms

• #1325 fix: schedule output of ReactiveCommand.Execute
• #1317 refactor: removed unused extension method and make class internal
• #1306 refactor: use xunit IsType in unit tests

Xamarin Android

• #1302 feature: improved exception message when there are multiple resource IDs with the same name

Xamarin Mac

• #1259 bug: the assembly for Xamarin.Mac20 in the reactiveui-events NuGet package was not included

Housekeeping

• #1331 housekeeping: use [email protected] for all communication
• #1313 housekeeping: add table of contents with relative links
• #1326 housekeeping: add backers and sponsors from Open Collective

Documentation

• #1323 chore: tidy up ReactiveCollectionMixin xml comments
• #1322 chore: tidy up xml comments in PropertyBinding
• #1321 chore: tidy up xml comments in OrderedComparer
• #1320 chore: improved ObservedChangedMixin xml documentation
• #1319 chore: tidy up XMLDOC in ObservableAsPropertyHelper
• #1310 chore: tidy xml documentation for AutoPersistHelpers
• #1308 chore: tidy xml comments in RegisterableInterfaces
• #1307 chore: tidy up xml comment
• #1309 chore: fix xml doc referencing type with generic arguments

Where to get it

You can download this release from nuget.org

7.2.0

As part of this release we had 34 commits which resulted in 27 issues being closed.

All Platforms

• #1282 feat: a more flexible default view locator
• #1261 feat: allow interaction handlers of any observable type
• #1255 feat: add scheduling support to interactions
• #1283 fix: add UseInvariantCultureAttribute and apply to relevant tests
• #1274 fix: ensure synchronous command execution is lazy. Note that this is a potentially breaking change if your existing usage of synchronous commands is incorrect. See the issue for details.
• #1247 fix: catch exceptions from InvokeCommand
• #1244 fix: complete command execution only when pipeline completes
• #1235 fix: InvokeCommand targets ReactiveCommandBase, not ReactiveCommand
• #1289 perf: use shared, static observables to reduce allocations
• #1236 perf: remove superfluous AsObservable calls in ReactiveCommand
• #1269 test: add activation tests
• #1268 style: tidy up and expand comments in activation code

Xamarin Android

• #1250 feat: more flexible WireUpControls implementation

Xamarin Forms

• #1270 feat: synchronize ViewModel and BindingContext properties
• #1281 fix: assign VM from correct thread in RoutedViewHost

Housekeeping

• #1180 feat: enable unit test coverage/coveralls
• #1267 style: tidy up comments for binding code
• #1263 chore: failing to set the appveyor version should not be a fatal build error
• #1257 chore: resolved gitlink wasn't working because pdbs/xml were not included because of a packaging defect
• #1252 chore: rename MobileLifecycle.cs to SuspensionHost.cs
• #1238 chore: removed next-version definition

Documentation

• #1243 docs: delete docs folder
• #1198 docs: document pull-request merging guidelines/process
• #1197 docs: document release process for contributors

Where to get it

You can download this release from nuget.org

7.1.0

As part of this release we had 8 commits which resulted in 4 issues being closed.

All Platforms

• #1225 fix: reactiveui NuGet packages should be pinned and only work with packages from the same release
• #1218 fix: subscription leakage in ReactiveCommand

Xamarin Android

• #1217 feature: allow WireUpControls to find View members

Xamarin iOS

• #1216 feature: added generic reactive controllers and views for iOS and Mac

Xamarin Mac

• #1216 feature: added generic reactive controllers and views for iOS and Mac

Where to get it

You can download this release from nuget.org

7.0.0

Oh, hai!

Wow! It's been a while, but we have a juicy new release for you. We had to take some time to heal internally, to train and mentor the future generations of maintainers which are going to carry us forward. Additionally the .NET ecosystem changed underneath us, and we didn't have continuous integration setup. Let this be a lesson to anyone considering operating an open-source project that targets nine platforms. Have a roadmap and succession plan in place and never allow long-running branches, ever. Implement continuous integration and mature your release processes to the point where cutting a new release is as simple as pressing a button.

So what is ReactiveUI?

ReactiveUI is inspired by functional reactive programming and is the father of the ReactiveCocoa (Cocoa/Swift) framework. Internally we debate whether we are or are not a framework, as at its core the project is essentially a bunch of extension methods for the Reactive Extensions.

ReactiveUI was started seven years ago and is now old enough to attend grade school but unlike a teenager is extremely stable. ReactiveUI has matured over the years into a solid and fine choice for building your next application. Additionally, because the implementation is unopinionated migration from another framework to ReactiveUI is incredibly easy.. You can slide it in on a single ViewModel and then migrate as you become more comfortable. Avoid those costly rewrites.

When reading the code, you'll find that ReactiveUI is rather unopinionated in the implementation, but we have always held some beliefs which have been the basis and foundation of the project.

We believe that code is communication between people, that also happens to run on a computer. If you optimise for humans, then over a long time your project will end up better. Software should be understandable by other people; that is super important.

We believe that only the power of the Reactive Extensions allows you to express the idea around a feature in one readable place.

Think about your typical user interface? It's a mutable bag of sadness with code all over the place. Instead of telling a computer how to do its job, why not define what the computers job is and get out of its way? If that sounds odd, let us re-introduce you to Microsoft Excel.

Instead of doing the typical ViewModel isLoading = true/false mutable dance by toggling it on and off in different branches of your code. Why not express the condition in a single place using a Microsoft Excel expression - =SUM(A1: B2)?

Still not convinced?

• Why You Should Be Building Better Mobile Apps with Reactive Programming – Michael Stonis (Xamarin Univeristy Trainer/Eightbot)
• Awaiting for Rx: A Play in Four Acts - Paul Betts (Slack/GitHub)
• FRP In Practice: Taking a look at ReactiveUI/ReactiveCocoa by Paul Betts (Slack/GitHub)

Maybe you need to watch this insanely smart, and eccentric guy in a tie-dye t-shirt do maths on a whiteboard:

Async/await is the zombie plague. Liberate your codebase today.

ReactiveUI is used in production at GitHub, Slack, Microsoft and is supported by consultants from different companies from all around the world. It's used at our clients, we can't name names specifically, but we encourage our community to showcase where and how they have used ReactiveUI in their applications, some members have even gone as far as open-sourcing their app and sharing their entire codebase. You are of course under no obligation to share these insights (or code) with us but it is greatly appreciated by the project maintainers, and you'll usually get a retweet out of it.

Where are the examples?

We are working on it; this release was for us. Next release is for you. For now:

• Read https://docs.reactiveui.net/en/fundamentals/history.html
• Watch the guest lecture over at Xamarin Univeristy
• Watch this god damn amazing video series by Kent Boogaart (one of the core maintainers)
• Play with the Xamarin University lecture source code. (Xamarin Forms)
• Play with the GitHub for Windows Visual Studio source code. (WPF)

Rx is hard

No, it's not. Learning Rx is one of the best things you can do to improve yourself as a software engineer. Unit testing was hard, so was dependency injection at first. The principals you learn during your journey will forever change you and best of all the knowledge is implementation and language agnostic. We have designed ReactiveUI so you can slowly transition from an async/await codebase at a pace that feels comfortable to you.

Highlights

ReactiveCommand is Better

ReactiveCommand is completely rewritten again (sorry).

• interfaces are gone. Any use of IReactiveCommand should be replaced with ReactiveCommand, possibly with type information (see below).
• static creation methods have changed:
  • execution logic is always required when calling CreateXxx methods, including synchronous commands (i.e. those created with Create). So rather than calling Create and then subscribing, you call Create and pass in your execution logic right then and there.
  • for consistency, the execution logic is always provided as the first parameter. Other parameters (canExecute, scheduler) are optional.
  • CreateAsyncObservable is now called CreateFromObservable.
  • CreateAsyncTask is now called CreateFromTask.
• parameter types are formalized by TParam in ReactiveCommand<TParam, TResult>.
  • if your command takes a parameter, you no longer take an object and cast it. Instead, you explicitly specify the parameter type when creating the command (of course, you can still choose object as your TParam if that makes sense, perhaps as an intermediary migration step).
• ICommand is now implemented explicitly. As a result:
  • the Execute exposed by ReactiveCommand is reactive (it returns IObservable<TResult>). It is therefore lazy and won't do anything unless something subscribes to it.
  • CanExecuteObservable is now called CanExecute.
• observables such as CanExecute and IsExecuting are now behavioral. That is, they will always provide the current value to new subscribers.
• RoutingState has been updated to use the new implementation. Consequently, any use of its commands will be affected per the above.
• the ToCommand extension method has been removed. This was a simple convenience to take an IObservable<bool> and use it as the canExecute pipeline for a new command. If you're using ToCommand, you can just replace it with a call to one of the creation methods on ReactiveCommand.

Old:

var canExecute = ...;
var someCommand = ReactiveCommand.Create(canExecute);
someCommand.Subscribe(x => /* execution logic */);

var someAsyncCommand1 = ReactiveCommand.CreateAsyncObservable(canExecute, someObservableMethod);
var someAsyncCommand2 = ReactiveCommand.CreateAsyncTask(canExecute, someTaskMethod);

someCommand.Execute();

New:

var canExecute = ...;
var someCommand = ReactiveCommand.Create(() => /* execution logic */);

var someAsyncCommand1 = ReactiveCommand.CreateFromObservable(someObservableMethod, canExecute);
var someAsyncCommand2 = ReactiveCommand.CreateFromTask(someTaskMethod, canExecute);

someCommand.Execute().Subscribe();

For more details, please see the extensive documentation on this topic.

Note To enable you to ease into the migration, all previous types are available under the ReactiveUI.Legacy namespace. Note, however, that there is no legacy version of RoutingState, so any code you have that interacts with its command may require minor updates.

Interactions are New and Exciting

UserError has been generalized and re-imagined. We call it interactions, and we think you'll like it. We did this in part because people were feeling icky using UserError for non-error scenarios. Basically, we realized that people need a general mechanism via which a view model can ask a question, and wait for the answer. It doesn't have to be an error - we're not that pessimistic! You could be asking to confirm a file deletion, or maybe how the weather is out there in the analog world.

Migrating from UserError to the interactions infrastructure is not really a case of one-for-one substitution. But here are some tips to get you started:

• read through the documentation first.
• decide whether you need shared interactions and, if so, define them in an appropriate place for your application (often just a static class).
• for any non-shared interactions, have your view model create an instance of the interaction and expose it via a property.
• typically you want the corresponding view to handle interactions by calling one of the RegisterHandler methods on the interaction exposed by the view model.
• the view model can call Handle on the interaction, passing in an input value.
• Recovery commands are no longer a built-in thing. If you need such a mechanism for your interactions, you are encouraged to write an appropriate class and use it as the input for your interaction.

Note To enable you to ease into the migration,...

6.5.2

This release resolves a NuGet metadata defect which was preventing the installation of ReactiveUI into Windows Phone projects (issue #1146). The assemblies within v6.5.2 are the same as those found in v6.5.1 and v6.5.0.

For new projects, we recommend joining us in Slack and using the v7 nightlies which are available from MyGet as we are in the final stages of preparing for the release of v7.0.0.