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

141–150 of 195 posts

Re: Using TypeScript with React

#141

Post by skn0tt »

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'm with you on this. In my opinion, TypeScript can really get in your way when you develop in a way that's not TypeScript-friendly, but you'll benefit heavily once you start developing with types in mind.

Re: Using TypeScript with React

#142

Post by arcticfox »

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…

(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 with OP that as a default, TS should be used over untyped JS in professional environments.

Re: Using TypeScript with React

#143

Post by EpicEng »

cryptica wrote: post #101
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 can come up with any number of excuses but the bottom line is that TypeScript adds complexity which creates a lot of different problems which plain JavaScript does not have.

Because JS apps never have package management issues, right? If you don't understand your tools, it will eventually bite you. Has nothing to do with TS.

Re: Using TypeScript with React

#144

Post by incadenza »

cryptica wrote: post #102
davidjnelson wrote: post #98

Typescript is awesome!!! The creator of it answers “why typescript” in a video[1] with a hilarious answer which includes his observation that large javascript codebases become read only :-D I’m giving a talk on typescript Friday. Some good stuff to understand is index signatures for object lookups, union types, intersection types, combining index signatures with named properties, and compile time immutability with re…

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

How specifically does the addition of static typing encourage spaghetti code?

Re: Using TypeScript with React

#145

Post by skn0tt »

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…

That's a very good point! Although I find the example to be rather exaggerated, I see how these types of errors can happen when you're dealing with very complex types. In the post, I also talk about how wrongly-typed dependencies will compromise type safety, which can be another source of errors.

Nonetheless, I think that TS can catch a lot of errors and will help documenting your code - and that's a very good thing on its own.

Re: Using TypeScript with React

#146

Post by skn0tt »

lhorie wrote: post #133
ng12 wrote: post #114

Earlier quoted context omitted.

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.

Correct me if I'm mistaken: I think you can indeed cast from HashMap to Animal and it will happily compile:

```java

import java.util.HashMap;

class Main {

  class Animal {
    String sound = "roar";
  }

  public static void main(String[] args) {
    HashMap map = new HashMap();
    Animal animal = (Animal) (Object) map;
    System.out.println(animal.sound);
  }
} ```

At runtime, this will crash with the following Exception: `Exception in thread "main" java.lang.ClassCastException: class java.util.HashMap cannot be cast to class Main$Animal`, but it will satisfy the type system.

Re: Using TypeScript with React

#147

Post by allover »

lhorie wrote: post #137
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 don't think GP is criticizing the flip-flopping, but rather the "arrogantly spouting" part.

Well it's the generalisation about a large community that is the problem, whether put arrogantly or not (the arrogance only makes it harder to scroll past and ignore). GP put it well:

> I'm always confused when someone calls out a large group of people for not having a consistent opinion.

Re: Using TypeScript with React

#148

Post by lifeisstillgood »

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 the fundamentals of tabular display, layout and so forth have to be relearnt every year or two.

Re: Using TypeScript with React

#149

Post by neurotrace »

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…

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

Re: Using TypeScript with React

#150

Post by skn0tt »

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 classes should be used when implementing controllers? I tend to think of controller classes as singletons, which kind of contradict using classes in the first place.

Post reply on HN