Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn how to unleash the full potential of the type system of TypeScript

type-level-typescript.com

Post reply on HN
Print view View original

201–210 of 256 posts

Re: Learn how to unleash the full potential of the type system of TypeScript

#201

Post by schwartzworld »

galaxyLogic wrote: post #187
somewhereoutth wrote: post #91

> Over the years, the type system of TypeScript has grown from basic type annotations to a large and complex programming language. Give someone (particularly a developer) the opportunity to build something complicated and undoubtedly they will. So now you have two problems, the complicated program that actually does some hopefully useful work, and another complicated program on top of it that fills your head and slow…

A simple trick with plain JavaScript is to give all arguments default values. That gives a pretty good insight for anybody reading the code as to what "type" of arguments the function expects. If you test-call such a function without arguments you will then know what kinds of values you can expect it to return. The argument default values can not be inner functions but they can be any function that is in scope. Or if…

> That gives a pretty good insight for anybody reading the code as to what "type" of arguments the function expects. If you test

Only true if you're using very simple types, i.e. number and string. But "string" is pretty close to "any" and doesn't give you much info. If my function only expects two or three possible strings, it should be typed to only take those ones.

Comments are not a solution for much of anything, btw, and they only "work" if you read them. How many comments are in your node_modules folder?

Re: Learn how to unleash the full potential of the type system of TypeScript

#202

Post by leidenfrost »

Cthulhu_ wrote: post #189
cogman10 wrote: post #26

A great idea. Now, everyone that learns this stuff, show some restraint! The drawback of a powerful type system is you can very easily get yourself into a type complexity mudhole. Nothing worse than trying to call a method where a simple `Foo` object would do but instead you've defined 60 character definition of `Foo` capabilities in the type system in the method signature. Less is more.

"Duplication is better than the wrong abstraction" This is where a lot of developers go overboard - not just in type systems, but in general. They are so afraid of duplication, they over-generalize and end up in a quagmire of unreadable overly complicated code. Some duplication is easy. It's just code volume, and volume shouldn't be as scary as complexity.

The focus should be readability of code while respecting abstractions and design patterns.

I prefer some duplicate lines over having to go back and forth over some source files only because some developers think that less code is better code.

The code we create should be made for humans to read, no to machines and specially not to brag about how clever is our code

Re: Learn how to unleash the full potential of the type system of TypeScript

#203

Post by afiori »

xcambar wrote: post #141
jongjong wrote: post #140

Earlier quoted context omitted.

My coding philosophy is centered around simple interfaces. I think of power sockets and plugs. The simpler the socket/plug design, the easier it is to plug in. It's easier to connect a European plug which has 2 round pins than it is to connect a UK plug which has 3 rectangular pins at different angles. You can imagine how difficult it would be to connect a plug with 10 pins; it would be difficult to get the alignment…

I love the socket/plug analogy. It's even better than it looks in Europe: there are actuality 3 contact points but only 2 are salient which allows for 2 easily pluggable positions (rotate 180deg). The ground is positioned twice for that matter. Only France has a variation around that to my knowledge, that is still compatible across Europe. And no one notices and just plugs in and out without thinking twice about it.…

The EU has a huge variety of plugs and sockets, what people often call the EU plug are variation of the schuko[0] design. The standard EU plug is the Europlug[1] which is compatible with most (but not all) sockets in Europe and only handles low amperage.

AFAIK Italy is the major outlier in having widespread sockets[2] that do not accept the Europlug

[0] https://en.wikipedia.org/wiki/Schuko

[1] https://en.wikipedia.org/wiki/Europlug

[2] https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Ita... the one on the left, rated for 16A.

Re: Learn how to unleash the full potential of the type system of TypeScript

#204

Post by schwartzworld »

tunesmith wrote: post #45

Might as well ask here. On our teams, we have the occasional developer that is insistent on using Typescript in an OO fashion. This has always struck me as square peg round hole. Even though I come from an OO background, Typescript strict settings really seem to push me in a direction of using interfaces and types for type signatures, and almost never classes, subclasses, instantiated objects. I don't have a very goo…

I like classes but I'm in the minority. They are just syntactic sugar over functions, but I like the explicitness of them. If a closure works for you, that's great but there isn't an objective reason to use one over the other.

Re: Learn how to unleash the full potential of the type system of TypeScript

#205

Post by leidenfrost »

galaxyLogic wrote: post #185
johnfn wrote: post #75

Earlier quoted context omitted.

This is so true. I've been thinking recently that in the same way that "use boring technology" is a pretty well-known concept, so should "use boring types" enter the collective conscious. Type operators are exciting and flashy, but I found that using them too much leads to brittle and confusing types. Saving them for a last resort tends to be the right strategy. Often there's an extremely dumb way to write your types…

If you only use "simple types" then you often get implicit assumptions about the "values". For instance note that "web-services" basically means you have a very simple interface defined by the HTTP-protocol. But what is actually inside the HTTP-payloads can then have many constraints on them which are not declared anywhere. For instance your code might assume the payload is JSON with several required fields in it.

For that you have the "closed for modification but open for extension" principle.

If the server is new and fresh, yeah it's ok to assume the payload of a request will be a JSON object with some required fields, but leave the parameter there in case someone decides they will start sending XML payloads to it

Re: Learn how to unleash the full potential of the type system of TypeScript

#206

Post by Erlangen »

solardev wrote: post #147
nsxwolf wrote: post #143

I currently have to occasionally contribute to a TypeScript codebase at work. I appreciate how much better it is than Javascript. When I write code as an outsider (Java and Go developer), I feel like I use the type system in sensible and readable ways. When I look at the code written by the native TypeScript experts in my company it is a bewildering, abstract, unreadable morass. I have no idea what's going on half th…

Yeah, what a terrible syntax :( Just today I was looking at the type definition for a third-party lib (ramda)... what the heck does this even mean... compose (fn5: (x: T5) => T6, fn4: (x: T4) => T5, fn3: (x: T3) => T4, fn2: (x: T2) => T3, fn1: (x: T1) => T2, fn0: (x0: V0, x1: V1, x2: V2) => T1): (x0: V0, x1: V1, x2: V2) => T6; Got it?

If expressed in OCaml, it's just

let compose f5 f4 f3 f2 f1 f0 x0 x1 x2 = f5 (f4 (f3 (f2 (f1 (f0 x0 x1 x2)))))

whose signature is,

val compose : ('a -> 'b) -> ('c -> 'a) -> ('d -> 'c) -> ('e -> 'd) -> ('f -> 'e) -> ('g -> 'h -> 'i -> 'f) -> 'g -> 'h -> 'i -> 'b =

Re: Learn how to unleash the full potential of the type system of TypeScript

#207

Post by gvergnaud »

triyambakam wrote: post #73
theteapot wrote: post #65

Earlier quoted context omitted.

OK cool, now what about `Equal` :).

type Equal = A extends B ? (B extends A ? true : false) : false;

Actually, this won't work with union types! The definition of `Equal` I use is this one:

type Equal = (() => T extends X ? 1 : 2) extends () => T extends Y ? 1 : 2 ? true : false;

Understanding this requires a bit more context, but I'll explain why we need something so complicated in the Advanced Union Types chapter :)

I picked it from https://github.com/type-challenges/type-challenges which is an awesome resource too

Re: Learn how to unleash the full potential of the type system of TypeScript

#208

Post by krembanan »

simlevesque wrote: post #5

Wow I think I know a lot of Typescript but I'll have to go through it because I'm always asked for ressources to get started and this one seem great. I also recommend type-challenges: https://github.com/type-challenges/type-challenges It works great with the VSCode extension.

> It works great with the VSCode extension.

What do you mean? Which extension?

Re: Learn how to unleash the full potential of the type system of TypeScript

#209

Post by somewhereoutth »

wk_end wrote: post #122
somewhereoutth wrote: post #102

Earlier quoted context omitted.

Yes, there is a huge difference between type checking a minimally type-annotated program, and dreaming up a rich type system just because you could (I should know, I used to be a Java dev).

You're giving yourself away by making that comparison - your experience as a Java dev gives you minimal insight into the expressiveness or utility of TypeScript's very different, much more powerful type system.

It's not about the expressiveness or utility - it is about types you write (bad) vs types the type checker generates and maybe shows you in an IDE (good).

The point being that people should write actual code, and should not write type code, simply because given an opportunity to write things, people will indeed write things, whether actually helpful or (more likely) not.

Re: Learn how to unleash the full potential of the type system of TypeScript

#210

Post by kuschku »

laumars wrote: post #164
jongjong wrote: post #140

Earlier quoted context omitted.

My coding philosophy is centered around simple interfaces. I think of power sockets and plugs. The simpler the socket/plug design, the easier it is to plug in. It's easier to connect a European plug which has 2 round pins than it is to connect a UK plug which has 3 rectangular pins at different angles. You can imagine how difficult it would be to connect a plug with 10 pins; it would be difficult to get the alignment…

The thing with electrical plus is that they should be designed around safety first, rather than convenience. And the U.K. plug is a lot more safety focused than many other plug standards. The advantage of the U.K. plug is that live pins are physically blocked and only released when the Earth pin is present. This is why the Earth pin is slightly longer on U.K. plugs and why insulated devices have a plastic Earth pin r…

And now try the Schuko, which improves on all metrics you named (except the polarity isn't fixed, that's its one theoretical disadvantage), but also significantly improves usability (you can plug it in either way, the plug goes in much easier, and it stays in with much more force)
Post reply on HN