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

171–180 of 195 posts

Re: Using TypeScript with React

#171

Post by Roboprog »

azangru wrote: post #108
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…

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…

The fact that you wrote a function called “getValue” screams “Java programmer!”. Ordinary js, like C# and some other languages, has accessors so you just use the property name as an r-value (or l-value).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Using TypeScript with React

#172

Post by Roboprog »

Epskampie wrote: post #66
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…

I still don't hear a good argument as to why you should't use classes for your model. I use [serializr]( https://github.com/mobxjs/serializr ) to convert json to my classes, and afterwards I can have all the deligtful methods I want. :-) I love the code clarity this gives, methods are where they are most logical, instead of on some helper object.

Method implies use of this, which implies they are probably not first class - such would be functions cannot be passed or returned, as the this reference won’t be bound if called as a function.

Re: Using TypeScript with React

#173

Post by Bizarro »

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. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case.

No, it's going to be more tedious 100% of the time. Now, if that tedium helps you in the long-rum is up for you to decide.

Re: Using TypeScript with React

#174

Post by loceng »

aficiomaquinas wrote: post #140
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…

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

Humour's not allowed on HN.

Re: Using TypeScript with React

#175

Post by bhalithan »

aficiomaquinas wrote: post #140
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…

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

Why not?

Re: Using TypeScript with React

#176

Post by yenwel »

The whole discussion of typed vs untyped is stupid. Types and structures are all around us (albeit simple or infinitely complex, eg inductive vs coinductive). It is rather a discussion about typesystems that check type constraints immediately before shipping and/or after shipping while running the program. Without a proper typesystem the programmer has to check the types in his mind, or the end user gets a runtime error. For small hacks or prototyping type checking is not really required because of low overhead. But in non trivial larger, long running systems with a lot of maintenance the cognitive overhead is too big to not use a typechecker. Even if you decompose in microservices or microfrontends you still stuff like schema definitions and IDLs. Even hardcore ecmascript evangelists use linters extensively before shipping (potatoe/potato linter/typechecker)...

Re: Using TypeScript with React

#177

Post by jjakque »

skn0tt wrote: post #152
jjakque wrote: post #47

I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been: - Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If…

When it comes to API responses you don't control, I recommend taking a look at user-defined type guards: https://basarat.gitbooks.io/typescript/content/docs/types/ty... Also, +1 on tslint and prettier, they're great tools.

> type guard

Thanks for the link, I am currently doing something similar without knowing TS implicit behavior.

With 1st given example in the link, I forced on a style to such:

```

function doSomething(x: number | string) { if (typeof x === 'string') { doSomethingForString(x) }

  // Never do catch all to assume all non-strings are numbers
  if (typeof x === 'number') {
    doSomethingForNumber(x)
  }

  // Per transpiler rule, you not meant to be here, so error throwing is appropriate
  throw new Error('Unexpected type')
}

function doSomethingForString(x: string) { // Code }

function doSomethingForNumber(x: number) { // Code }

```

Re: Using TypeScript with React

#178

Post by hombre_fatal »

Roboprog wrote: post #171
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…

The fact that you wrote a function called “getValue” screams “Java programmer!”. Ordinary js, like C# and some other languages, has accessors so you just use the property name as an r-value (or l-value). https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Why pick on a contrived example? You can fill in your own less-contrived state + methods, it's not really the point of their question.

Re: Using TypeScript with React

#179

Post by hombre_fatal »

lifeisstillgood wrote: post #148

I just want to stop using JS on the browser side. We can compile C to WASM, which gives us effectively most dynamic languages on the browser. Say Python. I have a plan to put a tiny web framework together just having Python doing the front end stuff. Not react or anythng but enough for "most" use cases (I know I know) But JS just feels like it changes too fast, its been well over a decade of wheel-reinventing when th…

Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates.

Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.

Re: Using TypeScript with React

#180

Post by mosdl »

skn0tt wrote: post #150
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…

I see why you're missing an explanation on why classes should be avoided. In fact, your opinion is very similar to mine - I also think that, especially in the context of the FP-influenced React, data should be separated from behaviour - I mean how exactly are you going to preserve immutability using OOP? React just works a lot better when there's no self-mutating objects. Could you elaborate on why you think that cla…

Any method that mutates returns a copy, pretty easy to preserve immutability in OOP.
Post reply on HN