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

241–250 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#241

Post by kilburn »

Androider wrote: post #237
kilburn wrote: post #233

Earlier quoted context omitted.

The advantage here is that you are not repeating the type of the property twice (once as optional in the base type, once as mandatory in the extended class). Even though the code may seem inscrutable, note that the resulting type is fairly easy to understand in your IDE. That is, if you hover over the "B" to see what the type definition is, you see: type B = A & { foo: number; baz: number; } If you defined the type l…

The beginner programmer copies the property definition. The advanced programmer simply writes "type Ensure = T & { [U in keyof Pick ]-?: T[U] };", thus removing the need to copy the property. The master programmer copies the property definition.

Do you have some argument? Without arguments, your comment has as much substance as me replying:

The beginner programmer copy/pastes the code.

The advanced programmer writes a function, thus removing the need to maintain copies of the code.

The master programmer copy/pastes the code.

It is not like "Ensure" would be a single-use thing. "Ensure" here is a utility type definition, which is what a "function in the world of types" would be.

Re: Tricks I wish I knew when I learned TypeScript

#243

Post by krona »

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 use of null in place of undefined is not composable with optional parameter behaviour, among other things.

Re: Tricks I wish I knew when I learned TypeScript

#244

Post by recursive »

spoiler wrote: post #210
recursive wrote: post #186

Earlier quoted context omitted.

I totally agree about ligatures. My user style sheet works pretty flawlessly for everything. * { font-variant-ligatures: none !important; } I cannot comprehend how ligatures ever got popular in programming, particularly in blogs supposedly trying to teach new languages or concepts.

For me personally, I found that they help reduce the noise in the code. I also noticed that it makes it a bit easier to "read" the code (not just visually, but "semantically" if that makes sense). As in, I think I have to spend less time "parsing" ≤ than = However, I am mildly dyslexic, so that might play a role in it.

That's all well and good for your personal environment. But I think it's a little crazy for a blog post that's supposed to be teaching things to beginners. "≤" is actually a different string than "<=". I think it's really misleading to render one series of characters as if it were another. For instance, julia actually supports ≤. There are others. On top of that, I don't expect a font to be able to correctly parse code. Sometimes "<=" happens in contexts other than "less than or equal".

Re: Tricks I wish I knew when I learned TypeScript

#245

Post by xsmasher »

irrational wrote: post #127

Does Typescript get better? I've been forced to use it for my most recent project, but haven't been given any time to read through the documentation. I've found that I'm spending about 99.9999% of my development time trying to figure out how to get my IDE to not show that their are typescript problem. At this point I hate typescript with the burning fury of a trillion suns. I wonder if this is everyone else's experie…

Once your environment is configured and you're writing good types, the only errors you see are when you do something that violated your type rules - like calling myRecord.names gives you an error "Property 'names' does not exist on type 'PlayerRecord'. Did you mean 'name?'"

I don't know if the issues you're having is bad setup, or type system abuse. Try a typescript forum or chat group?

I'll admit that, coming from C++, I'm 100% bought in on the usefulness of type systems; but I can't imagine refactoring or making major changes in a project written in untyped JS.

Re: Tricks I wish I knew when I learned TypeScript

#246

Post by pavel_lishin »

jakelazaroff wrote: post #154
pavel_lishin wrote: post #153

Earlier quoted context omitted.

> In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the implementation to make it easier to modify later. In practice, that someone then leaves the company, leaving this nightmare underfoot. > The TS compiler is surprisingly good at giving you good readable error messages as well when your code violates these advanced types Only if you're that…

Isn't this true for any abstraction, though? If the person who wrote it is inaccessible, you have to understand it by reading the source.

Sure. But this is easier to understand, albeit means repeating code:

    class B {
        foo: number;
        bar?: number;
        baz: number;
    }
I know these are toy examples, and I'm sure there are reasons why in the real world you'll be modeling things where this is not a good option. But I'd really need to be convinced that the CRUD webapps a lot of us write actually benefit from having this in our source code.

Re: Tricks I wish I knew when I learned TypeScript

#247

Post by flippinburgers »

skywal_l wrote: post #58
mithusingh32 wrote: post #56

Earlier quoted context omitted.

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.

Typescript is actually a great language. And with those utility types, you can do pretty fun stuff like, for example, you want to mutate a type so that some fields become mandatory: type Ensure = T & { [U in keyof Pick ]-?: T[U] }; class A { foo?: number; bar?: number; baz?: number; } type MandatoryFields = "foo" | "baz"; type B = Ensure ; const b: B = { foo: 42 }; Here, ts will complain that b is missing baz.

Just have a concrete type (class/interface) that specifies required fields.

This is overkill that will only confuse everyone who isn't the original author.

Re: Tricks I wish I knew when I learned TypeScript

#248

Post by Shorn »

toxik wrote: post #180
underdeserver wrote: post #162

Earlier quoted context omitted.

I know dozens of people who tried understanding Promises and all of them succeeded. I know dozens of people who tried to understand monads (including myself) and maybe 3 of them succeeded (I do not consider myself one of them).

A monad is just a monoid in the category of endofunctors, what's the problem?

HN may not be the place for these kind of comments - but I will never not up-vote this specific comment.

Re: Tricks I wish I knew when I learned TypeScript

#249

Post by throwaway675309 »

marton78 wrote: post #63

Kinda off topic from someone whos mother tongue is not English: what happened in the past years that people apparently forgot how the irrealis works in English? Shouldn't this be "Things I wish I had known when I learned TS" as opposed to "Things I wish I knew RIGHT NOW"?

Even as a former ESL instructor, I'm rather disdainful of statements such as these, as if language is some "well defined codified construct" as opposed to being a fluid means of communication that continually evolves to meet cultural needs.

It's like the word peruse, it traditionally meant "to look over something in great detail", yet you'll find the majority of people use it to mean "to look over some thing in a cursory fashion." So for all intents and purposes, that is the new de facto definition of the word.

Post reply on HN