Hacker News Reader

Comment by viktorcode | Hacker News Reader

> Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change

That's not strictly true. You get the new value inside the closure. This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI. Before you had to write the code like this to achieve that:

func startObservation() { withObservationTracking {

        print(store.state.toggle) // Here we have the new value (+ it is called once before any change)

    } onChange: {
        Task { startObservation() }
    }
}

View on HN

I know that you get the new value; but in many cases (almost every case I encountered), that doesn't help. You mention

"This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI"

I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.

For example, if I have an object that represents a camera, and the user tweaks a value in the UI that changes its resolution, the camera might offer a different set of values for things like frame rate.

So if I get notified that the user changed the resolution, I can't then tell the Recorder object to recompute the remaining recording time based on the camera settings, because those settings will not have changed yet.

And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.

It's another great example of serving only the most illogical and obscure use case. Who the hell would expect something called "startObservation" to just quit after one change? The stupidity is just galling.

> And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.

The restart is there in my example, and it doesn't look too complex. And this aspect of observation is exactly what will be changed in Swift 6.2. Nice improvement, I'd say!

> I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.

If your model stores 2 interdependent states then you'll risk running into infinite update loop regardless of whether you've been notified from `didSet` or `willSet`. It can be fixed by changing the model.

To be fair I didn't understand your example with camera and resolution. In all cases you already know the new value and so the dependent code is good to go. The code shouldn't ever care where the value comes from: the main state, the future state, or some mock state.

Reply on news.ycombinator.com