by DanRosenwasser on 5/29/19, 5:20 PM with 80 comments
by sli on 5/29/19, 7:21 PM
false | 'x' | 'y' | undefined
Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requires me to write the following value to avoid a type error:
'x' as 'x'
This is not the only time I've run into this kind of problem -- I run into this problem regularly -- this is just the simplest version of it that I've experienced. I just cannot take a type system seriously when workarounds like that are needed.
Add to that, in many cases being unable to import a JS library in that doesn't include typedefs, and I fail to see how TS can be considered a superset of JS. It's certainly sold that way, but it's clearly not totally true. TS+React requires --noImplicitAny, which cannot be worked around (it's labeled as being required due to a platform limitation).
I also find Microsoft's documentation of TypeScript to be very poor (and has no search feature -- I'm sure they have some convenient excuse for that). I tend to learn how things work from random Github comments or source code after reading the documentation over and over. What is `declare` used for in practice? They don't really say, they just say it's for declaring things, and give highly specific examples.
Maybe I'm the odd one here and maybe I'm missing some piece of information that a lot of TypeScript developers have, but I've yet to find it and given all the choice I have these days, there are numerous languages I would choose well before TypeScript.
by lioeters on 5/29/19, 7:34 PM
- Omit helper type
- Smart Select (allows editor to expand/shrink selection based on syntactic construct)
- Extract to type alias (smart refactor of function parameters to their own type)
- Performance improvements
by Roboprog on 5/29/19, 10:11 PM
Did they ever get a solution in place for partial function application (e.g. - as for Ramda.js)?
When this gets to the point where the only place I have to define explicit types is for JSON data read from the network, I’ll consider using it.
I know I’m in the minority, but I’d rather NOT have any type checking than have to read through Java-esque drivel (at least most modern languages put the types after the identifier like Pascal does, rather than before like C). In practice, I don’t spend much time chasing type errors, but do spend too much time reading through MEGO inducing verbiage which I would just as soon not.
by hermanradtke on 5/30/19, 4:18 AM
I looked into combining tsc-watch and jest, but jest does not currently support a public API. tsc-watch already emits an event on success which should be able to trigger (an already running!) test runner to incrementally test again.
by PaulBGD_ on 5/29/19, 7:52 PM
by mattigames on 5/30/19, 1:13 AM
1) Operator overloading
2) Runtime type checking of JSON payloads (on dev env at least)
Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2
And the most common error that it should help catch during development is that you get a JSON and you cast it but it means nothing cause on runtime the JSON can be something completely different and nothing breaks until is somewhere else hard to debug, I get that Microsoft don't want to add runtime overhead but it should be possible at least on development mode.