Parent-child composition about elmish.wpf

[2sComplement]

You are not missing anything. When writing this library, XAML prevailed as the best way to write WPF views (see #1). The view bindings are one extra step required to bind the view to the model.
let view _ _ = ... should really be let bindings _ _ = ..., and I have been writing it that way for a while. I'll update the samples and docs to reflect this, hopefully it will make things more clear.

[et1975]

It's worth mentioning that 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.

[2sComplement]

Would this still use WPF bindings under the hood or some other mechanism? What you describe sounds ideal, but how would it be possible to abstract something like Grid vs DockPanel? Or would the diffable model just contain a limited subset of controls?

[ehorrent]

Shouldn't it be possible to make the view return xaml UI element and corresponding binding ?
Mvu elements could then control the way UI elements are composed and how they are rendered dynamically (with bindings).

Main advantages I see :

• parent-child composition is now allowed
• no more dependencies between xaml files

[2sComplement]

It is possible, but would also require significant development effort to achieve. There are some downsides, too, such as designers losing the ability to use tools like Blend for developers to create implementations for those views.
Either way, for this library at least and for now, creating views in xaml and writing elmish logic flow seems like a "good enough" balance.

Just FYI in case you haven't seen it, there is at least one example of an attempt to implement what you describe.

[cmeeren]

I've been thinking on this topic while working on my Elmish.WPF rewrite/extension (#46).

A core tenet of Elm's guidelines seems to be keeping models and messages shallow, opting for reusable views instead of reusable components. This, as far as I have thought about it, is simply not possible in Elmish.WPF exactly because the "view" function doesn't create views, but bindings. The views have to be pre-defined (using XAML) and can't be generated by a pure function. (What the OP said, in other words.)

We are thus left with creating reusable components. For a while, we may be able to stick to a single ever-growing model / message type / update function (with one crucial exception mentioned below), but as the app grows more complex, the way to divide and conquer in Elmish.WPF must necessarily be to factor out functionality to sub-models, with their own message types and update functions.

Unless I've overlooked a possibility (which I may very well have), sub-components is however a strict requirement when using any kind of ItemsControl where elements contain e.g. a TextBox. While it's possible for Buttons to bind CommandParameter to some unique identifier for a particular element, and thus for the update function to know which item's button was clicked, TextBox does not support such a feature. The only way to know which ItemsControl item the message originated from in this case is to have each item be its own component (with its own model, message type, and update function).

This is enabled by the changes discussed in #46 (Binding.modelSeq), so at least it's possible, but there are downsides of using components that are not fully orthogonal. As discussed in the Hacker Noon article The importance of state ownership in Elm, sub-components may depend on state from their parents (for example, in my accounting app, more or less all components depend in some manner on the list of transactions and categories). Like the author of that article, I can see no optimal solutions to giving child components access to (part of) their parent's state that does not open up for state duplication and/or forgetting to update child models when the relevant parent state changes.

Just some thoughts here, no real conclusions.