Using TypeScript with React • Hacker News Board

Re: Using TypeScript with React

#81

Post by wereHamster » Thu, Aug 22, 2019, 2:55 PM UTC

bauerd wrote: post #36

I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anym…

That error you're seeing could be because you have multiple @types/react packages in your dependencies. You really should have just one version of each @types/* package installed. If you use yarn you can use `yarn why @types/react` to find out if you have multiple versions installed. To resolve these kids of errors, I usually uninstall all @types/* packages and then install them all at once again. Alternative is to use yarn resolutions (https://yarnpkg.com/lang/en/docs/selective-version-resolutio...) to force a specific version of those dependencies.

Re: Using TypeScript with React

#82

Post by verttii » Thu, Aug 22, 2019, 2:56 PM UTC

eropple wrote: post #73

verttii wrote: post #68

Earlier quoted context omitted.

I guess it depends on what you compare with. If you're coming from Java or the like, surely TS does not feel particularly verbose. However, coming from a truly terse language like Haskell you'll just feel TS is too verbose and not very elegant. TS is the most verbose and least elegant of the languages I'm personally using, on par with Dart. ADTs not only feel dirty because they're not first class citizens (you build…

I'm sure that, if you're carrying a torch for Haskell, TypeScript can feel very primitive--though I don't enjoy writing Haskell, in my experience it turns into an exercise in navel-gazing and write-only code compared to TypeScript or F#--but on the other hand normal people can write it and be productive and that's kind of important, yeah? I think the TS folks did a great job in making something that I can bring into…

Hehe yes the Haskell community certainly suffers from the dynamics you just described.

I guess my problem with TS ADTs is just that they're done with the TS primitives whereas they could be true first class citizens. But such a feature may be too hard to swallow for your typical JS developer whose first introduction to types is Typescript.

Btw can you elaborate on that Enum with ADTs? Or did you mean that you use Enums with switch-case? I use it too and find it one of the best bits of TS.

Re: Using TypeScript with React

#83

Post by eropple » Thu, Aug 22, 2019, 3:06 PM UTC

verttii wrote: post #82

eropple wrote: post #73

Earlier quoted context omitted.

I'm sure that, if you're carrying a torch for Haskell, TypeScript can feel very primitive--though I don't enjoy writing Haskell, in my experience it turns into an exercise in navel-gazing and write-only code compared to TypeScript or F#--but on the other hand normal people can write it and be productive and that's kind of important, yeah? I think the TS folks did a great job in making something that I can bring into…

Hehe yes the Haskell community certainly suffers from the dynamics you just described. I guess my problem with TS ADTs is just that they're done with the TS primitives whereas they could be true first class citizens. But such a feature may be too hard to swallow for your typical JS developer whose first introduction to types is Typescript. Btw can you elaborate on that Enum with ADTs? Or did you mean that you use Enu…

I do mean enums/switch, yeah. Makes it easy to have your code yell at you when all cases aren't dealt with.

The thing about making ADTs first-class citizens means that TypeScript stops being JavaScript, and one of the most valuable parts of TypeScript to me is that I can just look at it and know what the underlying JavaScript is. I kind of equate it to writing C on an old platform--it's going to be munged significantly but at a glance you can have a high degree of confidence that the code coming out the other end is going to be what you expect it to be.

Re: Using TypeScript with React

#84

Post by s_y_n_t_a_x » Thu, Aug 22, 2019, 3:07 PM UTC

gambler wrote: post #77

jillesvangurp wrote: post #35

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…

>If it's tedious, you're probably doing something wrong or sub-optimal. >IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arr…

OR JS developers are talking to their community and not you. The only language we can really use has evolved over the years to meet the problems that have cropped up. In the past a scripting language was enough to complement the HTML document it was served with. Now that web apps are expected, we need a real programming language and strategies.

They aren't the ones with zero self-awareness.

Re: Using TypeScript with React

#85

Post by lhorie » Thu, Aug 22, 2019, 3:08 PM UTC

gambler wrote: post #77

jillesvangurp wrote: post #35

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…

>If it's tedious, you're probably doing something wrong or sub-optimal. >IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arr…

The problem IMHO is the old adage of the devil being in the details. I see a lot of engineers talking about things like deriving types from enums, and meanwhile the type system will merrily let you do this:

    type Foo = {a: number}
    const o: Foo = JSON.parse('null')
    o.a = 1

It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilities, but they just shrug when I point out that the foundation of the scheme is still unsound.

Re: Using TypeScript with React

#86

Post by bauerd » Thu, Aug 22, 2019, 3:15 PM UTC

wereHamster wrote: post #81

bauerd wrote: post #36

I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anym…

That error you're seeing could be because you have multiple @types/react packages in your dependencies. You really should have just one version of each @types/* package installed. If you use yarn you can use `yarn why @types/react` to find out if you have multiple versions installed. To resolve these kids of errors, I usually uninstall all @types/* packages and then install them all at once again. Alternative is to u…

You were right, @types/react was resolved to both versions 15 and 16! God I'd totally buy you a beer.

But why does this happen? The very first time for me a package manage installs two major versions for a package …

Thanks A TON!

Re: Using TypeScript with React

#87

Post by sbergot » Thu, Aug 22, 2019, 3:18 PM UTC

gambler wrote: post #77

jillesvangurp wrote: post #35

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…

>If it's tedious, you're probably doing something wrong or sub-optimal. >IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arr…

Or maybe there are multiple voices with various opinions. What has remained constant for a few years is the volume of condescending comments that any discussion about js gets on the sole basis that people are discussing js.

Re: Using TypeScript with React

#88

Post by status_quo69 » Thu, Aug 22, 2019, 3:25 PM UTC

lhorie wrote: post #85

gambler wrote: post #77

Earlier quoted context omitted.

>If it's tedious, you're probably doing something wrong or sub-optimal. >IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arr…

The problem IMHO is the old adage of the devil being in the details. I see a lot of engineers talking about things like deriving types from enums, and meanwhile the type system will merrily let you do this: type Foo = {a: number} const o: Foo = JSON.parse('null') o.a = 1 It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilitie…

> It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilities, but they just shrug when I point out that the foundation of the scheme is still unsound.

I don't agree with this premise. Assembly is an untyped language but you can build things on top of it like Rust or Haskell, or you can write in C and cast everything to a void. I do* agree that validating the types of values is a hard problem in any language and that JSON.parse should be typed as `unknown` these days (although there are also reasons why it should not do that due to casting), but it makes complete sense IMO. JSON.parse could return any valid JSON value. The compiler doesn't know the structure of the string provided beforehand.

Re: Using TypeScript with React

#89

Post by wereHamster » Thu, Aug 22, 2019, 3:32 PM UTC

bauerd wrote: post #86

wereHamster wrote: post #81

Earlier quoted context omitted.

That error you're seeing could be because you have multiple @types/react packages in your dependencies. You really should have just one version of each @types/* package installed. If you use yarn you can use `yarn why @types/react` to find out if you have multiple versions installed. To resolve these kids of errors, I usually uninstall all @types/* packages and then install them all at once again. Alternative is to u…

You were right, @types/react was resolved to both versions 15 and 16! God I'd totally buy you a beer. But why does this happen? The very first time for me a package manage installs two major versions for a package … Thanks A TON!

To me it usually happens if I upgrade one of the @types/* packages, and then yarn/npm decides to install a separate version of its dependencies, even if I already have a different (compatible) version. There is no easy way AFAICS to tell yarn/npm that you really only want a single version of each @types/* package.

Same applies to most regular npm packages as well, for example you really only want a single version of "react", too.

Re: Using TypeScript with React

#90

Post by sli » Thu, Aug 22, 2019, 3:36 PM UTC

lhorie wrote: post #85

gambler wrote: post #77

Earlier quoted context omitted.

>If it's tedious, you're probably doing something wrong or sub-optimal. >IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arr…

The problem IMHO is the old adage of the devil being in the details. I see a lot of engineers talking about things like deriving types from enums, and meanwhile the type system will merrily let you do this: type Foo = {a: number} const o: Foo = JSON.parse('null') o.a = 1 It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilitie…

I've run into issues with TypeScript that forced me to cast string literal types to themselves before it would compile. So literally this code:

    'x' as 'x'

Nothing else would work, we were simply forced to do that. Avoiding `any` in all cases is simply not possible, as Redux will require you to use it at least once as of the last time I used TypeScript, which wasn't that long ago. Type discoverability for libraries was such a massive hassle that I don't see how other TS devs have gotten around it. Not everyone can use Visual Studio.

I don't find TypeScript's type system to be anywhere close to sound. Instead, it feels like it lies to me a lot. At least it has HKTs now, so that's nice. But I ended up moving to ClojureScript (and a little PureScript) and I've never looked back.