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

Add @internalProperty decorator, for private or protected fields. #881

Merged
merged 2 commits into from Jan 21, 2020

Conversation

rictic
Copy link
Contributor

@rictic rictic commented Jan 20, 2020

No description provided.

Copy link
Contributor

@justinfagnani justinfagnani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I do wonder if the name is ideal, but I don't immediately see an obviously better alternative, and the minimal change from @property is probably best. Other thoughts: since these aren't external properties, maybe something to do with "state" would be good. Also, in retrospect, I wonder if we should have gone for @field, since these things are class fields... but JS itself seems to have a naming problem with multiple ways to refer to them now: fields vs properties. meh

Are there any public tools that can take advantage of the property vs internalProperty distinction? Something in tsickle? If this is mainly useful inside Google, do we want to leave this out of the main docs as is, or add a note to the property docs? cc @arthurevans and @graynorton

@web-padawan
Copy link
Contributor

web-padawan commented Jan 21, 2020

IMO the name @internal would be clear enough.

@rictic
Copy link
Contributor Author

rictic commented Jan 21, 2020

@internal reads to me like it can and perhaps should be combined with @property

Are there any public tools that can take advantage of the property vs internalProperty distinction? Something in tsickle? If this is mainly useful inside Google, do we want to leave this out of the main docs as is, or add a note to the property docs? cc @arthurevans and @graynorton

tsickle will care, and I intend to add an optional, disabled-by-default pass to lit-analyzer that will require that @property is always public and @internalProperty is always private or protected.

Unless a project is compiling with closure compiler, they probably won't care about this distinction at all, and so it's probably not worth advertising this.

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

Successfully merging this pull request may close these issues.

None yet

4 participants