Any plans to port work on dynamic views from Elmish.XamarinForms to WPF??

[Zaid-Ajaj]

So much interesting stuff going on the Elmish.XamarinForms now especially with dynamic views which is starting to look a lot like Elmish/React with Fable, any plans on porting it here too?

[dsyme]

Hi @Zaid-Ajaj @2sComplement at al,

I would like to start to open a discussion about this too, partly as a way of getting feedback on the approach that Elmish.XamarinForms is currently taking, and iterating on that with like-minded people. I'd love to consider applying the same approach to WPF, or at least understanding the issues involved.

The very brief summary of the Elmish.XamarinForms dynamic views is here: https://github.com/fsprojects/Elmish.XamarinForms#binding-the-elmish-to-the-xaml-dynamic-views. There are pros and cons to dynamic views (and static view bindings are still supported in Elmish.XamarinForms). But when programming Xamarin apps so far I'm really very happy sitting in dynamic views.

Basically I'm wondering, should we consider a Elmish.WPF "v2" (perhaps using a different name) which supports dynamic views?

(Note, Probably the biggest downside is that 3rd-party controls need non-trivial work to work with dynamic views. That's one of the issues I need to understand better, in particular how much of this can realistically be automated).

[dsyme]

See also prior discussion in #29

@et1975 The approach taken by Elmish.XamrinForms as of today is essentially the one outlined by you in that thread. However a code generator is currently used based on a bindings.json, rather than a type provider. We could consider changing to a type provider but there are a number of syntactic code generation hacks used at the moment

[2sComplement]

Definitely would love to port dynamic views over here. @dsyme I also wonder if it would be possible to separate the "binding engine" from the view implementation. The view libraries could then sit on top of the binding engine and be brought in as needed depending on which framework is being targeted.

[Zaid-Ajaj]

Probably the biggest downside is that 3rd-party controls need non-trivial work to work with dynamic views.

@dsyme Can you please elaborate on the non-trivial work needed to integrate 3rd-party libraries? I am assuming it is just some type of glue code that to make the view DSL nicer. We are pretty much used to writing such glue with Fable to make React libraries work with Elmish so it is not that bad.

[Zaid-Ajaj]

Also, please consider the portability to Avalonia, a cross-platform WPF implementation. It is still beta but works really nice and easy on linux/mac.

[albertwoo]

Using Type Provider sounds more exiting and easier to port to different framework like WPF, Avalonia or Uno.

[dsyme]

@dsyme Can you please elaborate on the non-trivial work needed to integrate 3rd-party libraries? I am assuming it is just some type of glue code that to make the view DSL nicer. We are pretty much used to writing such glue with Fable to make React libraries work with Elmish so it is not that bad.

3rd party Xamarin.Forms libraries don't come with incremental-update by default. However it is not too hard to write such interop code. I'm going to put together some samples today

[et1975]

I think we can safely close this, as Uil aims to accomplish that independently.