Discussion: Refresh Changes

[JakenVeina]

Should we support them?

Personally, I think in RX-land, anything that is both mutable and needs to be monitored ought to be "properly" IObservable<>-ified. That is, either publish the new value through records and the immutable object pattern, or wrap the value itself in something like a BehaviorSubject<>, at its source. E.G. if I want to do something like .SelectItems(item => item.MyProperty) on a DD stream, I should either make item immutable, and change the value of .MyProperty by immutable copy, with a Replace change, or I should make .MyProperty an IObservable<> directly on each item.

However, I also think there's a lot of validity in scenarios that aren't this. In particular, I think the most convincing argument is that even developers who AGREE with me, and WANT to implement everything like I described above, might be working with systems that they don't fully control, and their job is still to stitch different pieces together, to make everything work.

As such, I think my position is "Implement Refresh as a change type, but leverage documentation to try and hint people away from using it, if they don't have to."

[RolandPheasant]

When I first wrote dynamic data, it accounted for immutable objects only, and refresh did not even exist. I agree that immutability should always be preferred .....but there is no getting around the fact that there are times that mutability is needed. Also I have long since come to the conclusion that it is a necessary evil.

[RolandPheasant]

Making people jump hoops to wire mutable changes into immutable objects would leave a bitter taste for any developer.