by tsujp on 3/3/23, 4:56 AM with 90 comments
by quickthrower2 on 3/3/23, 8:03 AM
I really like the ‘unknown’ type. In catch statements for example the error is unknown but you can do dynamic checks to see what it is, then typescript lets you treat it that way.
by CGamesPlay on 3/3/23, 6:39 AM
by myfonj on 3/3/23, 1:19 PM
// @ts-check
/// <reference path="./ts-reset-0.3.7/src/entrypoints/recommended.d.ts"/>
// = contents of the archive from
// https://github.com/total-typescript/ts-reset/releases
const allCurrencies = /** @type {const} */(["EUR", "USD"]);
/**
* @typedef {typeof allCurrencies[number]} currency
*/
allCurrencies.includes('XXX');
// No 'Argument of type '"XXX"' is not assignable…' error any more.
// Would be that error without ts-reset.
/** @type {currency} */
let foo = 'EUR'; // OK
/** @type {currency} */
let bar = 'XXX'; // that error, expected
by olalonde on 3/3/23, 7:49 AM
by jillesvangurp on 3/3/23, 8:04 AM
Kotlin and typescript are actually similar enough that transitioning from one to the other isn't that big of a deal. The key difference is that typescript tries to maintain compatibility with javascript whereas it's just a compilation target for kotlin-js.
Like with typescript, you use type safe wrappers for any javascript code you need to access. You can actually reuse typescript type definition files and generate Kotlin ones from them. Not perfect, sadly, but it works for simple libraries and you can manually deal with the more complicated ones. I use things like fluent-js, maplibre, and a few other libraries. I don't use react, but a lot of kotlin-js developers do. There are no real limitations on what you can use here.
The one compromise kotlin-js makes to enable interfacing with javascript code is the dynamic keyword, which you use to do the bait and switch style APIs you see a lot in the javscript world. It could be a list, a number, or a string, etc. Dynamic allows you to work with such APIs. It's a necessary evil. But otherwise, it's all good. It's strict by default. It doesn't have a mode where it is not strict. And this is what enables IDEs like intellij to be a lot smarter with Kotlin than it is with typescript.
If you ignore the few syntax and language features that are unique to either Kotlin or Typescript, the key difference is that typescript is more sloppy and it's mostly because of js compatibility. And since kotlin-js has almost none of that and can manage fine without it, it kind of proves that this level of sloppiness is simply unnecessary and redundant. A whole lot of downsides and not a lot of upsides. Typescript is much more sloppy than it needs to be. Making it less sloppy is the obvious way to improve it. It's why I use kotlin-js instead.
by redmorphium on 3/3/23, 6:17 AM
by mrblampo on 3/3/23, 11:50 AM
[1, 2, undefined].filter(Boolean). // number[]
is interesting because it makes use of the fact that the types of individual array members are known at compile time. I can think of some times when I have dealt with arrays that are defined at compile time, but not where I've needed to call .filter on such an array. Is there a common use case here?
by raydiatian on 3/3/23, 6:43 AM