Live data from Hacker News

Tricks I wish I knew when I learned TypeScript

cstrnt.dev

11–20 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#11
post #7

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.

Probably best to just lift one off of a major library like Lodash, they're well tested and efficient (no need to actually use the library, do include the LICENSE somewhere though):

https://github.com/lodash/lodash/blob/master/isObject.js

But depends on your needs, and you can also attach a typeguard to it.

Re: Tricks I wish I knew when I learned TypeScript

#12
post #7

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.

If you want to avoid a library then you can do `typeof x === "object" && !Array.isArray(x) && x !== null`. Not ideal, but you can of course turn it into a utility function.

Re: Tricks I wish I knew when I learned TypeScript

#13

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.

Which is exactly what was used in the code exemplifying something else in the second example - so that confused me (never having written any TS) too.

Re: Tricks I wish I knew when I learned TypeScript

#14

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.

How about

any => Object.prototype.toString.call(any).slice(8, -1)

Re: Tricks I wish I knew when I learned TypeScript

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

+1, and this practice can be verified by TS with the `noImplicitReturns` setting (https://www.typescriptlang.org/tsconfig#noImplicitReturns)

Re: Tricks I wish I knew when I learned TypeScript

#17

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.

How about any => Object.prototype.toString.call(any).slice(8, -1)

bit more self-explanatory `it => Object.prototype.toString.call(it).match(/^\[object (\w+)]/).pop()`

Re: Tricks I wish I knew when I learned TypeScript

#18

I actually don't really like Record types in the way people/library maintainers often use them - the type-checker asserts that values are actually present for all the specified keys, which is fine if the objects with the Record type really were exhaustive; but instead I often see them used where the reality of the data is a Partial - some keys are missing. Something about the abstraction causes people to misuse it fr…

Yep, and in your own code you can tell TS to verify your property access with the setting `noPropertyAccessFromIndexSignature` (https://devblogs.microsoft.com/typescript/announcing-typescr...)

The TS crew did discuss having a "pedantic" mode, which is stricter than "strict", but I don't think it's on the roadmap any more.

Re: Tricks I wish I knew when I learned TypeScript

#19
post #7

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.

I very, very much disagree with the type of suggestions here. Probably because I don't know TS but here it comes anyways...

You don't need a library or check that it isn't an array or anything like that. What you actually want to check is what it _is_.

You absolutely don't care whether that object is an array or a function or what have you. What you care about in that piece of code is that it satisfies what you want to do with it.

In the context of the article you can do an ad-hoc check on the fields that you require in that context.

Aside:

There are places where you want to have a kind of rigidity around the shape of your objects, including homogeneous collections. The JIT might reward you with optimizations in certain cases. But that is optimization, so you are supposed to measure first and only then apply them or have a very clear picture of how your runtime behavior will be.

Re: Tricks I wish I knew when I learned TypeScript

#20
post #16
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.

+1, and this practice can be verified by TS with the `noImplicitReturns` setting ( https://www.typescriptlang.org/tsconfig#noImplicitReturns )

Yeah, that rule is super powerful!
Post reply on HN