-
Notifications
You must be signed in to change notification settings - Fork 109
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
Support property renaming for decorators #1125
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TypeScript converts code like this: ```typescript class Foo { @decorator prop = 'hi'; } ``` into JS like this: ```javascript tslib_1.__decorate([ decorator, tslib_1.__metadata("design:type", Object) ], Foo.prototype, "prop", void 0); ``` This is a problem for Closure Compiler's property renaming, because the property `prop` may have been renamed, but `"prop"` is just a string literal, and so it won't be renamed. Fortunately there is an API that Closure Compiler knows to process at build time that will rename a string literal representing a field name on a type: https://google.github.io/closure-library/api/goog.reflect.html#objectProperty With this change, when emitting goog.module output, tsickle will notice calls to `__decorate` and instead emit ```javascript tslib_1.__decorate([ decorator, tslib_1.__metadata("design:type", Object) ], Foo.prototype, __googReflect.objectProperty("prop", Foo.prototype), void 0); ``` where `__googReflect` is defined just after the `goog.module` section as ```javascript const __googReflect = goog.require("goog.reflect"); ``` In this way, the decorator may safely use the property name with the assurance that it will be renamed at runtime when compiled with Closure Compiler. Doc (unfortunately internal to google) considering the various implementation options: https://goto.google.com/renaming-safe-decorators
mprobst
reviewed
Dec 2, 2019
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.
Looks nice!
mprobst
approved these changes
Dec 2, 2019
Approved. Let's do another TAP round, and then I can try to land tomorrow. |
Last night's TAP run is looking good. See http://test/283069087 (I have fixes for the two failures in TypeScript tests). |
Thanks, landed! |
rictic
added a commit
to rictic/tsickle
that referenced
this pull request
Dec 15, 2019
@ExportDecoratedItemsIfPublic is a new decorator modifier for fields which should only be exported if public. When private or protected they are renamable and may be eliminated as dead code. This is more optimal version of @ExportDecoratedItems for fields which can only be accessed by reflection if they're public. Our use case ExportDecoratedItemsIfPublic is the LitElement @Property decorator, where public properties are accessible as HTML attributes and may be written by raw HTML files or various template languages (lit-html, soy, angular templates, etc). This obviously is taking place outside of the class hierarchy of the element and so is only valid for public properties, but it is still useful for private properties to participate in the update lifecycle that comes along with @Property. This change, combined with the already-landed angular#1125 we'll be able to remove the final @ExportDecoratedItems annotation from the LitElement decorators.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TypeScript converts code like this:
into JS like this:
This is a problem for Closure Compiler's property renaming, because the property
prop
may have been renamed, but"prop"
is just a string literal, and so it won't be renamed. Fortunately there is an API that Closure Compiler knows to process at build time that will rename a string literal representing a field name on a type: https://google.github.io/closure-library/api/goog.reflect.html#objectPropertyWith this change, when emitting goog.module output, tsickle will notice calls to
__decorate
and instead emitwhere
__googReflect
is defined just after thegoog.module
section asIn this way, the decorator may safely use the property name with the assurance that it will be renamed at runtime when compiled with Closure Compiler.
Doc (unfortunately internal to google) considering the various implementation options: https://goto.google.com/renaming-safe-decorators