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

161–170 of 195 posts

Re: Using TypeScript with React

#161

Post by azangru »

neurotrace wrote: post #149
azangru wrote: post #108

Earlier quoted context omitted.

This sounds very arbitrary, opinionated, and unconvincing. If a class is a co-location of data and methods performed on it, then how is this class: class Foo { constructor(value) { this.value = value; } addOne() { this.value++; } getValue() { return this.value; } } const foo = new Foo(1); any worse than this POJO: const foo = { value: 1, addOne() { this.value++; }, getValue() { return this.value; } } Besides, what ar…

I think you missed the part where they said you don't need classes for POJOs and models i.e. things which only contain data and do nothing else. If you want methods that operate against the inner data of an object then totally write classes

It’s just that they started their post by saying that classes in Typescript should be avoided. A message "x should be avoided" is very different from "you don’t need x". Compare the statement "you don’t need redux", which has been incorporated into titles of numerous blog posts, with the statement "redux should be avoided".

Re: Using TypeScript with React

#162

Post by halleonard »

arcticfox wrote: post #142
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…

(1) OP said "we're reaching the point" which is clearly a nod to the maturing TypeScript ecosystem, which is why they changed their opinion over time. I've also changed mine for the same reason. (2) Sometimes there are such massive benefits that downsides are almost irrelevant. TS has instantly saved me from hundreds of bugs, some of them nasty, and only caused me grief a few times. There are few downsides. I agree w…

> TS has instantly saved me from hundreds of bugs

And who ever thought refactoring JS could be so easy!

Re: Using TypeScript with React

#163

Post by breatheoften »

breatheoften wrote: post #122
collyw wrote: post #46

Earlier quoted context omitted.

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

Edit: I meant to say ... turning on no implicit any (prevent the inference engine from inferring the any type)

Re: Using TypeScript with React

#164

Post by snek »

jinushaun wrote: post #31

Disappointed that the article alluded to but never explains why classes should be avoided in Typescript. (Which I agree, btw) If you’re used to classes, it’s really tempting to create classes for your models. But in Typescript, which gets compiled down to plain old JavaScript, you spend a lot of your time dealing with JSON and plain old JavaScript objects (POJO). These don’t have methods. These don’t have private mem…

"Classes considered harmful"

Re: Using TypeScript with React

#165

Post by deviantfero »

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…

How do you suggest someone should proceed if an essential library in their project has no typing for typescript?

Re: Using TypeScript with React

#166

Post by status_quo69 »

lhorie wrote: post #127
status_quo69 wrote: post #88

Earlier quoted context omitted.

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

I won't argue that getting strong code in TS is easy but I definitely don't think it's as hard as you're making it out to be. That being said, it's more of a limitation of the underlying execution context in my opinion, and you have to realize that it's not just jS that's out to get you but the whole ecosystem. But that's the expectation in all languages, even in Rust. In production optimizations all bets are off and you're on your own if your app dies.

For example of what I mean by the platform being out to get you, the second parameter to JSON.parse is a recovery function. So it'll happily parse anything and return anything. Again, should be "unknown" but it was typed before unknown was a thing.

    JSON.parse('{ "fooDate": 123456789 }', (key, value) => !key.includes('Date') ? value : new Date(value));

    JSON.parse('123456789', (key, value) => new Date(value))
I actually just learned about this today, since I was doing some digging. Horrifying stuff for a typed language to get around. FWIW, we've made it an explicit lint error to use the `any` type, and enabled --noImplicitAny and --noImplicitReturns. That's been pretty solid for our codebase and because I/O is limited to a few edges, we can call out those edges for type guards.

Re: Using TypeScript with React

#167

Post by jakear »

cultofmetatron wrote: post #155
jakear wrote: post #110

Earlier quoted context omitted.

TypeScript + GraphQL works really well for typing API responses (assuming you’re in control of the API, of course) Disclaimer, I work for ApolloGraphQL

I do not work for apollo but I completely concur! I use absinthe on the backend with apollo on the frontend. incidentally, there any chance of you guys releasing an ios/kotin websocket adapter for phoenix. subscriptions don't currently work because it assumes a different transport later format and phoenix is indesputably the best websocket technology I've worked with. would love to run apollo subscriptions over phoen…

We’ve actually just released a roadmap for rehauling the Apollo Server transport layer, to better support different technologies there. Does https://github.com/apollographql/apollo-server/3184 help you at all?

Or, if this is something that would be implemented client-side, drop an issue over on the iOS client repo, we’ve just brought on a new engineer dedicated to the mobile native clients, she might be able to better help you.

Re: Using TypeScript with React

#168

Post by AgentME »

deviantfero wrote: post #165
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…

How do you suggest someone should proceed if an essential library in their project has no typing for typescript?

Make a .d.ts file somewhere in your repo, and make its contents be `declare module 'library-name';`. This will make Typescript treat the library and all of its exports as any-typed. If you find it useful to, over time you can fill in the .d.ts file with actual type information, and then maybe submit it to DefinitelyTyped when you think it's complete.

Re: Using TypeScript with React

#169

Post by mattmanser »

deviantfero wrote: post #165
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…

How do you suggest someone should proceed if an essential library in their project has no typing for typescript?

They almost all do if you look hard enough, but it there really isn't one this is one of those edge cases where it's ok to generally just define it as an 'any' and save yourself some hurt.

It's that or take the time to make it yourself, but it might not be worth the effort, it's for you to judge.

Re: Using TypeScript with React

#170

Post by Roboprog »

cryptica wrote: post #97
wry_discontent wrote: post #79

Earlier quoted context omitted.

I'm listening...

With plain JavaScript + VueJS you get instant (0ms) build time, few dependencies, fast installation, no vulnerability reports, no version compatibility issues, no source mapping issues, no environment compatibility issues, no missing type definitions, no need to waste your precious time on renaming interfaces and you can code everything in half the time! And that's not all; for an unlimited time, this toolset is 100%…

Well, I myself am certainly interested in going down that route, eventually (vs AngularJS, or, yikes, Angular 2+),

BUT, it appears that’s not a popular opinion on a post about Typescript and React.

I don’t seem to encounter many type and name errors when writing js, but I guess there is an audience for compile time checking, willing to pay the costs, and the industry certainly caters to them.

Post reply on HN