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

Declare property quick fix should add private properties (or be configurable) #36249

Closed
mjbvz opened this issue Jan 17, 2020 · 9 comments · Fixed by #36632
Closed

Declare property quick fix should add private properties (or be configurable) #36249

mjbvz opened this issue Jan 17, 2020 · 9 comments · Fixed by #36632
Labels
Domain: Quick Fixes Editor-provided fixes, often called code actions. In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@mjbvz
Copy link
Contributor

mjbvz commented Jan 17, 2020

TypeScript Version: 3.8.0-beta

Search Terms:

  • quick fix
  • declare property

Code
For the code:

class Foo { 
	constructor() { 
		this._bar = 1;
	}
}

new Foo().other = 'a';

Trigger the quick fix to declare a missing property on _bar.

Expected behavior:
The quick fix adds a private property _bar:

class Foo { 
	private _bar: number;     
	constructor() { 
		this._bar = 1;
	}
}

Actual behavior:
The quick fix adds a standard public property:

class Foo {
	_bar: number; 
	constructor() { 
		this._bar = 1;
	}
}

Playground Link:

Related Issues:

/cc @JacksonKearl

@a-tarasyuk
Copy link
Contributor

Should TS suggest a new QF for properties that start from _ (Declare private property '_bar')? Or Declare property '_bar' QF should handle that?

cc @DanielRosenwasser

@DanielRosenwasser
Copy link
Member

Yeah, it sounds like the original quick fix is asking us to change the existing quick fix to add a private modifier to the property in TypeScript files, and maybe a /** @private */ doc comment in a JavaScript files?

What's preferable here?

@DanielRosenwasser DanielRosenwasser added Domain: Quick Fixes Editor-provided fixes, often called code actions. In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Jan 28, 2020
@a-tarasyuk
Copy link
Contributor

@DanielRosenwasser

TypeScript

class Foo {
  constructor() {
    this._bar = 1; /* Declare property 'bar' */
  }
}

After QF

class Foo {
  private _bar: number;
  constructor() {
    this._bar = 1;
  }
}

Is it a right example for TypeScript?


The following example is a valid JavaScript code

class Foo {
  constructor() {
    this._bar = 1;
  }
}

Where do we need to add /** @private */ JSDoc?

@DanielRosenwasser
Copy link
Member

Yeah, I guess the JS case doesn't need that... hmm.

But yes, I think the TS example you had is what what the quick fix should do. It's not clear whether it should be a separate action or not though.

@DanielRosenwasser
Copy link
Member

I'm inclined to experiment with keeping it as part of the same action and seeing if users are unhappy about it.

@DanielRosenwasser
Copy link
Member

But then I think there will be a question of "why don't you always make my properties private regardless of the _?"

@JacksonKearl
Copy link

@DanielRosenwasser I personally don't tend to prefix privates with underscores, so I'd like it to be a separate action.

Of course if it's a separate action you'll soon have "why isn't there an action for protected if you allow private and public?".

@a-tarasyuk
Copy link
Contributor

Of course if it's a separate action you'll soon have "why isn't there an action for protected if you allow private and public?".

I think, better to make a new action for that case. We can start by adding new QF action for private declaration, and see if it makes sense to add QF action for protected properties. What do you think?

cc @DanielRosenwasser @JacksonKearl

@JacksonKearl
Copy link

Adding just a separate QF for private seems fine for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Domain: Quick Fixes Editor-provided fixes, often called code actions. In Discussion Not yet reached consensus Suggestion An idea for TypeScript
4 participants