Tricks I wish I knew when I learned TypeScript • Hacker News Board

Re: Tricks I wish I knew when I learned TypeScript

#171

Post by dllthomas » Tue, Oct 12, 2021, 7:02 PM UTC

marginalia_nu wrote: post #140

jjice wrote: post #122

I'm so happy powerful type systems are more popular now. TypeScript bringing a great type system to a language as popular as JS is fantastic. Rust is also a great way to get a great type system while staying in a systems programming and procedural environment. Hell, even python type annotations support union types. I never knew the depth of type systems until the last year when I took a type theory course and a compi…

The grass does seem tend to appear greener in the other paradigm. Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Writing anything nontrivial with duck typing made more elaborate type systems seem appealing. Needing a PhD in category theory to produce a side effect will no doubt make some other para…

I think the major shift was that originally types were used mostly to talk about representation. Then we wound up in a situation where caring that much about representation didn't make sense as often (at this point it's at system boundaries and when we care an unusual amount about performance) and so it made sense for some languages (covering a growing portion of programming) to stop talking about representation. But it turns out there are other useful things that we can use similar technology to "talk about" as we learn to build better tools and to better apply them.

Re: Tricks I wish I knew when I learned TypeScript

#172

Post by pbowyer » Tue, Oct 12, 2021, 7:05 PM UTC

Etheryte wrote: post #118

EnderShadow8 wrote: post #2

Note: don't use typeof x === 'object' to check whether something is a valid object, because it will return true for arrays as well. Arrays are objects, so this is expected behaviour.

The core problem here is that you don't actually want to check if something is an object, but whether it matches the Human type. The correct way to do that is to define a type guard [0], for example: function isHuman(input: any): input is Human { return ( Boolean(input) && Object.prototype.hasOwnProperty.call(input, "name") && Object.prototype.hasOwnProperty.call(input, "age") ); } There are libraries which can autom…

> There are libraries which can automate this for you which is the route I would recommend

Which libraries do you recommend? I've had to do this a couple of times in my current project and it's painful (and I made mistakes).

Re: Tricks I wish I knew when I learned TypeScript

#173

Post by mynameisash » Tue, Oct 12, 2021, 7:05 PM UTC

remram wrote: post #109

IggleSniggle wrote: post #102

Earlier quoted context omitted.

I disagree. `null` in TypeScript is equivalent to `None` in many other typed languages. `undefined` in Typescript is like null in other languages, with the caveat that if you’re working to transition an untyped codebase and trying to bring types, there may be a useful place for `undefined` in order to express that there is a lack of safety / strict-handling in that area. I’m still not sure about Error handling, thoug…

Which language has both a "None" and "null"?

Scala, as I recall. It encourages using Options (Some/None), but since it runs on the JVM and will often interop with Java libraries, you can also have nulls.

Not exactly a language design, but an unfortunate reality.

Re: Tricks I wish I knew when I learned TypeScript

#174

Post by goto11 » Tue, Oct 12, 2021, 7:15 PM UTC

throwanem wrote: post #158

ebingdom wrote: post #144

Earlier quoted context omitted.

> Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Eh, I consider Java to be barely typed too. If you have a variable of type Foo, the type system doesn't even guarantee that you have a Foo in there (it might be null). The whole point of a type system, in my mind, is to guarantee that I have that Foo…

I'd love to see an explanation of monads that accurately captures their capabilities in terms no more complex than those required to do the same for promises.

Monads are a pattern for function or method chaining.

Re: Tricks I wish I knew when I learned TypeScript

#175

Post by mikojan » Tue, Oct 12, 2021, 7:20 PM UTC

Etheryte wrote: post #118

EnderShadow8 wrote: post #2

Note: don't use typeof x === 'object' to check whether something is a valid object, because it will return true for arrays as well. Arrays are objects, so this is expected behaviour.

