Account for discrepancy between soft privacy of `private` vs hard privacy of `#`
See original GitHub issueWith the upcoming TC39 class fields proposal landing in 2022, there is a soft private vs hard private discrepancy between vanilla JS’ #
and TypeScript’s private
. This discrepancy might not be obvious to all users and could cause issues.
Maybe the TS docs should highlight this discrepancy, or maybe we should have some kind of warning. Alternatively (and this would have to be raised elsewhere), maybe there should be a TypeScript ESLint warning for this.
TypeScript’s private
is soft private and has escape hatches like the ability to use bracket notation to access a private field.
The new #
private field prefix is hard private and doesn’t allow for this. In the example below, TS compiles private
and #
differently, and the console log at the bottom shows that accessing these values produces different results.
class Dog {
#barkAmount = 0;
personality = "happy";
constructor() {}
}
class Cat {
private meowAmount = 0;
personality = "angry";
constructor() {}
}
const fido = new Dog();
const garfield = new Cat();
console.log(
fido.#barkAmount, // no good
fido['#barkAmount'], // no good
garfield.meowAmount, // no good
garfield['meowAmount'] // fine
);
Compiles to:
"use strict";
class Dog {
constructor() {
this.#barkAmount = 0;
this.personality = "happy";
}
#barkAmount;
}
class Cat {
constructor() {
this.meowAmount = 0;
this.personality = "angry";
}
}
const fido = new Dog();
const garfield = new Cat();
console.log(fido.#barkAmount, fido['#barkAmount'], garfield.meowAmount, garfield['meowAmount']);
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (3 by maintainers)
A link in our docs to a well commmented playground showing both and letting folks play with the classes (like we do for types vs interfaces ) would probably solve this quite well. Open to PRs on the website 👍🏻
@orta thanks – I’d be happy to help with this. Will follow up.