[API] New static bindings API - Discussions

[YkTru]

Hi everyone,

I hope this thread serves as a place to gather ideas, suggestions, or code snippets related to the new/revised static bindings API.

This is by no mean intended to pressure you, @marner2, until you have time to focus on it; on the contrary it’s for us to better understand what kind of support you might need and to offer our help accordingly.

---

@marner2:
[Q1]: Do you have an approximate timeline for when you could provide - at least - a checklist? This would allow any of us to start brainstorming, study the better the source code, discussing, proposing code, or identifying issues.

[todos] eg quoted from you:

• use mapMsgWithModel exclusively instead of mapMsg/mapModel
• remove/discourage the confusing overload strategy such as modelAlways
• " (...) get the static VM stuff out to a more "fleshed out" solution " - what does "fleshed out" mean concretely?
• Elmish: "upgrade some of its interfaces with its latest version that needed to be incorporated" "as well as highly relevant F# language upgrades, right over this time period."

[YkTru]

concerning another recent quote from you:

I do believe it's fully functional

[Q2]: Based on my personnal experience and insights from various issues over the years, the submodelSelectedItem binding for trees/recursive types seems to be by far the most challenging/problematic/not fully functional binding. Do you have any ideas on how to implement a static + recursive version?

Honestly, this is the only part I haven't been able to get fully working with ElmishWPF, but a really important/fundamental one as "item selection" is quite common (eg Master-Details scenarios). Other than that, it’s an excellent library, a necessary paradigm shift from MVVM IMO.

(For recursive bindings, I currently use the "CurrentModel" prop from IViewModel to access any n-level VM, which I feel is hacky/not a good practice at all: I can effectively select any node at any level, though I get all kind of very nasty UI bugs, such as the model updating correctly while the "WPF SelectedItem" property does not. I'll prepare an MRE very soon. -- @TysonMN if/when you have time, your advice on these issues would be really appreciated, thank you)

[YkTru]

@marner2: Since, as you rightly mentioned:

there seems to be a gap with the examples and documentation for that (as well as some confusing designs that came from starting it as a drop-in replacement of the dynamic stringly-typed bindings).

[Task Proposal]: I suggest creating an application showcasing all bindings along with interactive and well-organized documentation. I volunteer to take on this task.

I envision building something - using ElmishWPF of course - similar to the MVVM Community Toolkit Sample App, which was immensely helpful when I started learning it three years ago:

I’ll also progressively add or update the new bindings features as you guide me, but regardless, I believe such an app can serve as a valuable communication tool and provide a comprehensive overview of what still needs implementation. I also think it can attract more users, which is also really important.

What do you think?

If I get green light/receive encouragement, I’m ready to start this week! (I have plenty of time and I'm very excited to contribute in any ways).

[TysonMN]

use mapMsgWithModel exclusively instead of mapMsg/mapModel

Why?

If you only need to change the message, then just call mapMsg. Same for the model.

[TysonMN]

@TysonMN if/when you have time, your advice on these issues would be really appreciated, thank you)

I don't expect that will happen for the static bindings. I try to help with the dynamic bindings.

[TysonMN]

[Task Proposal]: I suggest creating an application showcasing all bindings along with interactive and well-organized documentation. I volunteer to take on this task.

[...]

What do you think?

If I get green light/receive encouragement, I’m ready to start this week! (I have plenty of time and I'm very excited to contribute in any ways).

Yes, your improving the samples is a good idea. Go ahead.

Working on samples is the easiest way to get started. My first contribution to this repo was a big fix to a sample.

I envision building something - using ElmishWPF of course - similar to the MVVM Community Toolkit Sample App, which was immensely helpful when I started learning it three years ago:

I didn't recall using that sample before, but I expect that you are right that it is good. The other one that I know is good is the Material Design ln Xaml Toolkit.

[YkTru]

use mapMsgWithModel exclusively instead of mapMsg/mapModel

Why?

If you only need to change the message, then just call mapMsg. Same for the model.

source

"We need a better naming scheme (starting with using BindingT). In fact, I'm tempted to remove the model ones as you can always introduce it with a call to Bindings.mapMsgWithModel and just disregard the original msg (which is the obj parameter"

[YkTru]

@TysonMN @marner2 @awaynemd:

[Q1]: Have you ever successfully gotten subModelSelectedItem to work perfectly with a recursive structure + WPF SelectedItem (or any other ways) using either dynamic or static bindings? I've tried for months, and can't find anything in the past issues/PR discussions..

[Q2]: If so, do you have a working example/code sample you could share? (otherwise I can open an issue + MRE this week showing different bugs - for dynamic and static bindings - I typically encounter)

*I’m aware of the SubModelSeq sample, but it doesn’t use WPF’s SelectedItem to track which Counter is selected, maybe you could just add rec subModelSelecteItem to that sample for the moment?

Thank you.

---

edit: specified "using either dynamic or static bindings" in Q1

[TysonMN]

The title is this issue is

[elmish/Elmish.WPF] [API] New static bindings API - Discussions (Issue #619)

Q1 doesn't mention static.

Are you asking about dynamic or static bindings in that question?

I can open an issue + MRE this week showing different bugs - for dynamic and static bindings

Always feel free to do that.

[YkTru]

( Hi @marner2 : Could you share a quick update (just a line) on when you might have time to provide (at least) an initial checklist? I recall you mentioned "fall-winter," so I don’t want to rush you in any way—if it’s likely to be late winter, that’s perfectly fine.

In the meantime however, if you could provide even a basic checklist/short insights on what you envision (which pattern/approach, etc.), it would help me start exploring on my own, analyzing the source code with that mindset, and testing/providing some relevant examples I hope. I currently have plenty of time available to dedicate.

Thank you so much—I know you’re busy, and I truly appreciate your help! )