Skip to content
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

2.2.2 breaking change: globals are now 'not in scope' for templates? #38

Open
davidtaylorhq opened this issue Apr 18, 2024 · 4 comments

Comments

@davidtaylorhq
Copy link

There appears to be a breaking change between 2.2.1 and 2.2.2. Previously, in gjs files, we could reference JS globals directly as helpers. For example, we were using @something=(Boolean this.blah) to cast a value to a boolean.

Now, we get the error:

Error: Attempted to resolve a helper in a strict mode template, but that value was not in scope: Boolean

Adding const Boolean = window.Boolean to the file works around the problem.

This problem is not limited to helpers. Something like {{document.title}} previously worked, but now throws a 'not in scope' error.

@ef4
Copy link
Contributor

ef4 commented Apr 18, 2024

LIke #38, this was intentional because in general there's no way to statically disambiguate between javascript globals and future ember keywords. That is the tradeoff of not making people import keywords.

We do support globalThis, so I would expect @something=(globalThis.Boolean this.blah) to work.

We can decide to support a standard list of platform-provided globals, including Boolean and document. Perhaps we should do that right away to mitigate the impact of this change.

The thing we don't want to do is support arbitrary globals. Like, if somebody decides they don't like importing their component all the time and tries window.CustomButton = CustomButton, that doesn't make <CustomButton /> work in all components.

@chancancode
Copy link
Member

Another (IMO more important) consideration is html tags, or rather, for the scoping rule to work consistently across all positions (<___> vs {{___}}); say we support window and document, if HTML later introduces <window> or <document> elements, there will be no way to invoke them (without making convoluted excepts to the scoping rules)

@chancancode
Copy link
Member

Not to say that I am against supporting window or document for that reason, but we should keep that in mind every time we consider adding to that list

@NullVoxPopuli
Copy link
Sponsor Contributor

NullVoxPopuli commented Apr 19, 2024

I would like common casts added to the list: Boolean, String (helpful for glint)

And utility namespaces: Math, JSON, Date, URL

And Common globals: window, document, navigator, localStorage

Tho, given the congern ef4 raises, i can deal with destructuring globalThis, as awkward as it is. Tho, elements must all be lowercase, so the namespaces and casts seem safe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants