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

81–90 of 256 posts

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

#81

Post by spion »

agentultra wrote: post #54
323 wrote: post #50

Earlier quoted context omitted.

Non-soundness is sort of a feature, it lets you force your way through and just say "trust me, this is a Thing" when it's just hard (or impossible) to make TypeScript see that. In practice, you can write large code bases where you only need to do this every 1000 lines or so. Not ideal, but better than no typing.

Is it fair to say that the limitation is that the type checker can admit programs that are not type correct?

You can make "believe_me" assertions, which is incredibly useful when writing advanced (metaprogramming heavy) library code. The idea is to try and contain / and heavily test the small "unsafe" library part and isolate it from the rest of the code, then enjoy the advanced type transformations and checks in the "normal" application code.

For example, an SQL query builder library may internally do unchecked assertions about the type of the result row that a query transformation would produce (e.g. group_by), however assuming that part is correct, all application code using the query builder's group_by method would benefit from the correct row types being produced by `group_by` which can then be matched against the rest of the application code.

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

#82

Post by depaulagu »

WHATDOESIT wrote: post #47
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…

An ES module is encapsulated enough. You can dependency inject with them as you wish. It's like having a class, no need for a class inside a class. The biggest argument is that my functional-ish code is always 3x shorter with the same features, though.

How do you dependency inject a ES module?

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

#83

Post by zarathustreal »

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 don't have a very good answer for "yeah, but what about dependency injection"? though. Any thoughts from anyone?

There is no "dependency injection" in a functional world, take this opportunity to show your colleague how FP makes their life easier. It's just a function.

Instead of a class, implementing an interface, created by a factory, requiring a constructor, all you need is a function.

Anything that was previously a "dependency" in OO terms is now an argument to your function. If you want to "inject" that dependency you simply partially apply your function, the result is then of course a function with that "dependency" "injected" which can then be used as usual. In JavaScript there's even a nifty built-in prototype method on every function called `Function.prototype.bind` which allows you to do the partial application to create the "dependency injected" function!

Example:

```

const iRequireDependencies = (dependencyA, dependencyB, actualArgumentC, actualArgumentD, ...etc) => console.log(dependencyA, dependencyB, actualArgumentC, actualArgumentD, ...etc);

const withRandomDependencies = iRequireDependencies.bind(undefined, 'randomA', 'randomB')

withRandomDependencies('actualA', 'actualB', 'actualC', 'actualD', 'actualE') // etc

// => 'randomA' 'randomB' 'actualA' 'actualB' 'actualC' 'actualD' 'actualE'

```

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

#84

Post by int_19h »

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…

Interfaces are late bound, which, in conjunction with the concept of object identity and state, is OO. Subclassing is merely one specific approach to code reuse within the OO paradigm.

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

#86

Post by cogman10 »

marcosdumay wrote: post #32
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.

The types in your code are just as designed just like any other aspect of it. It's not a matter of restraint, it's a matter of doing things on the correct way.

I don't believe in "correct" when it comes to software dev. There's 1000 solutions to any given problem.

It's a matter of choosing a solution that is clear, easy to understand, and easy to maintain. There are nearly limitless solutions that can fit that definition.

Restraint comes into play because devs tend to "treat every problem like a nail when they have a hammer". When devs learn new concepts, they often look for places to use that concept even when it's a bad fit.

An example of this is excessive use of inheritance when simpler types fit better. Many of us have dealt with the greenhorn that creates a giant inheritance tree or generic mess after they first learn that "neat" concept.

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

#87

Post by nodejsthrowaway »

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…

No post body was provided.

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

#88

Post by antipurist »

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.

No need to show any restraint. It's much more fun to explore and burn yourself once into understanding how much of this power your need. Or twice. Or as many times until it gets more fun to be pragmatic.

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

#89

Post by jcelerier »

iainmerrick wrote: post #63
323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

I think that’s actually a positive feature of TypeScript -- a useful limitation. Reflection is generally a bad idea and it’s good to be forced to do without it. It is a bit annoying sometimes that you can’t have overloaded functions with different types, but in that case you can usually just give the overloads different names, and usually that’s better for readability anyway. (Or if you really want to, write one func…

> Reflection is generally a bad idea

it is not - dynamic reflection certainly has its issues, but static reflection is absolutely fine

> it’s good to be forced to do without it.

it just leads to people reinventing it even more badly with separate tools

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

#90

Post by nawgz »

likeclockwork wrote: post #67
323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

That boundary is why I have a hard time taking TypeScript seriously. A type system that doesn't participate in code generation is what.. just for linting and documentation basically? Is that what we are become? Is that all people think a type system is good for? Worse there is one value that is both a user-definable TypeScript type and a JS value.

> That boundary is why I have a hard time taking TypeScript seriously. A type system that doesn't participate in code generation is what

How is being able to check code correctness at compile-time even close to "just linting and documentation basically"? This has to be a bad faith argument

> Worse there is one value that is both a user-definable TypeScript type and a JS value.

What does this even mean? I don't think you understand TypeScript.

Post reply on HN