Skip to content

Instantly share code, notes, and snippets.

@ianmstew
Last active November 3, 2019 18:30
Show Gist options
  • Save ianmstew/37a15f18a5c263a3b8de0bda22e66aaf to your computer and use it in GitHub Desktop.
Save ianmstew/37a15f18a5c263a3b8de0bda22e66aaf to your computer and use it in GitHub Desktop.

http://www.typescriptlang.org/play/#code/MYGwhgzhAEAqCmEAu0DeAoaXoDMD2e0AvNEgBYCWEAdBQHYVIDc0A9K3AJ4AO8AysABOFbkgC0Y+owpgQFAF7wAJtADujMtGB46yQQFdgSPIOhhBAc0zYARueKlKNKUgBMLdtAAK+wfGgAUmAAbmACwqISwGB0AOQoLjJyimoaWjp6hsam5lbY0C6uAFxmdJxM1ljaukgGRiYAFNzCoUj+LiUxnAA0BQxunWUAlGiV+Y5UtP2uDoUV+QC+6AtAA

TypeScript makes JavaScript classes actually useful ^^

By fixing a fatal ES6 class flaw

The conspicuous absence of a way to reference constructor arguments within inline class property initializers

Which IMO after a year of struggles completely hobbles ES6 classes

But TypeScript classes literally solve that exact problem

Tangential but concerning classes, ES6 classes are incredibly unsafe due to ESLint's inability to catch mis-uses of this the way ESLint catches "usage before definition" errors for local scope variables

But TypeScript is capable of identifying that exact category of issue even with this, which is demonstrated in the above example by the error in bar = this.init2;

So not only are TypeScript classes not broken, this is as safe as using local scope variables

I'd go so far as to call ES6 classes an antipattern within any stack that supports TypeScript, and very questionable even in a stack that doesn't support TypeScript

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment