Binding API with composable effects

[TysonMN]

I would like the binding API include composable effects like

• Sticky (TysonMN@e4849b1)
• lazy during update (like oneWayLazy, oneWayOptLazy, and oneWaySeqLazy when being updated) (c.f. Lazy subModelSeq (and subModel)? #143)
• memoized/cached (like how oneWayLazy, oneWayOptLazy, and subModelSelectedItem are memoized/cached when being read by WPF) (c.f. Lazy subModelSeq (and subModel)? #143)
• validated (like twoWayValidate and twoWayOptValidate)
• minimal SubModel: i.e. without model or message mapping or option matching
• Move caching of SubModelSelectedItem to binding API
• Simplify SubModelSelectedItem binding by using lazy effect
• optional like oneWayOpt, oneWayOptLazy, twoWayOpt, twoWayOptValidate (This was actually easy. The optionality is "just" option-aware boxing.)
• optional like subModelOpt (This optionality is not the same as the other optionality.)
• Add AddId as a binding effect
• Make Seq/Sequence into a binding effect by exposing BindingData
• Pick Seq/Sequence merge based on presence or absence of Id effect
• sequence/keyed (like oneWaySeq and SubModelSeq)
• Figure out how to handle multiple validation effects (c.f. Multiple composable validation #424)
• Consistent names for model and message mapping functions: get and set respectively
• Multi-message bindings (c.f. Multi-message binding #321) (Probably do nearly last since it might make other work more difficult.)

Related

• Order of parameters in message mapping function Order of msg mapping inputs #386

---

Excluding those effects, the base binding types would be

• oneWay
• twoWay
• cmd (with variants cmd, cmdIf, cmdParam, and cmdParamIf for a total of ten combined overloads)
• subModel (with three overloads)
• subModelWin (with six overloads)
• subModelSelectedItem (with two overloads)

(All of those sections of code refer to method names on the Binding class.)

Maybe more effects could be extracted and duplication removed, but it is hard for me to see that far into the future given the current lack of composable effects and duplication.

This issue will exist for a long time before being resolved. It is not easy to solve. For me personally, I don't know how to achieve all this right now. However, I do think I know how to make progress.

We can make incremental progress on this issue by making internal changes. A good example of this is when caching was added in PR #183. In that case, caching was only added as a case of VmBinding<'model, 'msg> and not also as a case of BindingData<'model, 'msg>. This feature can probably be extended to a case of BindingData<'model, 'msg>. At the same time, we can choose to keep the public API unchanged. In this way, we could create the new API internally and decide when we are ready to publicly expose parts of it or "all" of it.

[TysonMN]

#295 is essentially a duplicate. It started off as a place to share example uses of mapModel and mapMsgWithModel and now has been tracking some progress on this issue.

[TysonMN]

I updated the initial comment in this issue. I think it is now rather accurate.

[YkTru]

@TysonMN
Do you think there's still things missing from the Binding APi? Do you have a more up-to-date list somewhere so I can see if I can eventually help? (@marner2 ?)

[TysonMN]

I don't recall the details anymore. Unfortunately I haven't thought about them in years.

When I last used the binding API, I thought it was very good.

My best guess is that the above list is up to date.