Elmish.wpf: Update to latest Elmish?

[dsyme]

I notice the Elmish program.fs/cmd.fs are out of date by about 6 commits, and it looks like a fair bit of work is going on in Elmish to make the fable stubs unnecessary. e.g. https://github.com/fable-elmish/elmish/commits/master

Are there plans to update to the latest Elmish?

https://github.com/fable-elmish/elmish/commits/master

Thanks!

[2sComplement]

Yes, definitely! Just haven't gotten around to it.

[dsyme]

@2sComplement OK thanks.

Context is that I'm looking at making an Elmish.XamarinForms in fsprojects that keeps up-to-date with the Elmish.WPF programming model (the old Elmish.Forms sample is getting a bit out-of-date)

[dsyme]

@2sComplement Is there a particular place where to discuss Elmish.WPF and Elmish.XamarinForms? Thanks.

[2sComplement]

I actually didn't know about Elmish.Forms until your previous comment. Ideally we wouldn't need separate libraries and would just plug in the view implementation on the fly. I haven't used Xamarin much so I don't know how feasible this is. From a brief glance, not much looks different in Elmish.Forms. Perhaps Elmish.Forms could be a separate package containing its runPage function (and other necessary overrides), and the core could still be part of Elmish.WPF. Does that make sense?

[et1975]

Quoting my comment from #26 :

we've been talking about something on top of XAML (which relies on mutations heavily), something that would provide immutable model and work similar to what React/VirtualDOM is doing. There's prior art in Kotlin ecosystem that does this for Android forms, using codegen to create an immutable diffable model based on the forms types. Maybe we could do something similar with F# type providers, and define the diffable model by pointing the TP at a XAML library that contains the UI elements.

@dsyme what do you think?

[dsyme]

@et1975 It's possible we can get the diff'ing done directly in the core of Xamarin Forms in the core property bag implementation. XF is fully open source and I'm interested in trying a spike on this sooner or later. That would save a lot of problems and be of interest elsewhere as well.

[dsyme]

@2sComplement Yes and no - there's not a lot of code in Elmish.WPF and Elmish.XamarinForms. But what there is has some similarity, but crucial differences in dependencies (XamarinForms has no WPF dependencies), dispatcher etc.

The sharing could perhaps happen by pushing a very generic ViewBase implementation and programming model as a shared "elmish-xaml" core. It's not urgent but could be good to align in the long run.

[dsyme]

@et1975 With regard to the native platforms (i.e. WPF, Android and iOS) I'd imagine that an external implementation of diffierential update is the only option, e.g. along the lines of the sample http://anthonylloyd.github.io/blog/2016/06/20/fsharp-elm-part1. Doing this via meta-programming seems the only really viable way to get overage. I don't think a type provider should be used because there's not necessarily any actual API surface area being generated - instead a reflection-based algorithm (i.e. one that suitable amortizes the reflection costs and no doubt has a lot of workarounds and hacks) would be seem more appropriate at first glance.

If you want to gen up a full replacement for view descriptions for the native platforms (i.e. to replace Xaml/storyboard etc. for these platforms) then that's harder and maybe a TP would make sense then. Big undertaking but maybe doable for WPF.

[et1975]

PR #32 looks to be good to go actually, samples work on full Windows.

EDIT: Actually, I'd love see to @dsyme input on https://github.com/fable-elmish/elmish/issues/130#issuecomment-381704405 , since it would affect Xamarin and WPF implementations if merged.

[cmeeren]

Closed by #48