I learned it in more than five minutes - over the last couple weeks - when I rewrote an open source UI Componenrt library in TS.
What’s scary is the number of bugs in the original implementation! I made the comment on Reactuflux’s #typescript channel that I’m afraid to use code not written in TS now.
Anyway, it’s been interesting coming from the land of Python, and surprisingly quite enjoyable.
I just started a side project with Typescript, and I like a lot of it, but, ironically, type discovery seems _very_ lacking. The JS keywords like `instanceof` are useless because everything is just an object, and Typescript doesn't give you a way to pattern match on types.
For example, in React there is this type that's a union of an array, single object or null. Some kind of catch-all, I guess. So, when you see one of these things, there's no way to know what you have unless you do something ugly like this:
if ((value as any).length) {
// it's an array
} else if (value) {
// must be a single object, I guess..
} else {
// null
}
The thought of littering my code with these kinds of type checks makes me feel really dirty, unless I'm totally missing something...
For types like those which are outside your control you can use type guards[1]:
if (value == null) {
// TS knows value is null, doesn't let you access value .length for example
} else if (Array.isArray(value)) {
// TS knows value is an array
} else {
// TS knows that it's an object here
}
However, having types like those in your own code (e.g. things like X[] | Y | null) is probably an antipattern and should be avoided. Using discriminated unions[2] is much better.
What you're "missing", I think, is that Typescript's types only exist at compile-time, so they aren't available through runtime operations like instanceof. It's like a more extensive case of Java generics erasure.
You’re not missing anything ; instanceof can be used to check prototype chain (class inheritance) but there is nothing similar for object interfaces (duck typing). And most Javascript objects are only loosely defined to conform to interfaces.
Good call. I love TypeScript, and wouldn't build a web app of even small scope without a typing solution at least as good as TypeScript, and it's the best.
But, as you say, pattern matching sum types is a weak point in practical use of TypeScript.
Since the types only exist at compile time, maybe there could be a heavier opt-in system that uses something like Symbols to do pattern matching:
matchable type Shape = Circle | Square | Triangle;
const myShape: Shape;
match myShape {
// uses symbol magic under the hood, eg. if (SymbolShapeCircle in o)
case (c: Circle) { ... }
case (other: Triangle | Square) { ... }
}
I really like this kind of introduction; they let you get into what the authors consider the main reason for their products existence straight away - this is what they will spend most time on and other features will exist at these features expense.
It is also the best place to start evaluating how "complete" a solution is; particularly when faced with multiple choices.
It was a tutorial very similar to this one that led me to choose flow over typescript - I did the equivalent of setting the "user" in this example to null, flow would tell me it wouldn't work and typescript just happily compiled away. In short, this kind of quick evaluation led me to deduce typescript is JS with loose types sometimes (but you aren't sure where) so as not to be annoying and flow is JS with restrictive types everywhere (that may not get your indirect but correct logic) so as to provide the most guarantees.
With the disclaimer that I don't get paid for my Typescript work (I use it for some personal projects, as it saves me a bit of time compared to C++), I have this as the compile scripts entry in my package.json:
"compile": "tsc -p ./tsconfig.json",
I also have a start script, for running it from the command line:
"start": "npm run compile && node ./.build/main.js"
tsc has some kind of file-watching mode, that I assume compiles when you save stuff, but I don't use that, because I'm not a monster.
I use tsc -w with a simple Python web server and use <script> tags to include all of my modules. Yeah, I'm a monster. And watch out for the browser cache.
Yeah, we use tsc for node. I typically just use ts-node for development, though, and tsc gets to hang out in CI/CD somewhere. I assume ts-node / webpack / etc all use tsc under the hood, though.
For node projects I use ts-node with nodemon watching for filechanges and takes care of restarting the server.
And then to build the project for release thats done with tsc.
There's a couple of things going on that you might not be familiar with as it's a bit different to most languages:
The public modifier on these constructor parameters is actually introducing them as properties of the Student type:
constructor(public firstName: string, public middleInitial: string, public lastName: string) {}
Since the Student type has 'firstName' and 'lastName' properties, it meets the Person interface requirements. It doesn't need to declare that it is, but could and usually would just for readability and the additional assurance that you haven't forgotten something.
No, you don't need to inherit or implement which is one of the great features of TypeScript!
In this example, the `greeter` function accepts any object that has a `firstName` and `lastName` property defined, regardless of what the object/type is called. No need for inheritance.
In fact, the `Person` interface is not even emitted in the JS output because interfaces are only used at compile time, not at run time.
Annoying that the site hijacks your back button history like a porn site. What’s up with that? Sure I want to give Typescript (or the equvilent) a try but this feels desperate if not an error.
TypeScript is one of the fastest-growing technologies in the JS ecosystem right now. It's unlikely the team is using the back button behavior as a way to get membership.
Incidentally, to which porn sites are you referring? Which of your favorite porn sites do you think do the best job with UI/UX?
this seems to be highly downvoted as i suppose people are reading it as a rude aside, but I read it as a feature worth highlighting. Microsoft has an excellent track record with language design, promotion, stability, and tooling.
What’s scary is the number of bugs in the original implementation! I made the comment on Reactuflux’s #typescript channel that I’m afraid to use code not written in TS now.
Anyway, it’s been interesting coming from the land of Python, and surprisingly quite enjoyable.
The Bulma library I’ve re-written and released on npm is https://www.npmjs.com/package/rbx