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.

[RobbieTheWagner]

Right, so this would mean apps would need to opt in to having their Application instance exposed?

[kellyselden]

In our E2E tests, we look up a service to inspect feature flags. We would need do #376 (comment) to keep this functionality, which isn't bad.

[NullVoxPopuli]

ye! it could be implemented via base route, or a decorator.

a decorator that exposes your app name could look like this:

import Route from '@ember/routing/route';
import { getOwner } from '@ember/application';

export function exportAppAsGlobal(klass: Route) {
  return class extends klass {
    beforeModel() {
      let owner = getOwner(this);
      
      let config = owner.resolveRegistration('config:environment');
      let name = config.moduleName;
      
      window[name] = { owner };
      
      return super.beforeModel();
    }
  }
}

Usage:

@exportAppAsGlobal
export default class ApplicationRoute extends Route {
  // ...

I have not tested this, but it should get people movin

[webark]

It's not the technical lift that is at issue, it's pretty strait forward how to use the window global, it's the change in methodology that just needs to be paired with it, and communicated.

If it's an "inspector" addon you have to include, or something that is provided by ember-cli itself, I just think the story around that should be flushed out before this functionality is removed.

[RobbieTheWagner]

I agree with @webark. If this requires opting in, it will remove the ability to inspect most Ember sites, which could be a feature, not a bug, if we want that locked down more, but I personally like being able to use Ember Inspector on any Ember site.

[wagenet]

Looks like this is duplicated by #540.

[wagenet]

Closing in favor of #832. We'll be sure to incorporate the discussion here into the future RFC. Thanks for your help!