Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using TypeScript with React

simonknott.de

Post reply on HN
Print view View original

131–140 of 195 posts

Re: Using TypeScript with React

#131

Post by aphexairlines »

manishsharan wrote: post #28
iraldir wrote: post #8

Earlier quoted context omitted.

Looked at Elm and it looks quite interesting. however concerns for going to it - Skill transfer. If I learn react, I can use my JavaScript skill to understand how everything works under the hood. If I learn Typescript with React, knowing react, I can focus on learning new language feature while not learning at the same time how to build the application. With Elm, I have to learn the language and the framework, all at…

The job market is a chicken and egg type problem. Management would not allow Elm based projects as there are no othe Em programmers on staff. We cant ask for Elm programmig experience in resumes as we dont have any Elm based projects. I wonder how other languages,like Scala, managed to get traction in the enterprise whereas Elm has not even though it can solve real issues that we face with Javascript development.

Scala got traction in places I've worked partly by making the pitch that the team hires people based on software engineering aptitude, not prior knowledge of specific technologies.

A new hire often has to learn a number of new/different technologies. The language is one of the easiest of those.

Re: Using TypeScript with React

#132

Post by WorldMaker »

wereHamster wrote: post #89
bauerd wrote: post #86

Earlier quoted context omitted.

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…

I find after a fresh `npm install` (as opposed to `npm ci` which pays attention to package-lock.json) an `npm dedupe` almost always seems necessary. `npm install` by default still doesn't seem to work hard enough to avoid duplication, especially with @types/ packages where is often critical.

Re: Using TypeScript with React

#133

Post by lhorie »

ng12 wrote: post #114
lhorie wrote: post #85

Earlier quoted context omitted.

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…

This is the equivalent of casting in Java. Is Java's type system unsound?

You can't cast from a HashMap to an Animal class in Java, so in that sense Java is sounder. But you can still do `Animal a = null; a.walk();`, so in that sense, Java isn't sound.

Re: Using TypeScript with React

#134

Post by zackify »

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…

this is why I wish typescript added runtime checks in development. Worst case, it would throw a TS error in your browser any time a function call or a network request didn’t match what you typed

Re: Using TypeScript with React

#135

Post by marcosdumay »

davidjnelson wrote: post #106
cryptica wrote: post #102

Earlier quoted context omitted.

>> javascript codebases become read only :-D This is BS. I've built very large JS projects with hundreds of thousands of lines and never had this problem. If your architecture is well designed and modular then refactorings are easy and localized to just a small number of files. On the other hand, TypeScript encourages spaghetti code which makes refactorings span more files; complex active instances end up getting pas…

Glad you enjoy large javascript projects and it works well for you. Architecture is important regardless of what language you are using.

Yes, architecture is important, but you can't architecture away neither errors nor domain complexity.

Besides, your language is the largest constrain you'll have on your program architecture.

Re: Using TypeScript with React

#136

Post by jimmyspice »

wereHamster wrote: post #89
bauerd wrote: post #86

Earlier quoted context omitted.

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…

@types versioning is strange because you never know whether or not the version of the types matches the dependency exactly. for example the case where the typed version has a minor upgrade (say due to increased type coverage), the types become out of sync.

the fix is to do away with @types and export types from the dependency itself so they are always in sync

Re: Using TypeScript with React

#137

Post by lhorie »

skrebbel wrote: post #117
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…

I'm always confused when someone calls out a large group of people for not having a consistent opinion. Gotta love Americans! They flip-flop on major aspects of policy making. One day they spout "ban guns!", the next they say "If need be I'll defend my right to bear arms with violence!"

I don't think GP is criticizing the flip-flopping, but rather the "arrogantly spouting" part.

Re: Using TypeScript with React

#138

Post by jimmyspice »

cryptica wrote: post #100
sli wrote: post #92

Earlier quoted context omitted.

I do find it rather strange that strongly typed code with no errors, that builds correctly, can fail at runtime due to type errors. My JS oftentimes ends up nicer than my TS because I don't have pages of, basically, type-level administrative work. I don't have this experience at all in other strongly typed languages, including very strong ones like Haskell/PureScript. The types there just work for me.

This can happen if handling data from a remote client. Type checking does not happen at runtime so you still need to do your own schema validation even with TypeScript. So IMO it adds almost no value.

in which case your API layer should validate the data at runtime so that it only actually returns type T as it claims. then you are back to soundness

Re: Using TypeScript with React

#139

Post by hazza1 »

zackify wrote: post #134
lhorie wrote: post #85

Earlier quoted context omitted.

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…

this is why I wish typescript added runtime checks in development. Worst case, it would throw a TS error in your browser any time a function call or a network request didn’t match what you typed

you don't really want the overhead of checking types on every call, you know where your applications entry points are - if you need checks add them.

Re: Using TypeScript with React

#140

Post by aficiomaquinas »

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…

> Gotta love JS community. It flip-flops on some major aspect of system design roughly every year, yet people continue to arrogantly spout their opinions about system design as if they had been correct about everything all along. Not "these are the benefits, these are downsides" not "I've improved in X by using Y", always "nobody needs X, everyone must do Y, and if you're not doing Z you're wrong and unprofessional". Zero self-awareness.

Gotta love HN community. It flip-flops on other's people opinions every day, yet people continue to arrogantly spout their opinions about those opinions as if they had been correct about them all along. Not "these are the benefits, these are downsides" not "I've improved in X by using Y", always "nobody needs X, everyone must do Y, and if you're not doing Z you're wrong and unprofessional". Zero self-awareness.

Post reply on HN