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

191–200 of 256 posts

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

#191

Post by jamil7 »

wk_end wrote: post #121
antipurist wrote: post #88

Earlier quoted context omitted.

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.

It's more fun, but your fun shouldn't come in the way of getting work done - or worse, getting in the way of others getting their work done.

I wouldn't say it's a matter of fun but often a matter of necessity in modern software development. Less experienced people can often have inflated egos and will refuse to listen to any advice from anyone else. Letting them fuck something up themselves (not too badly) after you've explained why it's a bad idea can be a hard but good lesson.

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

#192

Post by cjonas »

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.

I just finished writing a mess of very complicated types that can parse an open API spec, provide the request types (body & params) as input, and restrict the return to the appropriate response type... I hooked this higher order function into our API and immediately found 30-40 different places where the implementation was not aligned with the spec.

The devs now have guardrails in place to make sure they follow the spec...

Advanced types are invaluable when you are writing a framework or library... But in every day implementation, I agree they should be used sparingly.

I have 7 years of ts experience and I'll still 'as any' a reduce function from time to time

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

#193

Post by spion »

derangedHorse wrote: post #129
spion wrote: post #79

Earlier quoted context omitted.

Request-scoped DI (as seen in ASP.NET MVC) is great on the backend for servicing requests. You can ask for e.g. a class representing the current user information to be injected anywhere, or to keep track of request-associated state like opentelemetry spans, or a transaction, etc. The alternative is to pass the user information class or transaction to all other services, which can be annoying Its rarely seen in the ec…

The IoC is a nice paradigm that I tried using with a couple different libraries in JS, but they all felt like they had missing features and sometimes were annoying to run tests with (depending on the how they implemented the IoC container within their frameworks). The work Microsoft puts into their web frameworks to make them so cohesive with the rest of their ecosystem libraries is sometimes underrated

Yeah, the designs of DI libraries in TS land often leave me wondering what the author was thinking.

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

#194

Post by gherkinnn »

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…

Some native JS constructs are class-based (or constructed using the new keyword). Promises, for example [0]. Nothing wrong the odd class here and there.

Though I would be wary of introducing patterns and paradigms that make sense in a different language when Typescript offers an ultimately simpler solution. Working against the grain helps nobody. Goes for both OOP and FP, really.

ES modules, functions, and well designed TS models get you 95% of the way.

0 - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#195

Post by iainmerrick »

jcelerier wrote: post #89
iainmerrick wrote: post #63

Earlier quoted context omitted.

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

You’re right, I was just thinking about dynamic reflection.

My concern is with fiddly runtime stuff like “instanceof” -- I find that can go wrong in surprising ways. Better to just trust values to implement the interface they say they implement rather than trying to forcibly cast them.

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

#196

Post by valenterry »

solardev wrote: post #183
valenterry wrote: post #179

Earlier quoted context omitted.

From what you are writing, you really lack the basics here. Learning on the job is fine, but sometimes it's worth to spent dedicated time to learn foundations or at least get someone on board who can teach them. I suggest to try to get your boss to sponsor this, since you need it for the job. It will also make your dev experience so much more fun!

For sure. I am no TypeScript expert, and for the most part I don't really need to be... most of our types are pretty straightforward, arrays of strings and such. Learning is great, but this job, like many others, doesn't really have a well-defined system for training, documentation, professional development, or anything like that. Either I learn on the job as it happens or I don't learn at all. There's always too muc…

I think I see where you come from. And for libraries and even frameworks I would agree.

But typescripts advanced features are more like advanced SQL. Sure, you'll learn some chunk specific to your database, but the majority will be transferable. And just like SQL it won't become outdated knowledge in the next decades most likely.

So I still think it will be worth. If not for the company then at least for yourself. :)

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

#197

Post by Akronymus »

somewhereoutth wrote: post #101
shepherdjerred wrote: post #97

Earlier quoted context omitted.

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

And it doesn't stop certain kinds of logic bugs (mixing up adding and subbing for example) but it VASTLY reduces the kinds of bugs you tend to have.

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

#198

Post by Akronymus »

osigurdson wrote: post #137
softfalcon wrote: post #109

Earlier quoted context omitted.

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…

Do you mean something like this: f(arg1, arg2, arg3, deps)?

As I am not familiar with TS, I am gonna use F# as an example:

    let sort (iterator: 'b -> 'a list) (collector: 'a list -> 'c) (comparator: 'a -> 'a -> bool)  (collection: 'b) -> 'c =
        ...
I added the type annotations to, hopefully make it clear. The iterator is a helper to convert some arbitrary collection to a list, with the collector turning it back into a collection type again (not necessarily the same.)

For example, the iterator could map from a tree to a list, and the collector then to an array. Or if you already have a list and want a list back, you could pass in the identity function for those.

One call could be the following:

    sort id id (>) somelist
Hope it isn't too unreadable.

Edit: Adjusted the order of the arguments, as the original order wouldn't work too well with partial application.

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

#199

Post by Akronymus »

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.

You could model that with one function taking that dependency and returning a new one with it included. Then you just use the one that has it included instead of the one that doesn't.

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

#200

Post by j1elo »

jongjong wrote: post #140
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.

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…

USB-C would be a nice looking single-argument function... but parameterized with every possible generic template meta-programming feature in the language.
Post reply on HN