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

41–50 of 256 posts

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

#41

Post by kbr- »

Is there any place I could report issues or ask questions about the course other than Twitter?

If the author is reading this, the proposed solution to the `merge` challenge is:

  function merge(a: A, b: B): A & B {
    return { ...a, ...b };
  }
That's the "obvious" solution, but it means that the following type-checks:

  const a: number = 1;
  const b: number = 2;
  const c: number = merge(a, b);
That's not good. It shouldn't type check because the following:

  const d: number = { ...a, ...b };
does not type check.

And I don't know how to express the correct solution (i.e. where we actually assert that A and B are object types).

Also, looking forward to further chapters.

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

#42

Post by 323 »

rideg wrote: post #40
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…

You can use type guards for something similar: https://www.typescriptlang.org/docs/handbook/advanced-types....

Keyword similar. I use type guards for other things (like typing JSON responses), but they can't solve this particular problem.

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

#43

Post by gitowiec »

Hi n I have a question. I will go as simple and short as possible. I joined a small team working on the internal invoicing tool. Backend is Spring. Front-end is ExtJS used for me in very peculiar way. It emulates Java classes, there are Ext.define declarations with FQN names eg: "com.projectName.ds.Board.ui.extjs" (as string, casing important) Then in the code this class is instantiated by its FQN but used as identifier eg: var Board = new com.projectName.ds.Board.ui.extjs(); There are also a lot of FQNs with short namespaces, different are associated with business short names and other like Dc, Ds, Frame belong to code architecture domain (data controller, data store, a frame on the screen). How I could use typescript to improve developer experience here? I'm from the react world, I programmed 4 years only in typescript, react, node and mongo. Thanks!

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

#44

Post by KrishnaShripad »

kbr- wrote: post #41

Is there any place I could report issues or ask questions about the course other than Twitter? If the author is reading this, the proposed solution to the `merge` challenge is: function merge (a: A, b: B): A & B { return { ...a, ...b }; } That's the "obvious" solution, but it means that the following type-checks: const a: number = 1; const b: number = 2; const c: number = merge(a, b); That's not good. It shouldn't ty…

> And I don't know how to express the correct solution (i.e. where we actually assert that A and B are object types).

You can do this:

  function merge,
    B extends Record
  >(a: A, b: B): A & B {
    return { ...a, ...b }
  }

  const result = merge({ a: 1 }, { b: 2 })

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

#45

Post by tunesmith »

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

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

#46

Post by ttymck »

KrishnaShripad wrote: post #44
kbr- wrote: post #41

Is there any place I could report issues or ask questions about the course other than Twitter? If the author is reading this, the proposed solution to the `merge` challenge is: function merge (a: A, b: B): A & B { return { ...a, ...b }; } That's the "obvious" solution, but it means that the following type-checks: const a: number = 1; const b: number = 2; const c: number = merge(a, b); That's not good. It shouldn't ty…

> And I don't know how to express the correct solution (i.e. where we actually assert that A and B are object types). You can do this: function merge , B extends Record >(a: A, b: B): A & B { return { ...a, ...b } } const result = merge({ a: 1 }, { b: 2 })

Why Record and not object?

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

#47

Post by WHATDOESIT »

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.

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

#50

Post by 323 »

agentultra wrote: post #17

Nice course, and nice site. Although, as a Haskell developer, I am curious what type system TS is using (System F? Intuitionist? etc) and what limitations one can expect. Aside from the syntax of TS being what it is, what are the trade-offs and limitations? I was under the impression, and this was years ago -- things are probably different now?, that TS's type system wasn't sound (in the mathematical logic sense).

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.
Post reply on HN