Ship ReactiveUI 7.0 #850
Ship ReactiveUI 7.0 #850
Conversation
|
#802 is a Neato Thing(tm) |
|
It would be nice to get #769 fixed. I've not managed... |
|
Let's include the burning of
See also issue #710 |
|
It'd be nice if the user could pull in some of the core magic of RxUI without any of the fluf. Perhaps this is wishful thinking on my part, but a slimming down of RxUI core would ease integration with other MVVM frameworks, and even make it easier to provide a .Net 4.0 release for those of us stuck supporting WinXP clients. I was thinking the core features would be:
Things not included in this core:
Note I have used both RxUI 6.0 and 4.0 recently and I may have some features confused between them. Please excuse me if I listed some things that are no longer included in the main RxUI library. |
|
👍 I've more than once wanted to use some of the RxUI bits in completely non-UI scenarios, but didn't want to add the extra dependencies. |
|
👍 Great idea @kmcginnes |
|
@kmcginnes Removing Splat isn't possible because RxUI itself relies on Splat to implement the features you mention in the Core list (especially WhenAny). I think this problem indicates a perception / education issue than an actual code issue - if you don't want to use any of the features in the "not included" list, you can just completely ignore them, none of them are forced on your application. |
|
Any thoughts on implementation of a new validation model/approach, a modern day successor to ReactiveValidatedObject. |
|
Edit: So I'm totally embarrassed. I wrote this long rant out of some pain I was experiencing, but if I would've read just a little bit more about the actual issue (extension method name conflicts) I would've found that if my extension method is at the root of my app's namespace it will be chosen before those outside the namespace. @paulcbetts So my suggestion was actually a really big complaint wrapped up along side some other smaller complaints I had. I've had this similar issue in other libraries/frameworks. In ReactiveUI there is an extension method witch is phenomenal on its own, but conflicts with how I want to use it. Creating my own extension method, at least with the same name, is now out of the question in classes that include the ReactiveUI namespace. That extension method is This concept was introduced by Rob Reynolds in early 2013. I'm not sure who predated whom, but I learned it from Rob. It has become such a hit with me that I use a custom version of it in all my apps. However, when using ReactiveUI, if I'm in the view model or view I can't use my custom So my original intent with the suggestion to create a ReactiveUI core was to reduce the possibility of ReactiveUI opinions leaking out into it's consumer's code bases. This might've been fine in the first few releases, but as the user base grows this becomes a bigger and bigger issue. While NuGet is far from perfect, it does allow for the easy consumption of optional additions to a library. Therefore giving the choice to the user, rather than including everything that a user may possibly use in a single package. I hope this rant wasn't too, uh, rant-y. I just had to get that off my chest. |
|
@kmcginnes Nope, ReactiveUI had this almost exact API a full two years before that article came out :) ReactiveUI/ReactiveUI/Logging.cs Line 78 in b00354d |
|
Let's include #599 as well? |
|
How do you guys feel about finally dropping the ReactiveUI-Mobile and ReactiveUI-Platforms packages? They were deprecated for v6 (or earlier?), so they just muddy up the waters now. |
|
@moswald 🔥 🔥 🔥 |
|
🔥! |
|
How would everyone here feel about closing down the addition of new features to RxUI 7 after a particular date. ie. define scope, prevent increase and define release theme.
For example I know Kent wants to have a stab with someone else as well at potentially looking at improving routing but that's definitely a v8 feature. Let's get them all out on the table now, eventually we need to cut a release but that date doesn't need to be specified but we do however need to define in/out of breaking changes :-) |
|
Dates don't work for me (and probably never will on open source work), but agreeing on features and fixes does. PS. some features I want are in Splat (sane logging, in particular). |
|
A cut-off date for breaking changes is useful. Provides some certainty to users and allows us to drop all those warnings off the documentation. We are all volunteers here and contribute where we can. It's already a second job in itself and deadlines suck the spirit out of it. With that in mind the I've had a date in my own mind as a "it would be nice to have v7.0" by Evolve - 24th of April which is three months away. That's been my own personal milestone and marker for pace, it doesn't have to be yours. That's totally okay. There is a "Why you should be building better mobile apps with reactive programming" talk and it would be a nice present to the presenter and great marketing to have a RC by that date. RC basically means no more breaking changes (ie. redesigns of fundamentals) until v8. We should be able to come to a definition of that. Everything else from that point forward is just rolling packages off master. |
- newlines between arches and platforms, to make future editing easier - fixed nuget.exe path - quieter msbuild - quieter file/folder operations - using `get-childitem` instead of `ls` alias, as that is sometimes redefined - printing any errors found before packaging results - output nuget packaging to `./artifacts`
run unit tests as part of continuous integration pipeline
Add interactions to UWP project.
Use non-generic BindableProperty.Create.
Fix InvokeCommand to respect execution window
Throw specific exception when pipeline fails.
Remove BindCommand implementation taking Func<TParam>.
Use ViewWillAppear for iOS activation
…/microsoft-reactive-testing (#1185)
… that code is codegened (#1187) reduces spam in the CI build log
…r|Minute] (#1186) .Current[Hour|Minute] has been obsoleted.
This is the main
PR for what will become ReactiveUI 7.0
Features / TODO: