Elmish.wpf: Conditional elements of views

Created on 2 Feb 2018 · 11Comments · Source: elmish/Elmish.WPF

One of the nice things about the Elmish React programming model is the way the view function can be used to conditionally compute the view, e.g. based on whether the user is logged in or not. A sample is here (a non-None model indicates the user is logged in, the UI updates accordingly).

The Elmish WPF and Elmish Xamarin Forms approach appears to be to put this state into the binding and use various Xaml conditional view logic things, e.g. https://github.com/Prolucid/Elmish.WPF/blob/master/src/Samples/Elmish.Samples.DesignDataContext/Program.fs#L48. The removal of this kind of control state into regular program logic is however an important "win" of the Elmish model.

My question is whether anyone has explored a happy medium between these two somehow. I understand that the view function is currently only called once in the Elmish.WPF/XF model. I'm thinking of some setup where the view function is called repeatedly and the results indicate both bindings and visibility, and the results are differentially applied (note: I'm not thinking of full differential update of the whole WPF visual tree as in React, which really requires changes inside WPF or Xamarin Forms as far as I understand, though those are interesting in their own right for Xamarin Forms)

To put it another way, have people fiddled with the Elmish.WPF architecture to allow more control logic to be taken out of explicit bindings (e.g. into some variant of a repeatedly-called view function)

enhancement

Source

dsyme

Most helpful comment

My only concern with this approach is that, IMHO, writing Xaml without intellisense would not be a good time. Do you guys agree?
I wonder if it would be possible to generate bindings like those used in fable-react for WPF controls. That would provide us with a very Elmish experience as well as conditional view rendering.

2sComplement on 7 Feb 2018

👍2

All 11 comments

I have not yet explored this specifically. In my use of this library, I find writing conditional views in Xaml based on Visibility bindings to be easy enough. Even though the WPF view itself is not conditionally rendered in the typical Elmish way, the control logic is still part of the Elmish flow. The view bindings really just tie everything together, and in my mind the generation of those bindings is the place for improvement.

That being said, I am definitely open to suggestions on how conditional views could work. Are you picturing a view function that conditionally returns a parent WPF control and its corresponding view bindings based on state logic?

2sComplement on 3 Feb 2018

@2sComplement Thanks! That make sense.

I'll fiddle around with different approaches and report back if anything feels usable. It could be that there's no really stable middle point: you can always construct examples where you conditionalize/compute more things, and you get dragged more towards Elmish-with-dynamic-views

dsyme on 5 Feb 2018

@dsyme that's the feeling I get - that it will be all or nothing when it comes to dynamic rendering. Then it becomes a question of "do we want to write Xaml or not?"
Thanks for your interest though, I look forward to hearing your suggestions.

2sComplement on 5 Feb 2018

@dsyme that's the feeling I get - that it will be all or nothing when it comes to dynamic rendering. Then it becomes a question of "do we want to write Xaml or not?" Thanks for your interest though, I look forward to hearing your suggestions.

@2sComplement :) That's a good way to put it

BTW another general question: what do you think about constructs that permit Xaml, HTML or other markup in F# source, e.g.

let view _ _ = 
    <xaml>
        <ContentPage x:Class="MasterDetailApp.ItemsPage">
            ...
        </ContentPage>
    </xaml>

People have not been shouting for this in F#, but React JSX files that integrate HTML are quite popular.

In F# one could imagine that such a mechanism was extensible via a type provider, so the above becomes something like

let view _ _ = 
    Xaml<""" ... content... """>.Value

allowing preprocessing and checking of the content. This would also allow other markup languages:

let view _ _ = 
    markdown:
        ...

let view _ _ = 
    <html>
        ...
    </html>

The exact range of constructs delimiting such markup would be a major point of discussion, as would the allowable quasi-quotations.

I know there are lots of technical reasons not to do this for Xaml - e.g. the need to pre-compile it. But I'm just taking the opportunity to ask generally from the language design perspective.

Thanks

dsyme on 7 Feb 2018

👍1

@dsyme

Full disclaimer, my history is in C# development, but I learning FP on the side and have really enjoyed learning Elm. Since I have a background in .NET and Elm borrowed a good bit from F#, I keep my eye on the F# community as well.

From an outsiders point of view, I would really like the constructs you showed in the examples above. One thing I like about React is the JSX syntax. If what you showed above came to F#, I would be really excited.

Just one person's opinion.

Have a great one.

euphbriggs on 7 Feb 2018

2sComplement on 7 Feb 2018

👍2

I wonder if it would be possible to generate bindings like those used in fable-react for WPF controls. That would provide us with a very Elmish experience as well as conditional view rendering.

@2sComplement Yes, that would be possible. The conditional view rendering would not be incremental but it would be fine for many purposes.

dsyme on 8 Feb 2018

generate bindings

That's what I was talking about when I suggested a TP. The reason we're interested in using WPF at all is the UI libraries on top of it. Having DSL just for XAML or barebone WPF is fundamentally not interesting, that's why I thought a TP that one can point at a controls lib and have it generate DSL for the controls it contains would be a viable way forward.

EDIT: I might be on the wrong side of history, but I think JSX support that BuckleScript went after was a mistake. Programming in XML for the sake of programming in XML is... just not right.

et1975 on 8 Feb 2018

@et1975 For the language design I can see the need to cater to all three constituencies ("markup-in-file", "markup-out-other-files", "view-via-programs-using-DSL-and-possible-a-type-provider").

I have no strong preference personally.

dsyme on 9 Feb 2018

@et1975 I'd disagree - I do see a use case, but it would be more with creating a component architecture for libraries like Gjallarhorn and Gjallarhorn.Bindable
This would be more in line with usage in the React world, using a reactive framework rather than existing MVVM-based tooling that is built around WPF.