notifyPropertyChanged and native classes

I used notifyPropertyChanged in a few Ember Objects. In the classes I have a property getter that makes an external third party API call and sometimes I want to at-will update that data. It works perfectly, but with the change to native classes it seems like EmberObject is sort of going to be eventually deprecated. Am I reading too much into this? Is there a more preferred design pattern.

For a real world example, suppose I display the outside temperature. There’s a button the user clicks to update the outside temperature. There’s no ready way to get the third party temperature service to set the value on the object. So, if I get the temperature from the third party API, and use notifyPropertyChanged on that property any templates etc that use that property rerender. The only other way I’ve seen it done is to wrap the rendered property in an if and then toggle the if conditional which seems really clunky.

I have a property getter that makes an external third party API call

I could be misunderstanding your problem but I think typically you want to avoid making async requests of any kind in get/set/computed scenarios. The temperature example you described would typically be done like button click triggers action -> action fetches temperature -> when fetch is complete it sets the temperature prop. That would update any computed properties. And with the new tracked decorator of course you don’t need all the manual observer configuration.

It’s a lot easier if getter/setter methods and computed properties are all synchronous and you handle all async operations in actions, routes, and ember concurrency tasks.

Anyway hope that makes sense and isn’t way off what you were actually getting at.