DEPRECATION: waitForProperty is deprecated due to its use of observers.

[jagthedrummer]

I just updated to ember-stereo 5.4.1 and am seeing a new deprecation warning. It may have been there previously but I missed it among the other warnings about the inject as service deprecation.

DEPRECATION: waitForProperty is deprecated due to its use of observers.
Consider using a polling approach instead.
[deprecation id: ember-concurrency.deprecate-wait-for-property]
This will be removed in ember-concurrency 5.0.0.

Unfortunately this one doesn't seem like it's as easy of a fix as the inject as service one was.

[jkeen]

yeah, that one is rough because it's pretty crucial to how the 5.x ember-stereo works. I just cut a 6.x beta release branch that has some long-in-my-head restructuring of ember-stereo to get away from relying so heavily on some of those waitForProperty calls (among other things).

If you wanna give that whirl, I'd love to get your feedback. Here's the upgrade docs: https://ember-stereo.com/versions/beta/docs/upgrading

[jagthedrummer]

Hey @jkeen I just tried the version 6 beta and I didn't run into any major issues.

Here are some interesting differences I did notice if it's useful.

With 5.x I was seeing several of the waitForProperty deprecation notices as soon as the app loads. In 6.x those notices are gone.

However, in 6.x the desktop version of my app (via ember-electron) shows these errors when the app first loads, which are not there in 5.x.

It looks like it has to do with the new casting stuff. Maybe that could be opt-in or opt-out in some way if people aren't planning to use it? And/or maybe we could document what needs to be done on the app side to make this work in electron. (I'd guess it's going to involve updating the Content Security Policy or something similar to allow those gstatic.com URLs to load.)

In 6.x I do still see a couple of deprecation notices about waitForProperty each time that I hit "play" on a new sound. The same thing happens in 5.x.

Other than that everything that I've tested so far is working as expected. And I didn't even have to touch any of my code because I'm not using any of the things mentioned in the upgrade docs.

I think 6.x is off to a great start! Thank you for your continuing work on this excellent add-on.

[jkeen]

@jagthedrummer Thanks for the great feedback! This was useful to know, and I just cut beta 2 which should resolve both of those issues.

Those calls you saw for casting were just chrome checking if casting was available, and now I changed the logic so it doesn't do that unless a casting-related helper is used, so it shouldn't fire at all if you're not using it.

[jagthedrummer]

Thanks for the quick update, @jkeen! I just tried beta 2 and it's working great. Both of the issues I mentioned are resolved and I'm not seeing any other errors or warnings and everything in my app works as expected. Cheers!

[jagthedrummer]

I was going to go ahead and roll with beta 2 to get some real world tests going, but for some reason using it causes a bunch of extra stuff to show up in my test output which breaks the reporting part of my workflow.

WARNING in ../../ember-stereo/dist/_app_/-private/utils/cast-sdk-loader.js 1:0-70
export 'default' (reexported as 'default') was not found in 'ember-stereo/-private/utils/cast-sdk-loader' (possible exports: isCastFrameworkPresent, loadCastSdk)
 @ ./assets/seshy.js 312:13-63

WARNING in ../../ember-stereo/dist/_app_/-private/utils/event-map.js 1:0-64
export 'default' (reexported as 'default') was not found in 'ember-stereo/-private/utils/event-map' (possible exports: EVENT_MAP, SERVICE_EVENT_MAP)
 @ ./assets/seshy.js 327:13-57

[jkeen]

Would love some real-world tests! And I think this is an an easy fix, I'll have a commit + new release shortly