Splitting the reactive elmish to a separate library

[kgday]

Have you considered splitting out the core reactive elmish from the wpf and avalonia dependencies, into another package? Then one could use a f# libray with a c# blazor and reactiveui as per reactiveui examples for a web assembly application.

[JordanMarr]

Yes, I have considered doing that a few times. That's why I split out the core library into its own project.
I am currently working on a C# WPF project and so I started to create a WPF port.

A few things prevented me from continuing:

Splitting out the core project into its own NuGet package made it more difficult to work on and debug. (I did work around this issue by including the core dll into the Avalonia as part of the same package though.)

When I attempted to use the ReactiveElmishViewModel from C#, I realized that all of the Bind methods used F# arrow function, which meant that C# would need to convert them, which sucks. I thought about changing them to use Action and Func natively, but I just felt too prejudiced against the idea to continue.

I even made a separate branch where I experimented with converting the Bind methods into extension methods so that they could be easily consumed in C# WPF projects where there is almost always an existing ViewModelBase. But I think the thing that has stopped me in all of these cases is that I didn't feel like bastardizing the codebase in these ways just to accommodate usage from C#.

But yes, I have definitely thought about doing it.

[kgday]

So was this creating the ViewModel in c#, or creating the ViewModel in F# and using the ViewModel from c#?

[JordanMarr]

I wanted to use the view model from C#.

[kgday]

I am not sure I understand. If you a creating the view model in F#, what C# would see is just ordinary read or read / write properties would it not?

[JordanMarr]

My current project is C# + WPF. I wanted to be able to inherit from the ReactiveElmishViewModel in my C# project so that I could utilize the various Bind functions.

But the Bind methods all utilize F# function parameters, not Action and Func. So that means I would either need to use converters (which would look terrible), or I would need to change all the Bind methods to use Action and Func, which I am resistant to doing for aesthetic reasons and my own prejudices against C# in general.

It's kind of a non-reason, really.

But all of this outlines another reason that makes me hesitant to go down this path:
Opening up the library for multi-use would further obfuscate the purpose of the library. When the elevator pitch becomes too complicated to explain in 10 seconds, potential users will dwindle. Multi purpose for different frameworks (and maybe cross language) would also multiply any work times the number of platforms. All of this has been stacking to put me off on the idea, despite the fact that it is a logical next step and it probably is a good idea.

With that said, I'm not totally against it -- just hesitant to move forward.

[kgday]

My preference would be to write the view models in F#. I would just prefer to handle as much of the core functionality of an application using F#. Like you, I just like to work in F# as much as I can. The original Elmish.WPF was used that way too, because you had to.

[wangjian30]

Could you give some example ? I prefer to write the view models in F# too, I tried some code use the similar way like Elmish.WPF, but it did not work!

[JordanMarr]

@wangjian30
All of the examples on the README use F# for everything.

[wangjian30]

Yes, But they use Avalonia, And I want use WPF.

[JordanMarr]

You can use https://www.nuget.org/packages/ReactiveElmish.Wpf

[JordanMarr]

ReactiveElmish is published as a beta:
https://www.nuget.org/packages/ReactiveElmish/

Now you can even utilize the next bindings from within an existing ViewModelBase (since most projects already use one):

[kgday]

Wow, well done.