Deprecate Ember.Namespace

[runspired]

Largely a holdover from the globals era.

http://www.emberjs.com.cn/api/classes/Ember.Namespace.html

I believe it still has some use by the Ember Inspector for registering versions of libraries, but alternative ways of accessing library version information exist.

[Gaurav0]

Is DS from Ember Data an Ember.Namespace?

[rwjblue]

@Gaurav0 yes

[RobbieTheWagner]

@runspired we're using it to get all the app containers I believe. https://github.com/emberjs/ember-inspector/blob/master/ember_debug/vendor/startup-wrapper.js#L161

Is there a better way to do this? As we try to add engines support, I'm also curious if we could add logic here to add in the different engines too?

[hjdivad]

Following on to @rwwagner90's comments, Ember.Namespace.NAMESPACES_BY_ID is extremely useful when debugging, as it gives you devtools console access to apps (and therefore the container, store &c.).

Any deprecation/removal here should retain some happy path for debugging IMHO.

[RobbieTheWagner]

Agreed with @hjdivad, I think @runspired was saying this will be replaced with some new way to get the apps/containers, and as long as we retain that functionality, I am good with it 👍

[rwjblue]

While I completely agree with the overall point that @hjdivad made (we must provide public apis for console debugging), the actual mechanism that @hjdivad mentioned is 1) private api and 2) has a bunch of pitfalls. Accessing the “container” in this way exposes a very rough API that was never intended for access outside of the framework itself, we should instead provide a convienient public API for access the public owner APIs that we are familiar with.

[mixonic]

Howdy! We discussed this today at the framework meeting and think this issue is definitely ready to move into an RFC. Namespace should no longer be providing any unique functionality, not that we know of.

[RobbieTheWagner]

@mixonic what are the public APIs that replace it? Is there a better way to do things like this? Ember.Namespace.NAMESPACES[1].__container__.lookup('service:foo')

[nightire]

@mixonic what are the public APIs that replace it? Is there a better way to do things like this? Ember.Namespace.NAMESPACES[1].__container__.lookup('service:foo')

getOwner(this).lookup('service:foo'); -> https://api.emberjs.com/ember/4.4/functions/@ember%2Fapplication/getOwner

[webark]

getOwner(this)

This would require individuals to include something in there code to hook up debugging. Maybe this is a higher level thing that Ember cli could do? But the current way ember inspector interacts with the ember app without any app code installed for debugging purposes would have to be changed.

[RobbieTheWagner]

getOwner(this) only works when this is your application instance. I am asking for how to find the application instance in the console if you don't already have it.

[webark]

@rwwagner90 @mixonic if seems like if the desire is to not expose that at runtime, there would need to be some mechanism/package you could add which would expose that for debugging/inspection tools. And that should be a prerequisite for removing this api.

[NullVoxPopuli]

during app boot you can do

// routes/application.js
import { getOwner } from '@ember/application';

export default class ApplicationRoute extends Route {
  beforeModel() {
    window.MY_APP ||= {}
    window.MY_APP.owner = getOwner(this);
  }  
}

and then anywhere in the console, you can do:

window.MY_APP.owner.lookup('whatever you want')

[webark]

Sure. which was what I meant by

This would require individuals to include something in there code to hook up debugging.

This would be a departure from the current functionality of ember inspector, and that transition should be laid out and implemented/documented before it is broken.