Binding API with composable effects

[TysonMN]

trafficstars

I would like the binding API include composable effects like

• [x] Sticky (https://github.com/TysonMN/Elmish.WPF/commit/e4849b1840e217205ea5d986ab7ca9dd15e454db)
• [x] lazy during update (like oneWayLazy, oneWayOptLazy, and oneWaySeqLazy when being updated) (c.f. #143)
• [x] memoized/cached (like how oneWayLazy, oneWayOptLazy, and subModelSelectedItem are memoized/cached when being read by WPF) (c.f. #143)
• [x] validated (like twoWayValidate and twoWayOptValidate)
• [x] minimal SubModel: i.e. without model or message mapping or option matching
• [x] Move caching of SubModelSelectedItem to binding API
• [x] Simplify SubModelSelectedItem binding by using lazy effect
• [x] 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. #424)
• [ ] Consistent names for model and message mapping functions: get and set respectively
• [ ] Multi-message bindings (c.f. #321) (Probably do nearly last since it might make other work more difficult.)

Related

• Order of parameters in message mapping function #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.