Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tricks I wish I knew when I learned TypeScript

cstrnt.dev

Post reply on HN
Print view View original

41–50 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#41

Post by amitport »

jeswin wrote: post #8

Here's another. Instead of returning Sometype|undefined from a function which may or may not have a value to return (such as searchCustomer), return Sometype|null. That forces the function to return a value that's explicitly intended rather than defaulting from a missed out if-else codepath. This is useful since JS is often imperative style code.

You can declare Sometype|void return type. So the compiler will check that you either don't use the return type or treat it as Sometype. Of course this depends on the logic and for failed routes you should return appropriate results.

Re: Tricks I wish I knew when I learned TypeScript

#42

Post by henriks »

charesjrdan wrote: post #38

Is there ever a reason to use interface over type? From what I’ve seen it looks like they can both do the same thing but with slight differences in syntax

One detail I stumbled upon the other day is that interfaces can use the `this` keyword to refer to the type implementing the interface. This isn't supported for types afaik.

https://www.typescriptlang.org/docs/handbook/advanced-types....

Re: Tricks I wish I knew when I learned TypeScript

#45

Post by conaclos »

charesjrdan wrote: post #38

Is there ever a reason to use interface over type? From what I’ve seen it looks like they can both do the same thing but with slight differences in syntax

In my knowledge, there are some differences:

- in error reporting: type aliases may be replaced by their definition in error reporting.

- you cannot create union types with interfaces

- legacy versions of TypeScript does not enable to create recursive type aliases such as type `List = {v: V, right: List | undefined }`

- interfaces with same name are merged

However the frontier between type aliases and interfaces seems more and more blur. Generally interfaces are encouraged over type aliases. I personally prefer type aliases because there are more capable and seems more elegant to me. However their poor support in error reporting makes me rely more on interfaces when possible.

Re: Tricks I wish I knew when I learned TypeScript

#46

Post by kkirsche »

charesjrdan wrote: post #38

Is there ever a reason to use interface over type? From what I’ve seen it looks like they can both do the same thing but with slight differences in syntax

“Type aliases and interfaces are very similar, and in many cases you can choose between them freely. Almost all features of an interface are available in type, the key distinction is that a type cannot be re-opened to add new properties vs an interface which is always extendable.” …

“For the most part, you can choose based on personal preference, and TypeScript will tell you if it needs something to be the other kind of declaration. If you would like a heuristic, use interface until you need to use features from type.” https://www.typescriptlang.org/docs/handbook/2/everyday-type...

Re: Tricks I wish I knew when I learned TypeScript

#47

Post by 3np »

throwanem wrote: post #3

The third example describes something useful in record types, but goes about it in what seems an odd way, and ends up suboptimal as a result. I'd instead use an object type like this: type Human = { name: string; age: number; } which also enforces value types in the compiler, rather than requiring runtime guards.

I think the example type is useful for unvalidated input data e.g. from an API call. Or an update function for a DB abstraction.

Internally in the backend, you’d still use the type you just posited.

Re: Tricks I wish I knew when I learned TypeScript

#48

Post by Fckd »

WA wrote: post #7
EnderShadow8 wrote: post #2

Note: don't use typeof x === 'object' to check whether something is a valid object, because it will return true for arrays as well. Arrays are objects, so this is expected behaviour.

Note: please post a better solution.

x && !Array.isArray(x) && typeof x === 'object'.

its typical to start off with `var &&` to avoid operations on null & undefined values

Re: Tricks I wish I knew when I learned TypeScript

#49

Post by jwalton »

otrahuevada wrote: post #40
WA wrote: post #7

Earlier quoted context omitted.

Note: please post a better solution.

a simple solution would be > if(entry && entry.constructor === Object){}

This isn't a great solution:

    entry = Object.create(null);
    entry.name = "Jason";
    entry.age = 42;
    entry.constructor === Object // false - constructor is undefined.
`entry` is a valid Human here, but fails your check. Actually, just creating a new class that implements the Human interface will cause a similar problem, since the constructor will be the class instead of Object. You don't even really want to exclude arrays here:

    entry = []
    entry['name'] = "Jason";
    entry['age'] = 42;
Again, entry is a valid Human here.

Re: Tricks I wish I knew when I learned TypeScript

#50

Post by zarzavat »

amitport wrote: post #41
jeswin wrote: post #8

Here's another. Instead of returning Sometype|undefined from a function which may or may not have a value to return (such as searchCustomer), return Sometype|null. That forces the function to return a value that's explicitly intended rather than defaulting from a missed out if-else codepath. This is useful since JS is often imperative style code.

You can declare Sometype|void return type. So the compiler will check that you either don't use the return type or treat it as Sometype. Of course this depends on the logic and for failed routes you should return appropriate results.

void implies that the return type should is undefined behavior and should not be relied upon, so that something like this

    const x = foo();
is incorrect when foo() returns void. 99% of the time x will be undefined (the value) but there are cases where it would not be. For example

    arr.forEach(x => x.sort())
sort returns a value as well as having a side effect. But forEach expects a void callback. This code is perfectly fine in JavaScript because forEach does not read the return value of the callback.
Post reply on HN