Live data from Hacker News

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

type-level-typescript.com

121–130 of 256 posts

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

#121

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.

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.

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

#122

Earlier quoted context omitted.

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

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.

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

#123

Earlier quoted context omitted.

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.

ah, thanks, I thought it was something different.

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

#124

Earlier quoted context omitted.

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.

So less can be more but more can also be more, more or less?

Exactly. "More" and "less" are pretty much wrong ways to measure it.

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

#125

Earlier quoted context omitted.

People who are trying to statically describe the behavior of highly dynamic JavaScript code.

Yeah but how is Turing completeness directly relevant to that? Article doesn't seem to explain, just says "Turing Complete" in the title. Again, so what? I suppose it's somewhat indirectly vaguely reassuring? P.S. You might like this http://beza1e1.tuxen.de/articles/accidentally_turing_complet...

[deleted]

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

#126

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

Sooooo agree. Let's layer an abstraction on top of an abstraction to abstract the abstraction.

Everything is an abstraction, even physical reality. "Concrete" is just a term for an abstraction that's useful. Typescript is certainly useful.

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

#127

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

Hard disagree. For me, the proof is in the pudding. When writing regular Javascript, I need to run and debug my code often as I'm developing it to make sure all intermediate states make sense and that there's no edge cases I've missed. With Typescript I can often write code for hours without even starting it up, and when I finally do run it, it usually works correctly right out of the box.

I recently started working on a project with typescript for the first time. I have been astounded by how often my code works the first time I try it because so much is caught by the typing system. I know what I want my code to do, how it should do it, and that it does work - my errors are almost all from mistyping things.

Massive productivity boost, and I have a kind of confidence in my code that I never have had before, not having used a strongly typed language before.

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

#128
One of the worst things about Next.js, Remix etc. is their file system driven routes. I really wish these frameworks would stop relying so much on hidden magic. Conventions are good, but as to why those conventions aren't in code is quite peculiar.

Previously, I wrote my route definitions with types for both path params and query params in one file, and used TypeScript to enforce that the equivalent back-end definitions (async loaders etc.) and front-end definitions (React components) were kept in sync.

When I first implemented this in a previous project, I found many instances where routes were expecting query params but they were being dropped off (e.g. post login redirects).

Supporting things like parameters for nested routes certainly means the TS types themselves are non-trivial, but they're the kind of thing you write (and document) once, but benefit from daily.

Examples of stuff that can and should be 100% type checked:

  // ...
  template: {
    path: idPath("/template"),
    subroutes: {
      edit: { path: () => "/edit" },
      remix: { path: () => "/remix" },
    },
  },
  onboarding: {
    path: () => "/onboarding",
    query: (params: { referralCode?: string }) => params,
    subroutes: {
      createYourAvatar: { path: () => "/createyouravatar" },
    },
  },
  // ...
Routing:

  // Path params
  navigate(routes.template.edit({ id: props.masterEdit.masterEditId }));
  // No path params, just query params (null path params)
  navigate(routes.onboarding(null, { referralCode }))
  // Nested route with query params (inherited from parent route)
  navigate(routes.onboarding.createYourAvatar(null, { referralCode }))

React hooks:

  // Path params
  const { id } = useRouteParams(routes.template.edit)
  // Query params
  const { referralCode } = useRouteQueryParams(routes.onboarding);
API routes:

  // ...
  play: {
    path: () => "/play",
    subroutes: {
      episode: {
        path: idPath("/episode"),
      },
    },
  },
  // ...
Relative route paths (for defining nested express routers):

   const routes = relativeApiRoutes.api.account;
   router.post(routes.episode(), async (req: express.Request, res: express.Response) => {

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

#129
post #79
post #53

Earlier quoted context omitted.

This. Creating classes to wrap dependencies is a pattern only needed because of language limitations. With JS/TS, you can mock at the import statement level, so no need to twist your code to abstract away importing. Also, even if you didn't want to mock that way, you can get dependency injection with functions just by taking a parameter for a dependency. If dependency injection is the only reason you have to use a cl…

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

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

#130

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.

Ah, the "smoke a whole pack of cigarettes" method of teaching software dev.

I kinda agree - often no amount of "this is a bad idea" will teach as well as just letting someone make the mistake and actually experience the consequences.

The only problem is that hard to maintain code often does not cause any problems until you write a critical mass of it and end up trying to develop enough non trivial extra features on top of it.

Post reply on HN