RFC: Nuget Packages confusing to users with separate platforms about rfcs HOT 4 OPEN

@worldbeater did a fantastic job updating our nuget overview page, but I really had to dig to find it. Plus his getting started page wasn't obvious. We need the documentation first page to kind of put this in your face.

https://reactiveui.net/docs/getting-started/installation/nuget-packages/
and
https://reactiveui.net/docs/getting-started/

NuGet Packages

ReactiveUI is a composable, cross-platform model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming which is a paradigm that allows you to express the idea around a feature in one readable place, abstract mutable state away from your user interfaces and improve improve the testability of your application.

Getting Started

ReactiveUI is a composable, cross-platform model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming which is a paradigm that allows you to express the idea around a feature in one readable place, abstract mutable state away from your user interfaces and improve improve the testability of your application.

from rfcs.

AS mentioned by @matthewclendening Kent's book still references the pre Rx 8 information of the bait and switch for WPF etc. How do we get the setup process easier for users?

One proposal are Visual Studio Templates to make it easy to setup different Rx packages with recommended practices (eg a .NET Standard library etc) and some practice code. I know @RLittlesII has been working on this a bit in his spare time.

from rfcs.

This may be just (or partially) a documentation thing. I actually started off yesterday installing the ReactiveUI.WPF package - when that didn't work I started digging. Installing just that single package today (with v8.4.1) does the right thing and works seamlessly.

from rfcs.

I think the System.Reactive 3.1.1 issue was a special snowflake. Granted I don't know how we ensure these things don't happen in the future. We will always be dependent on packages that may or may not play nice together.

I still think some documentation per platform to tell you which packages are required to get up and running is a step in the right direction.

Templates I think should be the ultimate goal of this effort. But that has it's own challenges like maintenance, i.e. cutting a template per packages release. No worst feeling than downloading someones template, and then having to manage the package, and paradigm updates yourself before you can use the latest features. Simply defeats the purpose of convenience the templates provide.

from rfcs.