Using TypeScript with React • Hacker News Board

Re: Using TypeScript with React

#101

Post by cryptica » Thu, Aug 22, 2019, 4:18 PM UTC

wereHamster wrote: post #81

bauerd wrote: post #36

I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anym…

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.

Re: Using TypeScript with React

#102

Post by cryptica » Thu, Aug 22, 2019, 4:22 PM UTC

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 passed around all over the place and makes your code brittle and fully dependent on TypeScript to make any changes.

TypeScript allows you to write a lot of spaghetti code and allows you to delay having to think about architecture until your code is a total complete unmaintainable mess.

With JS, you will discover if you architecture is a mess a lot sooner and you will learn more and adapt faster.

Re: Using TypeScript with React

#103

Post by davidjnelson » Thu, Aug 22, 2019, 4:28 PM UTC

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

This may help:

https://www.typescriptlang.org/docs/handbook/advanced-types....

Re: Using TypeScript with React

#104

Post by no_wizard » Thu, Aug 22, 2019, 4:30 PM UTC

joshAg wrote: post #13

hki99 wrote: post #3

During my internship we've built a large prototype using React+Typescript, and here are some of my key take aways from it: - Quite often when using unreleased APIs, you turn to using "any" all over the place. - Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features). - Lots of frustrati…

The way we've been using typescript is that when you're first implementing the API using 'any' is just fine, but it's not ready for release until all the 'any's are removed. What I've found is that there tends to be a happy medium between making everything 'any' at the start and never using 'any' at all that roughly corresponds to how defined our implementation is. When we're designing the implementation as we go, th…

I'm curious, and I'm prefacing this up front because I'm not always good at writing what I say in a way that may not feel like I'm coming from a good place, so here goes:

Whats your testing story? This to me seems like not writing good, solid, abstracted tests before doing proper implementations of your code. This could be solved with good interface design, and perhaps be faster.

I apologize in advance if this sounds harsh. This sounds like the exact thing folks on my team were trying to do, and it was turning things very sub-optimal.

(Disclaimer: I'm a bit of a TDD/BDD idealogue. Not as hardcore as Uncle Bob[0], certainly, but close enough. I think writing Interfaces before Tests is acceptable, I think that might be where things differ, i guess).

[0]https://blog.cleancoder.com/

Re: Using TypeScript with React

#105

Post by cryptica » Thu, Aug 22, 2019, 4:36 PM UTC

bauerd wrote: post #86

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

This is a perfect example of a developer blaming themselves when in fact the real problem is that the tool is too complex with too many moving parts and that's why it breaks all the time.

If you're a driver and your car keeps breaking down constantly, you wouldn't open up the hood each time, slap your forehead and say "It's OK, it's only the camshaft phase variator this time!" You rightly expect the car to just work. If the car breaks often, it means it's shit; simple as that. The solution is to buy a better car. And there is no excuse in this case because plain JavaScript is 100% free.

Re: Using TypeScript with React

#106

Post by davidjnelson » Thu, Aug 22, 2019, 4:37 PM UTC

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…

Glad you enjoy large javascript projects and it works well for you.

Architecture is important regardless of what language you are using.

Re: Using TypeScript with React

#107

Post by timdorr » Thu, Aug 22, 2019, 4:39 PM UTC

bauerd wrote: post #86

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

Actually, that happens all the time. The way node resolves modules and npm installs them, it's entirely possible to have several different versions of the same dependency. If you use npm ls, you can see where they ended up.

Re: Using TypeScript with React

#108

Post by azangru » Thu, Aug 22, 2019, 4:41 PM UTC

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 are models and controllers in React codebases, and why is using classes for one of these groups any better than for the other?

Re: Using TypeScript with React

#109

Post by bauerd » Thu, Aug 22, 2019, 4:43 PM UTC

cryptica wrote: post #105

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!

This is a perfect example of a developer blaming themselves when in fact the real problem is that the tool is too complex with too many moving parts and that's why it breaks all the time. If you're a driver and your car keeps breaking down constantly, you wouldn't open up the hood each time, slap your forehead and say "It's OK, it's only the camshaft phase variator this time!" You rightly expect the car to just work.…

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

Re: Using TypeScript with React

#110

Post by jakear » Thu, Aug 22, 2019, 4:45 PM UTC

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…

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

Disclaimer, I work for ApolloGraphQL