91–100 of 194 posts
But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?
It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?
Talking specifically Angular 1 if you have one, otherwise a general tutorial is fine.
I'm interested in whether it is worth the effort migrating a pretty large frontend codebase.
The thing with 3rd party libs is, often there are no type defs, especially bleeding edge stuff :/ Also VSC often is flunky with picking up defs... sometimes you open a file and some are missing. Or imports with numbers don't work. On the other hand, using big libs like babylonjs is charming with all the auto complete :)
I see a lot of Angular comments, has anyone had good/bad experiences with TypeScript and React?
From a React newbies's perspective, the React community is much more in the es6 camp than Typescript. Many of the starter kits are in es6. It's not a huge deal. I actually write most of my front-end code these days in Aurelia, which is written in es6, but they actually have type annotations which Babel knows how to deal with. So basically the tooling can auto-generate the *.d.ts files for you. That said, Typescript n…
It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?
Tests are weak evidence of the validity of a piece of data at runtime. Types are proof. The stronger your type system, the more you can prove.
Certainly type checking can prove that it's the right type, but in my experience knowing that it's the right type but the wrong data is useless, I care if it's the exact data it's supposed to be.
How does type checking protect you (or someone else) from inadvertently mutating a value without changing it type and causing problems later? It's perfectly possible to do this without having any checks for class/instance throw a warning, unless there's something I'm missing.
Earlier quoted context omitted.
I was just about to complain how TS fails totally for typechecking backbone models or immutablejs datastructures: both situations where obj.get("foo") and obj.get("bar") return a particular type but there's no way of having TS handle that except defining them as any. But it turns out string literal types in 1.8 will make that work. And this was out since February! I should reevaluate TS for my omniscient project.
IIRC there is no ergonomic way to define typed records for Immutable.js ?
It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?
It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?
Check out some typescript tooling videos, this one was shown at an angular 2 conference but you don't need to know any angular to watch it:
I just wish TS was based on CoffeeScript.
If something is written in typescript it doesn't matter if you don't know it. Just write what you want to change in javascript. All javascript is typescript.