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

91–100 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#91

Post by Vinnl »

hamstercat wrote: post #68
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.

The difference between null and undefined in JavaScript is something I wished had never been implemented. Other languages refer to null as their billion dollar mistake, but somehow JavaScript got 2 of them with slightly different but sometime identical behaviour. I would defer to eslint to prevent this particular issue if you care about it, this allows you to set rules in your own code without any impact to the outsi…

When people refer to the "billion dollar mistake", they mean the language feature that every value could potentially be `null`, i.e. even if a function returns MyType, it could also return `null`.

TypeScript in strict mode (the default) still has `null` and `undefined`, but not the billion dollar mistake: if you want to be able to pass `null` to a function, you have to mark that parameter as being potentially `null`.

Re: Tricks I wish I knew when I learned TypeScript

#92

Post by [deleted] »

phailhaus wrote: post #70
_fat_santa wrote: post #57

Earlier quoted context omitted.

I found that pattern useful when you don't know what the key will be. I have an iOS app that tracks tips, when you add a tip, it's stored in an object like this: type Tips = { [tipGuid: string]: TipObject } which can be rewritten using Record as type Tips = Record That pattern ins't very useful when creating object with known keys but for data structures where the key is either not known or generated it a godsend.

`Record` is a dangerous type, and I would recommend against it. The problem is that it assumes any key is valid and will return a value type. Example: type Tips = Record const tips: Tips = {} tips["hello"] // TipObject, but you actually get undefined It's better to define a Dictionary type like so: type Dictionary = Partial > Then to use: type Tips = Dictionary const tips: Tips = {} tips["hello"] // TipObject | undef…

[deleted]

Re: Tricks I wish I knew when I learned TypeScript

#93

Post by hardwaresofton »

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.

Array.isArray[0] is your friend

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

Re: Tricks I wish I knew when I learned TypeScript

#95

Post by xixixao »

hamstercat wrote: post #68
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.

The difference between null and undefined in JavaScript is something I wished had never been implemented. Other languages refer to null as their billion dollar mistake, but somehow JavaScript got 2 of them with slightly different but sometime identical behaviour. I would defer to eslint to prevent this particular issue if you care about it, this allows you to set rules in your own code without any impact to the outsi…

Both Flow and CoffeeScript got this right, while TS is slowly dragging its feet towards the right solution: Pretend there’s no difference between them. Your code will be easier to reason about. If you need two different “other values”, use a proper enum / type union / restructure your API.

Re: Tricks I wish I knew when I learned TypeScript

#96

Post by nathias »

handrous wrote: post #71
nathias wrote: post #65

Everything that TS does JS libraries do better without the horrible tradeoffs ... sadly MS has invested so much into promoting it that it's now almost a requirement for all software development.

> Everything that TS does JS libraries do better Which ones do you need to do everything TS does? > without the horrible tradeoffs Which tradeoffs are horrible?

For example if you want prop types you use propTypes. In React TS replaces good error handling for horrible obscure errors and slows down development considerably etc. etc.

Re: Tricks I wish I knew when I learned TypeScript

#97

Post by bmn__ »

spicybright wrote: post #94

I'm going to be one of those people, but multiple "=" rendering as a large double line is really ugly.

You don't have to suffer (subjectively) bad typography. Cascading style sheets were designed with the ability to override author styles with user styles, your Web browser has settings for this.

Re: Tricks I wish I knew when I learned TypeScript

#98

Post by shadowgovt »

mithusingh32 wrote: post #56
skywal_l wrote: post #43

Utility Types[0] will help you get to the next level on Typescript. It's important to know them and know how and when to use them. [0] https://www.typescriptlang.org/docs/handbook/utility-types.h...

Wow, thanks for this. I wasn't even aware of these. I'm surprised I rarely see these in courses/tutorial. These should be like day 1 material.

TS has been around long enough that it suffers from the 'obsolete tutorial' problem (one I first observed learning C++): many of the utility types didn't exist when many of the popular tutorials were first written.

Re: Tricks I wish I knew when I learned TypeScript

#99

Post by goto11 »

hamstercat wrote: post #68
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.

The difference between null and undefined in JavaScript is something I wished had never been implemented. Other languages refer to null as their billion dollar mistake, but somehow JavaScript got 2 of them with slightly different but sometime identical behaviour. I would defer to eslint to prevent this particular issue if you care about it, this allows you to set rules in your own code without any impact to the outsi…

> Other languages refer to null as their billion dollar mistake

The "billon dollar mistake" as described by Tony Hoare was not nulls per se.

The billion dollar mistake was having a type system where null was a member of every reference type. This does not apply to language like JavaScript without static type checking, and it doesn't apply to type systems like TypeScript where null or undefined have to be explicitly specified as members of a type.

The undefined/null distinction solves an additional problem: In Java you don't know if a value is null because a field wasn't initialized correctly or because it was deliberately set to null. JavaScript allows you to distinguish between these two scenarios.

Re: Tricks I wish I knew when I learned TypeScript

#100

Post by mikeryan »

bobbylarrybobby wrote: post #80
hamstercat wrote: post #68

Earlier quoted context omitted.

The difference between null and undefined in JavaScript is something I wished had never been implemented. Other languages refer to null as their billion dollar mistake, but somehow JavaScript got 2 of them with slightly different but sometime identical behaviour. I would defer to eslint to prevent this particular issue if you care about it, this allows you to set rules in your own code without any impact to the outsi…

I've always liked the two-nulls solution in JS. `undefined` is a runtime-generated missing value, whereas `null` is a compile-time author-supplied missing value. In other words `undefined` is a "pulled" missing value, `null` a "pushed" missing value. Any feature can be misused, but having the distinction is certainly helpful.

I agree. I can understand the parent but I like these distinctions and Typescript makes them easier to deal with for me
Post reply on HN