Elmish.WPF
Elmish.WPF copied to clipboard
elmish
Return errors as ObservableCollection<object>
When doing validation with https://github.com/lfr/FSharp.Domain.Validation or https://github.com/JamesRandall/AccidentalFish.FSharp.Validation you can have mo than one error per property.
UWP does not have native support of INotifayDataErrorInfo so that we created our control that displays errors via ItemsControl which prefers ObservableCollection as ItemsSource
I think that validation errors must be returned similar to Binding.oneWaySeq where you can set comparers and merge new errors seq into old errors and update UI (ItemsControl) accordingly.
That makes sense. I am open other ways to handle validation errors.
I am interested to see the proposed change.
The user is free to expose "errors" (just like any other data) via a OneWaySeq or SubModelSeq binding. I have not thought very hard about the tradeoffs between the current/INotifayDataErrorInfo approach and this alternative approach.
In the suggested / proposed change is, would Elmish.WPF continue to use INotifyDataErrorInfo or stop using it?
@xperiandri, the animation I saw in UWP with addition/removal from an ObservableCollection<> looked great. I assume that this requires the more complicated keyed merge (aka a merge that uses IDs).
What would the animation look like if the unkeyed (aka merge that doesn't use IDs) were used? Can you record that animation would look like and share it here in a comment as an animated GIF?
Yes, that would be preferred. Maybe you could record the animation for both algorithms so that the difference is clear to us.