After a long, long time I just bootstrapped a new Ember application, using Ember/EmberData 5.3.0 and Ember Simple Auth. While everything from authenticating a session (oauth) to loading a current user 's profile into a service (within the application route) works pretty well, I came across a concept issue or rather an issue with my mental model.
Long story short: Isn’t a service - defined in an application route - accessible from all other routes? As some sort of an application wide singleton?
Second question: How do I disable the browser’s console output about deprecations such as
“DEPRECATION: You are relying on ember-data auto-magically installing the NumberTransform. Use export { NumberTransform as default } from 'ember-data/serializer/transform'; in app/transforms/number.js instead [deprecation id: ember-data:deprecate-legacy-imports] This will be removed in ember-data 6.0.”?
Thx in advance,
Martin
Not quite how I would characterize it… The way I would describe it is that a service is a global singleton which can be injected anywhere in the app (routes, controllers, components, other services, etc). But a service which is injected in the application route shouldn’t necessarily be accessible to anything else simply because it’s injected in the application route. And I guess I wouldn’t characterize a service as being “defined” in a route but rather “injected”. I’m guessing the injection model will change in Polaris since it’s still resolver based but I’m not sure on all that. So yes a service is an application wide singleton. I think they’ll be staying around as a concept (they’re very useful and more intuitive IMO than some of the weird component contortions from component-only frameworks). I’m not sure if that answers your question…
IIRC these are stripped out in production builds already but if you don’t want them in dev builds you can use ember-deprecation-workflow to ignore them by deprecation id. That said I wouldn’t recommend simply hiding them as in the long run you’re hurting yourself. If this app is intended to live any length of time you’d be much better off addressing the deprecations as they come up. That is advice from experience 
Thank you for your explanation on both the service concept as well as the console log.
Will try to create an example app using mirage to illustrate my problem.
SOLVED Timing problem. Tried to output the service’s property (user) in a component’s template (after injecting the service, of course) and did this unconditionally. So so surrounding {{ this.currentUser.user.username}} with {{#if this.currentUser.user}} {{/if}} lead to the the expected result.
Thanks again for your answer. Happy that my mental model matches the reality!
And: Will happily ignore the deprecation logs in my dev run from now on. 
Update: Always keep in mind that syntactic sugar of async/await can help to shoot yourself in the foot.
1 Like