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

61–70 of 195 posts

Re: Using TypeScript with React

#61

Post by untog »

siempreb wrote: post #45
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…

> now throws ~30 errors on build Yep, it's a beautiful technology, total type safe heaven. Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at th…

> Yep, it's a beautiful technology, total type safe heaven.

If you do what you're actually supposed to do (check in package.json files) it is.

> Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

Oof, no. As you say, you're basically removing all the benefits of using TS that way. Honestly it surprises me what a hard time people have with it, it felt entirely intuitive to me not long after starting to work with it, and now I don't think twice about it (except to be thankful for it)

> I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly

I think the benefits of this are wildly oversold. There will be some very performance-intensive areas where WebAssembly will be useful, and it'll be a boon to be able to bundle cross-platform libraries easily. But outside of that you're going to be adding complication for little real benefit, and good luck hiring a "Go web front-end engineer" to work on your brand new codebase...

Re: Using TypeScript with React

#62

Post by Epskampie »

verttii wrote: post #59

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

Verbose? Do not agree at all. Adding types to function parameters for example is just a simple ": TYPE" I do not see how that could be much shorter.

Furthermore, where possible (variable assignment, function returns) types are inferred, and do not need to be specified at all, leaving you with mostly plain JS syntax.

Re: Using TypeScript with React

#63

Post by eropple »

verttii wrote: post #59

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

I feel almost the exact opposite: TypeScript is delightfully terse while still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript.

You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nasty level of boilerplate. (They can also be implemented with an abstract class if that's more your bag.)

It lacks pattern matching because it intentionally doesn't include a runtime component, which I think is also wise. Options exist if you want to use them. I've seen people use Purify to good effect.

Re: Using TypeScript with React

#64

Post by seanmcdirmid »

amoerie wrote: post #55
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).

Generally, try the following steps: - turn off strict flags, turn them on again after everything compiles in non strict mode - ensure you have the correct typings for the libraries you're using. Some libraries include them, others require a @typings/xyz dependency. (E.g. React and ReactDOM) - try to hunt down the root errors. Much like C# or Java, one error can lead to hundreds of compilation errors down the line, bu…

Typescript is really unlike C# or Java though, error cascading is a much much bigger issue in a structural type system than a nominal one, where the x method not implemented by class C will trigger whenever you try to call the x method (in a nominal type system you just get the error once, the typescript team could probably do a better job with this by investing some resources into the problem).

Re: Using TypeScript with React

#65

Post by eropple »

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…

> Discourage 'any' but not been afraid of using it when must.

I've found that I rarely need `any` anymore. My solution has been `@ts-ignore` (and a warning coming out of tslint for that, to clean up as better typings, etc. arrive) and the `unknown` type, which better encapsulates the "valid" uses of `any`.

> I've had real headache typing API responses.

Swagger and generated library code has made this a lot better in my neck of the woods. It isn't perfect, of course, but it's incrementally better. (Obviously, if you don't own the API, it's harder. Though I've also defined Swagger docs for third-party APIs in the past and generated my own clients, if I understood them well enough.)

Re: Using TypeScript with React

#66

Post by Epskampie »

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.

Re: Using TypeScript with React

#67

Post by verttii »

Epskampie wrote: post #62
verttii wrote: post #59

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

Verbose? Do not agree at all. Adding types to function parameters for example is just a simple ": TYPE" I do not see how that could be much shorter. Furthermore, where possible (variable assignment, function returns) types are inferred, and do not need to be specified at all, leaving you with mostly plain JS syntax.

No algebraic data types leads to having to add an additional discriminating union type key.

Besides that, no type signatures without parameters and other things just produce a lot more code than you'd have in a nicer type system.

Re: Using TypeScript with React

#68

Post by verttii »

eropple wrote: post #63
verttii wrote: post #59

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

I feel almost the exact opposite: TypeScript is delightfully terse while still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript. You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nas…

I guess it depends on what you compare with. If you're coming from Java or the like, surely TS does not feel particularly verbose.

However, coming from a truly terse language like Haskell you'll just feel TS is too verbose and not very elegant. TS is the most verbose and least elegant of the languages I'm personally using, on par with Dart.

ADTs not only feel dirty because they're not first class citizens (you build them with the TS primitives by adding a discriminating union key) but also somewhat useless since you don't have pattern matching.

Although pattern matching would not be a trivial problem to solve in TS. It could be solved with the compiler, however, you'd still have to hack the compiler API quite a bit too and TS doesn't even support integrating custom extensions with a config file like Babel does.

Btw thanks for pointing me to that ts-purify, it looks good!

Re: Using TypeScript with React

#69

Post by 0XAFFE »

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.

There is also class-transformer[1] and class-validator[2] which also do the same job but integrate a bit better into the whole typescript cosmos.

[1] https://github.com/typestack/class-transformer [2] https://github.com/typestack/class-validator

Re: Using TypeScript with React

#70

Post by brlewis »

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…

There's a historical reason why classes are used a lot for models. It's up to you to decide if this reason applies to your project or organization.

A few years ago there was a dilemma between ES6 and TypeScript. A lot of JS developers chose to stay away from TS in order to follow the ES6 path instead. Then TS harmonized with ES6. But it retained a reputation for being an incompatible alternative to ES6 rather than just JS+type annotations. However, if you write classes, they look just like ES6 classes plus type annotations, allaying concerns.

Post reply on HN