-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert #3218, replace #4358. Deprecate global access from templates #4459
Conversation
Bleh, this is probably not actually ready to go. There are many deprecation notices that fire in the logs during a test run now, an example:
Looks like |
Sorry for being MIA and thanks for taking this over. This is a weird issue and I wasn't sure what to do with it. #3218 was a small change that made I tried to explain in #4358, but it is not simple to invert that behavior. Many helpers use globals as you've seen, and most use bindings directly. There's currently no way to determine whether a binding is being created from a template vs app code. I didn't think modifying the bindings code was great, but it was the only solution I could find. Anyway, I was missing something and didn't know how to get the tests to pass. I do think only deprecating global lookup for |
@xtian definitely agree about deprecations being inconsistent only on lookup and I prefer keeping this discussion focused on the templates though, and to avoid discussing anything lower-level until #4124 can be merged (since it may raise deprecations for some of the inconsistencies as well). |
@ebryn this deprecates direct global access and access via |
@mixonic Do you mean it does not fix the issue where uppercase properties are resolved as globals? |
@oskarols I'm confused by your example. This PR is only for deprecation of global access. Via |
Newly rebased, I believe this is ready to go. /cc @ebryn this was something you asked for, let me know what you think of the implementation. |
@ebryn monthly yo. I could use feedback or a merge or a close. Freshly rebased. |
|
||
if (value === undefined && root !== Ember.lookup && isGlobalPath(path)) { | ||
if (isGlobalPath(path)) { | ||
Ember.deprecate("Global lookup of "+path+" from a Handlebars template is deprecated.", !options.callGlobalDeprecation); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This deprecation shouldn't be fired if the path resolved locally. It's legit to have capitalized local paths. The behavior we're looking for is described here: #3218 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not possible with how get
works today. Get does the fallback internally. Short of calling get with the same path and Ember.lookup
as the first argument, imo a deprecation as specific as you want won't happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, we have normalizePath
. Maybe that can help.
This is pretty good. Still a more deprecations firing from tests than I would prefer, but this is pretty close to ideal. |
Replaces #4358. These deprecations are narrow in scope, and only impact
{{Global}}
. They do not deprecate any other global access in templates. Deprecating all global access from templates would a) need to be done helper-by-helper or b) would impact theget
and binding code at a lower level.@xtian I'm rewritten your first commit but preserved it here.
@ebryn yo.