You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Ember Global (window.Ember) remains in the programming model, despite the fact that the globals resolver and much of its other functionality was deprecated a long time ago. This is primarily because, in part, removing the global means shifting around a lot of code within Ember itself. The other major part is that the global is the only way many intimate APIs, such as Ember.meta, are accessible.
With the global in place, its not possible for us to treeshake Ember in any meaningful way. It also forces a large eager evaluation cost on users of the framework, since every module gets evaluated immediately to construct the global. Removing the global will help with both of these, and will remove a fair amount of code from the application.
Migration Path
There are a number of intimate APIs that are currently only accessible on the global. Ideally, but the time the global is fully deprecated and removed, these APIs should all have alternatives, themselves be deprecated. The final version of this RFC should perform an audit of the remaining APIs that are only available on the Global, so we can begin this process.
Additionally, these APIs are used frequently by debug tooling, like the Ember Inspector. We must make sure that debug tooling has a way to get the information it needs to get before we remove these APIs. A public debug API will likely need to be created for this purpose.
Deprecation Timeline
This RFC is dependent on replacing all of the use cases for a number of intimate APIs with first class public APIs (or removing the need for them entirely). Until a thorough analysis is done, and the alternatives made, it will probably not be possible to finalize this RFC. Setting the proposed deadline at v5.0.0 gives us a target to try to achieve this by, which will help to motivate cleaning up the remaining intimate APIs.
The text was updated successfully, but these errors were encountered:
The Ember Global (
window.Ember
) remains in the programming model, despite the fact that the globals resolver and much of its other functionality was deprecated a long time ago. This is primarily because, in part, removing the global means shifting around a lot of code within Ember itself. The other major part is that the global is the only way many intimate APIs, such asEmber.meta
, are accessible.With the global in place, its not possible for us to treeshake Ember in any meaningful way. It also forces a large eager evaluation cost on users of the framework, since every module gets evaluated immediately to construct the global. Removing the global will help with both of these, and will remove a fair amount of code from the application.
Migration Path
There are a number of intimate APIs that are currently only accessible on the global. Ideally, but the time the global is fully deprecated and removed, these APIs should all have alternatives, themselves be deprecated. The final version of this RFC should perform an audit of the remaining APIs that are only available on the Global, so we can begin this process.
Additionally, these APIs are used frequently by debug tooling, like the Ember Inspector. We must make sure that debug tooling has a way to get the information it needs to get before we remove these APIs. A public debug API will likely need to be created for this purpose.
Deprecation Timeline
This RFC is dependent on replacing all of the use cases for a number of intimate APIs with first class public APIs (or removing the need for them entirely). Until a thorough analysis is done, and the alternatives made, it will probably not be possible to finalize this RFC. Setting the proposed deadline at v5.0.0 gives us a target to try to achieve this by, which will help to motivate cleaning up the remaining intimate APIs.
The text was updated successfully, but these errors were encountered: