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

101–110 of 256 posts

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

#101

Post by somewhereoutth »

shepherdjerred wrote: post #97
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…

> Almost all bugs are logic bugs or inconsistent state bugs (thanks OOP!), almost none are type bugs. Many bugs of these classes can be avoided with a sufficiently expressive type system. There’s a reason that Haskell programmers say if it compiles, it probably works correctly.

Ah but Haskell was built that way from the beginning, and has important invariants (pure functions etc) that make it possible to produce inherently sound programs. Of course none of that will help you make the right inherently sound program.

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

#102

Post by somewhereoutth »

serverlessmania wrote: post #99
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…

Agree for the OOP part, most devs doing the transition from Java,C# to TypeScript are using the tool to port what they learned and apply it to a JS project and projects like Angular are encouraging this by enabling experimental stuff like decorators, but missing the real point behind TS, the type checking system which is to be fair, really awesome.

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).

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

#103

Post by shepherdjerred »

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…

OO programming is a very versatile paradigm, and not at all incompatible with JS/TS.

It comes down to choice; pick one for the project and be consistent. That’s all that matters.

DI does not require OOP, and you don’t need DI to write good TS/JS code. DI is common in OOP, but if you aren’t using OOP you don’t need DI anyway.

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

#104

Post by serverlessmania »

jcparkyn wrote: post #95
zarathustreal wrote: post #83

Earlier quoted context omitted.

>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 previou…

The problem with that is that eventually you want to have the dependencies automatically injected (like how an IoC container would be used in a typical OOP application). Sure, there's solutions for this in the FP world, but in my experience they tend to have their own drawbacks. Admittedly, I've only ever used TS on the front-end (with no DI), so I've never really looked at what FP-style libraries exist for this.

Are you seeing any decorator or OOP style in React? Yet plenty of dependencies are automatically injected without the OOP jargon, if you want to see a pure JS example of auto DI go check angular 1.5 dep system, and Vuejs.

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

#105

Post by softfalcon »

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 keep our stack mostly functional and that’s how it was done before me on our current project.

A few objects contain state like say a DB connection/client or a RequestContext you pass down through your request handler middleware’s. Those are an OOP class with an interface definition.

Everything else is just functions and closures. We also generate interface objects from our GraphQL types but that’s not a real OOP type, it’s just an interface.

If you keep to that structure, you’ll largely avoid the whole polymorphism OOP type hierarchy hell and all the dangers that come with it.

As for DI (dependency injection), that’s honestly just a fancy form of passing parameters down through function calls. Technically, the RequestContext I mentioned before is a “ball of mud” provider pattern DI code smell. So maybe down the road we will use DI to create more constrained context scopes.

If I do go that route for DI, I would likely strongly follow a CQRS style class pattern to inject objects and keep them nicely named and organized. Would also fit nicely pattern wise with the existing function + closures architecture.

But yeah, overall, stick to functions and closures, use OOP style classes sparingly and you’ll get the best of all worlds.

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

#106

Post by shepherdjerred »

jcparkyn wrote: post #95
zarathustreal wrote: post #83

Earlier quoted context omitted.

>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 previou…

The problem with that is that eventually you want to have the dependencies automatically injected (like how an IoC container would be used in a typical OOP application). Sure, there's solutions for this in the FP world, but in my experience they tend to have their own drawbacks. Admittedly, I've only ever used TS on the front-end (with no DI), so I've never really looked at what FP-style libraries exist for this.

Why do you need automatic injection? What the parent said is idiomatic FP

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

#107

Post by somewhereoutth »

edgyquant wrote: post #92
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…

Have you worked with typescript? Adding strict types to JavaScript fixes pretty much all the complaints I use to have when working with frontend services/clients. Typescript isn’t a “now you have two problems” anymore than types in any other language are.

Maybe in a controlled environment Typescript can produce benefits - however much of my argument is that our environments are typical uncontrolled, let's not give the monsters any more magic than we have to.

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

#108

Post by serverlessmania »

depaulagu wrote: post #82
WHATDOESIT wrote: post #47

Earlier quoted context omitted.

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?

You'll export a function from your esModule if you want to inject

export const myFn = (...deps) =>

You don't need anything else, for encapsulation you have the EsModule, that what OP meant.

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

#109

Post by softfalcon »

shepherdjerred wrote: post #103
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…

OO programming is a very versatile paradigm, and not at all incompatible with JS/TS. It comes down to choice; pick one for the project and be consistent. That’s all that matters. DI does not require OOP, and you don’t need DI to write good TS/JS code. DI is common in OOP, but if you aren’t using OOP you don’t need DI anyway.

I successfully used functional programming with DI and it was quite pleasant!

Because DI is just “give me the dependencies I need when I declare I need it” you can use simple classes as scopes similar to CQRS patterns and continue doing functional programming from there.

It’s quite neat how you can interchange between the two and have it work rather nicely.

Technically, you could even do the same thing with closures and avoid OOP style classes all together even.

DI lives on, it just looks a little bit different than the constructor injection we’re used to seeing in OOP.

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

#110

Post by rbonvall »

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…

> Almost all bugs are logic bugs or inconsistent state bugs (thanks OOP!), almost none are type bugs.

The whole point of using types is making inconsistent states type bugs. Types are logic.

This article presents a great example: https://fsharpforfunandprofit.com/posts/designing-for-correc...

Post reply on HN