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

121–130 of 195 posts

Re: Using TypeScript with React

#121

Post by lhorie »

Merg wrote: post #96
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…

As far as I don't like the "Angry Lisp Drunk Haskell" version of TS e.g. loads of ` ' mixed with functional concepts from half of the Haskell, which makes understanding code harder than necessary. Typescript is one of the rare good things in javascript. You have to understands JS, because there is always gun pointed at your foot, waiting to blow you away. Still TS makes this gun, a little bit harder to trigger. You c…

> your example looks like casting `void *` in C

In practice, that's a pretty good approximation, except that in C, such a cast sticks out like a sore thumb, whereas something like `const o:Foo = getSomeDataSomehow()` looks the same for both a matching concrete type as it does for a cast from `any`.

The thing with type systems like Typescript/Flow is that there are both structural types and nominal types, and _some_ ability to refine nominal types based on their structures, but then people think they can extrapolate that limited capability to ends that the type system doesn't really support.

The return type of JSON.parse can very neatly be expressed with a recursive ADT (e.g. something like `type JSON = string | number | boolean | null | {[key: string]: JSON} | Array`), and TS/Flow do have the ability to refine ADTs, e.g. `if (typeof x === 'string') x.toLowerCase()` is perfectly sound. Why that's not the default is a bit mind boggling IMHO.

What doesn't make sense is to assume one can cast a generic structural type to a random concrete nominal type using the "I know better than the compiler, let me cast" escape hatch mechanism, and then simultaneously omit the runtime refinement checks that they are responsible for writing, when they voided warranty through the cast.

But it's a heck lot harder to explain that they are writing unsound code in this case, because "hey look my type coverage is high, it must be sound!"

TL;DR: TS/Flow aren't silver bullets, but as usual, people tend to cling on to the brand as a social proof of "safety", rather than actually taking the time to understand what actual type safety is all about.

Re: Using TypeScript with React

#122

Post by breatheoften »

collyw wrote: post #46
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…

I am a backed developer 90% of the time, but I currently have to work on a Typescript / React application that an agency did for us - cleaning up the bugs. Is there a good resource to demonstrate how to get around the problems you get with typing? At the moment I am using @ts-ignore to get things done. (Saying "you are probably doing it wrong" isn't really very helpful).

I would highly recommend turning off no implicit any of you haven’t already — implicit any _will_ make it harder for you to figure out how to solve all the typing issues because it will make it significantly harder for you to understand the way type inference works by inspection. — E.g. if you are learning the typescript by looking at example code — a block of code which only types correctly because the compiler implicitly inferred the any type somewhere within can very easily lead you very far astray from understanding how the type system actually works ...

You might have to fix a bunch more errors but at least those are easy to fix (just add any explicitly to the type — or better yet, add the real type if it’s obvious) ...

Re: Using TypeScript with React

#123

Post by Cookingboy »

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 recently started doing a lot of work with React and JS, coming from years of native application development.

It does seem like the general "trend" or "consensus" in the JS community is very inconsistent and easily influenced by a few well-linked blogposts or highly upvoted StackOverflow answers, which themselves are very often written by people with honestly limited software and system engineering experiences. Sometimes a "best practice" in 2017 would be considered awful and "should avoid" in 2018.

Btw Americans opinions do flip-flop on major aspects of policy making, due to all reasons from media coverage to current events. Look at American's support for the Iraq War for example. Herd mentality, leader worshipping, cargo cult, etc are just as prevalent in public policy discussion as it is in software development community.

JS/React, due to having a community that's larger and arguably less experienced than most other community, just show more of the same symptoms.

Re: Using TypeScript with React

#124

Post by bauerd »

cryptica wrote: post #111
bauerd wrote: post #109

Earlier quoted context omitted.

Not blaming myself, just grateful for getting this mess fixed. I cannot imagine working with tech like this on a daily basis, I'd probably ragequit in half a year

Ah yep. I know how it feels to solve some random useless problem that shouldn't even exist in the first place. It still feels great (like solving any other real problem). But it's a psychological trap that makes you feel more invested in the horrible technology which created the problem in the first place. It's like filling out useless bureaucratic government forms. You still get a hit of satisfaction once you finish…

Technological Stockholm syndrome

Re: Using TypeScript with React

#125

Post by SenHeng »

collyw wrote: post #95
ht85 wrote: post #57

Earlier quoted context omitted.

Could you give an example of the kind of problem you're talking about?

I am trying to remember the error that I got. I think it was complaining that the variable being passed to a function may be a null rather than the type that was specified.

Sounds like an optional variable.

    function fn(arg?: SomeObject)
Or worst still, an or undefined, often found in class variables.

    this.foo: Thing | undefined = undefined;
Easy way to sidestep this error is > if (!arg) return;, but it’s really a code smell of a larger, design issue. As in, the function shouldn’t really be depending on an optional value.

Re: Using TypeScript with React

#126

Post by izolate »

I get why TypeScript is quickly becoming the standard, but the problem with it is that it's still JavaScript, and contains all the warts thereof. If at some point your attention turns to the very real benefits of static typing, why not choose an objectively better language?

That's why after ~10 years of being a JS/Node developer, I switched to Dart, not TypeScript.

Re: Using TypeScript with React

#127

Post by lhorie »

status_quo69 wrote: post #88
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…

> 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 .…

The difference between something like Rust->ASM and TS->JS is that the former actually emits runtime machine code to deal with e.g. an Option, whereas in TS, the compiler is happy to emit the exact same runtime code for both `const o: Foo = JSON.parse('null')` and `const o: Foo | null = JSON.parse('null')` without throwing a compile error.

Rust makes it exceptionally "hard" to write unsafe code, by making it blindingly obvious when you're doing it, whereas in TS it can be very challenging to spot unsoundness, especially considering that the audience of the language is not type system scholars.

Re: Using TypeScript with React

#128

Post by marcosdumay »

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?

There is no casting in a sound type system.

No language actually gets there, but there are some where developers mostly don't even remember there is a cast operation.

Re: Using TypeScript with React

#129

Post by qaq »

Cookingboy wrote: post #123
skrebbel wrote: post #117

Earlier quoted context omitted.

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 recently started doing a lot of work with React and JS, coming from years of native application development. It does seem like the general "trend" or "consensus" in the JS community is very inconsistent and easily influenced by a few well-linked blogposts or highly upvoted StackOverflow answers, which themselves are very often written by people with honestly limited software and system engineering experiences. Some…

It's hard to compare to anything else given the size of the community and history.

Re: Using TypeScript with React

#130

Post by tuxracer »

collyw wrote: post #95
ht85 wrote: post #57

Earlier quoted context omitted.

Could you give an example of the kind of problem you're talking about?

I am trying to remember the error that I got. I think it was complaining that the variable being passed to a function may be a null rather than the type that was specified.

Doesn't sound like a problem you get with typing, sounds like it was actually catching what could be a runtime error in production. If the variable is possibly null but the function you're passing it to expects it to not be null then typescript is pointing out what could be a runtime error if you don't explicitly handle that case (if (!foo) ...)
Post reply on HN