TypeScript Features to Avoid • Hacker News Board

Re: TypeScript Features to Avoid

#91

Post by Zababa » Thu, Jan 20, 2022, 2:55 PM UTC

donatj wrote: post #63

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript . There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript. If you ju…

> It’s a full fledged language that compiles to readable JS

Compiling to readable JS is not one of TS's goals. For example:

https://www.typescriptlang.org/play?noImplicitAny=false&targ...

Re: TypeScript Features to Avoid

#92

Post by donatj » Thu, Jan 20, 2022, 2:58 PM UTC

Zababa wrote: post #91

donatj wrote: post #63

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript . There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript. If you ju…

> It’s a full fledged language that compiles to readable JS Compiling to readable JS is not one of TS's goals. For example: https://www.typescriptlang.org/play?noImplicitAny=false&targ...

That seems very readable, especially in comparison to something like Dart or Elm’s output, both of which can output thousands of lines from something as simple as your example.

From the language goals

> 4. Emit clean, idiomatic, recognizable JavaScript code.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Re: TypeScript Features to Avoid

#93

Post by breatheoften » Thu, Jan 20, 2022, 3:00 PM UTC

gmiller123456 wrote: post #88

breatheoften wrote: post #84

Is anyone still using the class keyword in javascript or typescript? private field syntax doesn't matter in the first place if you don't use class {} anywhere ... I feel like most of the typescript code i've been in recently looked like it needed 0 more class declarations.

I use "class" all the time in Javascript (don't use Typescript at all), why wouldn't you?

I think the oo features tend to not play as well with many styles of functional programming -- at least the forms of it that work well in typescript ... in typescript I tend to represent data as structurally typed "plain old javascript" objects and my program becomes largely just functions that operate on values and return new values. The idiomatic ways available in the language to copy and produce new values from old values tend to be straightforward and without as many gotchas when the values themselves carry all their meaning without the prototype chain. Once the prototype chain is a important factor in the program behavior you tend to have to keep track of "how exactly was a value with this shape acquired" -- i can't as easily just roundtrip it through some json for example -- and copying a value tends to not be as composable an operation with a tree of objects where the reachable sub objects all have behavior based on prototype chain.

When the prototype chain is involved I think the value gained from structural typing tends to decrease -- or at least exposes the programmer to more sharp edges.

Re: TypeScript Features to Avoid

#94

Post by afavour » Thu, Jan 20, 2022, 3:01 PM UTC

brightstep wrote: post #50

activitypea wrote: post #43

Earlier quoted context omitted.

What are the advantages of enums over a string literal union? I can only see disadvantages.

In some cases you can use it to define string arguments to an external library. Maybe table names to an ORM or a well-known file path. This helps because you get autocomplete from typing `MyEnum.` and seeing options, even though the external function takes a plain string.

All of that is possible with a string literal union though, surely?

Re: TypeScript Features to Avoid

#95

Post by donatj » Thu, Jan 20, 2022, 3:06 PM UTC

Vinnl wrote: post #78

donatj wrote: post #63

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript . There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript. If you ju…

> imho represent a misunderstanding of what Typescript is going for. It's pretty what TypeScript's going for though: > Avoid adding expression-level syntax. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I’m curious what they mean by “expression-level syntax” specifically, because they certainly added a lot of syntax that isn’t ECMA and aren’t just Babel, backporting future ECMA features.

Re: TypeScript Features to Avoid

#96

Post by lucasyvas » Thu, Jan 20, 2022, 3:08 PM UTC

cobertos wrote: post #64

kesslern wrote: post #61

Earlier quoted context omitted.

One advantage of enums is that you can iterate over all possible values of an enum, but not a union type.

You can if you derive the union from a const array using indexed types. const MyTypeValues = ['a', 'b'] as const; type MyType = typeof MyTypeValues[number]; MyType is now a type 'a' | 'b'

This is the way, because iterating enums produces odd results due to a bidirectional mapping.

I had always used enums in TS until this year, but union literals are better.

I create my own enums with const objects, compute the type based off the object's values. So very similar this, just with an object as the source instead of an array.

Re: TypeScript Features to Avoid

#97

Post by tentacleuno » Thu, Jan 20, 2022, 3:10 PM UTC

moystard wrote: post #15

throw_m239339 wrote: post #9

Earlier quoted context omitted.

I think class were needed because too many developers were creating their own (incompatible) class systems on top of prototypal inheritance (which is more verbose). The problem with Typescript is that too many Typescript developers don't understand Javascript itself, which is an completely different issue. That and the obsession for some to reproduce JEE everywhere including in the browser...

What do you mean by reproducing JEE? Leveraging OOP in your Javascript programs? I really dislike this tendency of certain Javascript developers to qualify combining OOP with Javascript as "not understanding the language".

In my humble opinion, they're both fine. Use functions where you need to, and do the same with classes. They're both citizens of the language, so why not utilize them?

Re: TypeScript Features to Avoid

#98

Post by moystard » Thu, Jan 20, 2022, 3:26 PM UTC

tentacleuno wrote: post #97

moystard wrote: post #15

Earlier quoted context omitted.

What do you mean by reproducing JEE? Leveraging OOP in your Javascript programs? I really dislike this tendency of certain Javascript developers to qualify combining OOP with Javascript as "not understanding the language".

In my humble opinion, they're both fine. Use functions where you need to, and do the same with classes. They're both citizens of the language, so why not utilize them?

I agree with you. They both serve a purpose and should be used when they make the most sense.

Re: TypeScript Features to Avoid

#99

Post by joshstrange » Thu, Jan 20, 2022, 3:26 PM UTC

After trying enums in TS a long time back I also realized it was best to avoid them. Here is my solution to this:

    // filename: role.ts
    export const Role = {
        CUSTOMER: 'customer',
        ADMIN: 'admin',
        SYSTEM: 'system',
        STAFF: 'staff',
    } as const;
    type TRole = keyof typeof Role;
    export type TUserRole = typeof Role[TRole];

Using this structure I can reference any of my roles by `Role.CUSTOMER` and the value is `customer` because it's just a `Record` at the end of the day. But I am able to type things by using my `TUserRole` so a function can required that the input be one of the values above. For me this is really clean and easy to use. Note the `type TRole` isn't exported as it's only an intermediary in this process, I could just as well name it `type temp` in all my files and never worry about conflicts.

This way I'm not spreading "special" strings all over my code (always a sign of code smell for me), I can changed everything at a central location, and it's valid JS (it's just an object).

EDIT: I know that `as const` seems unnecessary but I'm pretty sure it's needed for some reason, I whittled this down to the smallest/simplest code block I could and I just copy/paste this pattern whenever I need enum-like functionality.

Re: TypeScript Features to Avoid

#100

Post by joshstrange » Thu, Jan 20, 2022, 3:32 PM UTC

conaclos wrote: post #17

Replacing TS enum with JS objects is really tedious: type HttpMethod = keyof typeof HttpMethod const HttpMethod = { GET: "GET", POST: "POST", } as const It is even worse with int enum: type HttpMethod = Extract const HttpMethod = { GET: 0, POST: 1, 0: "GET", 1: "POST", } as const My personal "avoid"-rules are: - Avoid enum with negative integers because it generates code that cannot be optimized by the JS engine - Pr…

I've been using the method I outlined here [0] and it's not tedious to work with at all. That said you might have a different usecase where my example doesn't work.

[0] https://news.ycombinator.com/item?id=30010017