4 ms·
Lots of comments seen to have missed that the article isn't recommending against private fields, only the private keyword. Typescript and JavaScript have a new
by seniorsassycat 5y ago
Lots of comments seen to have missed that the article isn't recommending against private fields, only the private keyword.
Typescript and JavaScript have a newer brand # to make fields private. The native feature will have runtime benefits while the private keyword creates fields that's are public at runtime.
I still use the private keyword because constructor shorthand doesn't support brands.
constructor (private field)
constructor (#field) // error
- ironmagma 5y ago> We'd like to maintain feature parity with JavaScript unless there's a compelling reason not to. And ladies and gentlemen, the generated code... var __classPrivateFieldGet = (this && this.__classPrivateFieldGet) || function (receiver, state, kind, f) { if (kind === "a" && !f) throw new TypeError("Private accessor was defined without a getter"); if (typeof state === "function" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError("Cannot read private member from an object whose class did not declare it"); return kind === "m" ? f : kind === "a" ? f.call(receiver) : f ? f.value : state.get(receiver); }; Nothing about this says "native JavaScript" to me. Who cares that a private field is technically public at runtime?
- robpalmer 5y agoYou're looking at down-levelled code. Babel and esbuild would equally produce similar code. This is not a TypeScript issue. If you want "native" JS output, use the tsconfig option... "target": "esnext