Hacker News Reader

Comment by jasonkillian | Hacker News Reader

There are _some_ downsides:

* Slightly more complex build workflows

* Integrating with non-TypeScript libraries can be difficult depending on the quality of external typings available

* Error messages can at times be slightly obtuse (especially depending upon the complexity of types used)

* Learning curve of TypeScript (Certain language features can be a bit complex. For example, mapped/conditional types might seem tough for a beginner. See here for an example[0])

That said, to me, it's still a no-brainer to use TypeScript for anything beyond the most trivial of apps. The advantages it gives you have heavily outweighed the disadvantages in my experience so far.

[0]: https://github.com/piotrwitek/utility-types/blob/532fe5cfcc5...

View on HN

My favorite is [1]. The downstream errors that type generates are "fun."

"Slightly obtuse" is an understatement when dealing with `Pick` and the errors the complimenting mapped types generate. Once you throw in React and higher order components, you can get errors that are literally several console pages long - although that's usually just tsc "tracing" the error through the complex types.

[1] https://github.com/piotrwitek/utility-types/blob/532fe5cfcc5...

They have been working on the error UX for the last 2 releases and still have some things planned https://github.com/Microsoft/TypeScript/issues/26077

Yes, your experience mirrors mine completely. It's quite difficult to get complex higher-order components working correctly, especially if you're throwing in things like defaultProps and propTypes. For example, some issues I've hit recently: [0][1].

I think this is likely an artifact though of how powerful TS's type system is. I'm sure there're error-readability improvements possible, but with such complex type constructs, it's not all together surprising to me that the error messages can be difficult.

My worry with these challenges is not that they make TS unworthwhile (it's still completely worth it), but they do make it a little harder to convince a team to adapt TS and sell TS to React developers who are use to working in JS.

I know the TS team has React support as a priority and they've done a pretty great job of making TS React-friendly. I do wish they'd be slightly more hands on with maintaining `@types/react` and even publishing documentation, but perhaps it's fine to leave that to the community.

For those struggling with React typings, https://github.com/piotrwitek/react-redux-typescript-guide is my current favorite resource.

[0]: https://github.com/Microsoft/TypeScript/issues/27484 [1]: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/28...

I always found react-redux's connect function maddeningly hard to understand, because it does far too many things all in one function. The types just expose that complexity, and make it plainly obvious that it should be split apart.

The great thing about types is that the make you think more about keeping you APIs nice and clean on a semantic level, not just about if the syntax in your examples look pretty. I really hope more library authors use them early on so they avoid such mistakes in the future. There's only so much the Flow and TypeScript devs can do to make up for those existing problems.

Which gets to my wish that instead it is the React team themselves that adopt and maintain @types/react more directly, rather than leaving it to the community and/or Typescript devs. Seeing CRA add default support for Typescript transpilation with easy opt-in for type checking, is a great sign that plenty more React developers are going to have a chance at Typescript. Hopefully it becomes more of a two-way street where the Typescript community isn't just typing major React libraries after the fact, but more of the libraries are directly written in Typescript or at least the types are directly maintained by the authors of the APIs.

Reply on news.ycombinator.com