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
Remove attrs because they were deprecated for removal in 4.0 #20671
Conversation
Did we actually deprecate |
I think the deprecation of |
I think the problem here is that there is |
I'm going to propose we remove immediately via RFC |
it's possible this was due to a lack of coverage and was just missed as the VM's been upgraded |
I just found |
oh no 🙈 |
There is some confusion/things being conflated here.
But when you reference them in the template you probably didn’t meant to render When we deprecated implicit this we also have to deal with this as it is a special case on top of normal property access in the templates and we just told people to use In the post-deprecation-removal world, imo But we aren’t talking about deprecating classic components having an attrs object in the first place, nor are we talking about deprecating accessing it from JS (not even deprecating accessing it from the template necessarily, just that if you think it unwraps for you now that will stop being true). But I actually don’t think we intentionally did anything in the VM that should/would break this test. There is a good chance that one of the changes I did (probably to the PathExpression node) is accidentally buggy, perhaps node.this is not having the right value etc. So I would dig deeper into why it stopped working regardless of whether we deprecate this |
no worries, I made a deprecation RFC: emberjs/rfcs#1016
ah, so the glimmer-vm upgrade PR needs another build-time plugin that converts |
Given the existing test, that must already be the case somewhere and I think something unintentionally broke it, which should be investigated regardless of whether we intend to keep it around, because something else unrelated would probably be affected by the same underlying bug as well |
Ok I see what’s happening now. It’s all in the screenshot you pasted above. I can’t tell you if this was intended or a bug when converting the AST plugin from transforming the access to an assertion, but notice how the isAttrs (which sounds like it is just checking stuff) actually mutates the node. If I am reading it right it, intentionally or not, end up changing It used to be that the Perhaps that turned out to be a little wrong. Based on what this existing plugin is doing, it may be the case that the The plugin here is problematic for sure, if only just because the mutation is hidden away and makes it hard to understand, but I think there is a potential ast breakage to correct |
yeah, I'm gonna fix it after I finish the action deprecation PR (it's big) |
Superseded by #20672 |
Unblocks the GlimmerVM upgrade: #20658
Merged RFC: emberjs/rfcs#690
Deprecation guide: https://deprecations.emberjs.com/v3.x#toc_attrs-arg-access