The core problem here is that you don't actually want to check if something is an object, but whether it matches the Human type. The correct way to do that is to define a type guard [0], for example: function isHuman(input: any): input is Human { return ( Boolean(input) && Object.prototype.hasOwnProperty.call(input, "name") && Object.prototype.hasOwnProperty.call(input, "age") ); } There are libraries which can autom…

This approach is "correct" only when you're interacting with an API you have no control over whatsoever because specifying all this and maintaining it is really error prone.

All this boilerplate is not a proof. It remains an assertion. And so in most cases you might as well just add a "type"/"kind" property to your object (or create a class).

Re: Tricks I wish I knew when I learned TypeScript

#176

Post by yesbabyyes » Tue, Oct 12, 2021, 7:31 PM UTC

errantspark wrote: post #107

handrous wrote: post #71

Earlier quoted context omitted.

> Everything that TS does JS libraries do better Which ones do you need to do everything TS does? > without the horrible tradeoffs Which tradeoffs are horrible?

Not OP but I do tend to avoid TS. I don't like the additional friction of working with the language (transpiling, unable to copy/paste directly into an interpreter). I also feel like the community at large writes awful baroque code that makes me want to die. Why use a function when 18 classes subclassing eachother across 4 files will do? If you're familiar with the tiktoker @khaby.lame, TS feels like exactly the over…

I've found the perfect middleground is typescript checking with JSDoc syntax. The code is just JS, no emitting necessary, but you get all the type checking.

Together with testing of @example stanzas, you get everything for cheap-ish.

Alas, there is no good JSDoc @example test runner¹. This would be very valuable. If there were, I would let that handle my unit tests and focus only on integration testing.

Edit: runtime type checking at the boundary is also valuable! I've tried runtypes, but actually prefer compiling the ts definitions to JSON Schema with typescript-json-schema, and checking with plain JSON Schema validation.

¹I've used @supabase/doctest-js and jsdoctest, and found both lacking. If you know of a better one, please share!

Re: Tricks I wish I knew when I learned TypeScript

#177

Post by sibeliuss » Tue, Oct 12, 2021, 7:34 PM UTC

btbuildem wrote: post #166

"any" is such a cop-out, it's a shame it exists. You can't eat your cake and have it too.

`any` is one of the main reasons why typescript is now so popular. Its a dev-conversion tool. It's amazing for teams that aren't ready to make the full leap. But later migration to strict mode is necessary.

Re: Tricks I wish I knew when I learned TypeScript

#178

Post by Choc13 » Tue, Oct 12, 2021, 7:34 PM UTC

throwanem wrote: post #158

ebingdom wrote: post #144

Earlier quoted context omitted.

> Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Eh, I consider Java to be barely typed too. If you have a variable of type Foo, the type system doesn't even guarantee that you have a Foo in there (it might be null). The whole point of a type system, in my mind, is to guarantee that I have that Foo…

I'd love to see an explanation of monads that accurately captures their capabilities in terms no more complex than those required to do the same for promises.

I had a pop at this here https://dev.to/choc13/grokking-monads-in-f-3j7f

Re: Tricks I wish I knew when I learned TypeScript

#179

Post by recursive » Tue, Oct 12, 2021, 7:38 PM UTC

btbuildem wrote: post #166

"any" is such a cop-out, it's a shame it exists. You can't eat your cake and have it too.

Then turn it off with your compiler options. Typescript never would have gained significant adoption without it. It's essential for gradual conversions from js codebases.

Re: Tricks I wish I knew when I learned TypeScript

#180

Post by toxik » Tue, Oct 12, 2021, 7:41 PM UTC

underdeserver wrote: post #162

ebingdom wrote: post #144

Earlier quoted context omitted.

> Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Eh, I consider Java to be barely typed too. If you have a variable of type Foo, the type system doesn't even guarantee that you have a Foo in there (it might be null). The whole point of a type system, in my mind, is to guarantee that I have that Foo…

I know dozens of people who tried understanding Promises and all of them succeeded. I know dozens of people who tried to understand monads (including myself) and maybe 3 of them succeeded (I do not consider myself one of them).

A monad is just a monoid in the category of endofunctors, what's the problem?