
Using TypeScript with React - skn0tt
https://simonknott.de/articles/Using-TypeScript-with-React.html
======
jillesvangurp
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 by default over untyped javascript in professional environments. It's
like having tests, which are also not generally considered optional. I've been
in CTO type roles and already insist on it when I can. I don't think I'm alone
in this and many organizations only do typescript at this point.

~~~
gambler
_> 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 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". Zero self-awareness.

~~~
lhorie
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 utilities, but
they just shrug when I point out that the foundation of the scheme is still
unsound.

~~~
ng12
This is the equivalent of casting in Java. Is Java's type system unsound?

~~~
lhorie
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.

~~~
skn0tt
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<String, String> 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.

~~~
lhorie
Oh right, I totally forgot about casting to Object! So much for "sort of
sound" haha

------
h0h0h0h0111
I've been writing Typescript with React for quite a while now and these are my
feelings so far:

\- Typescript type system is pretty awesome, and allows the expression of some
things really elegantly; in particular, string literal types are quite cool
for component props that feel "htmly", union and intersection types are great
for making reusable/generic components and Partial<T> is cool for making
typesafe component states
([https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)
is a great resource)

\- on a related note, the Typescript docs are very comprehensive

\- ... but docs for anything React related to Typescript (types of components,
etc) are harder to come by

\- for the actual UI code there is some time wasted getting type signatures
perfectly correct, particularly for React and HTML components, but I've built
up a bank of helper functions in this regard.

\- using `any` nearly always comes back to bite you as you trick yourself into
feeling typesafe

\- there is always a tradeoff between having perfectly exact types and not
writing 139587123598 interfaces; expressing, for instance, mapStateToProps,
mapDispatchToProps and mergeProps to compose into component props, or the
former as a subtype the latter is pretty fiddly to get right and imo not worth
the extra code

\- create-react-app typescript support has gotten pretty good now, but it's
nigh-impossible to step outside their boundaries. For me, some older features
of typescript I wanted that protobufjs generated typescript used was just not
usable and I had to work around that with great difficulty

\- nearly all packages now have type definitions for them which is sick

\- at the end of the day, you can still resort to vanilla JS where typescript
really, really gets in the way

~~~
fabian2k
> ... but docs for anything React related to Typescript (types of components,
> etc) are harder to come by

I just saw this linked today and didn't look it through entirely, but this
React+Typescript cheat sheet looks very interesting for React-specific issues
you might encounter with Typescript:

[https://github.com/typescript-cheatsheets/react-
typescript-c...](https://github.com/typescript-cheatsheets/react-typescript-
cheatsheet)

For example it explained an issue with the type inference for custom hooks
that confused me somewhat earlier.

I really like Typescript so far, but you can easily encounter situations that
are hard to figure out with only basic Typescript knowledge, especially when
interacting with more complex libraries. This probably gets better with more
Typescript experience, but it can be a serious speed bump as a Typescript
beginner.

~~~
a_wild_dandan
This is wonderful, and probably a better strategy than the one I've employed
(e.g. hovering the onClick attribute of some component, seeing what type pops
up in VSCode, copying it, and using that for my type, done!).

------
bauerd
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 anymore so I can't figure out
which versions it used to resolve to …

The @types definition packages for react-router, redux-thunk, etc. give me
"error TS2605: JSX element type X is not a constructor function for JSX
element". Most popular answer on GitHub is to rm -rf node_modules and rebuild,
however that does nothing for me. I tried upgrading some @types selectively
and triple-double checked that the resolved versions make sense, but nothing
so far.

A codebase that used to build cleanly now throws ~30 errors on build, without
_any_ changes to it. Insane. Always pin your exact versions in JS land …

~~~
siempreb
> 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 the same time.

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. Good
luck with it anyways.

~~~
cryptica
>> 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

That should be at the top of every page on the TypeScript documentation
website. It would save developers so much suffering.

>> 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 the same time.

I'm still looking forward to the TypeScript version when they invent dynamic
typing and enforce it at compile time.

I have similar experiences. What I've found is that a team which can build a
high quality application in TypeScript is generally capable of building an
even higher quality application in JavaScript in half the time and with
better, higher quality test coverage.

>> 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.
Good luck with it anyways.

I look forward to this glorious day. Short live TypeScript!

~~~
sli
I do find it rather strange that strongly typed code with no errors, that
builds correctly, can fail at runtime due to type errors. My JS oftentimes
ends up nicer than my TS because I don't have pages of, basically, type-level
administrative work.

I don't have this experience at all in other strongly typed languages,
including _very_ strong ones like Haskell/PureScript. The types there just
work for me.

~~~
cryptica
This can happen if handling data from a remote client. Type checking does not
happen at runtime so you still need to do your own schema validation even with
TypeScript. So IMO it adds almost no value.

~~~
jimmyspice
in which case your API layer should validate the data at runtime so that it
only actually returns type T as it claims. then you are back to soundness

------
jinushaun
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 members.
These don’t have constructors.

You actually don’t need any of that. You just want type safety around your
JSON and POJO. That’s why more often than not, you’re going to be using
interface.

I’m not saying never use classes. But don’t use classes to define models. Use
classes for controllers.

~~~
azangru
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?

~~~
neurotrace
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

~~~
azangru
It’s just that they started their post by saying that classes in Typescript
should be avoided. A message "x should be avoided" is very different from "you
don’t need x". Compare the statement "you don’t need redux", which has been
incorporated into titles of numerous blog posts, with the statement "redux
should be avoided".

------
jjakque
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 the usage going to persist (example, using a
library without @type), then you treat it as JS and have appropriate amount of
validation around the occurrence.

\- Usage of "?" and "!" covers more scopes with less lines of code. For
hobby/one-man project, I found their usages no-brainer, however I'm nervous
when it comes working in a team of various experience level.

\- I've had real headache typing API responses. On one hand, you have absolute
no control of others' code quality that you might as well have "number |
string | null | undefined" for all parameters. But doing that almost defeats
the purpose of typing it, so I'll need to use my educated guesses and judge
reliability of each known parameters in responses.

\- TypeScript version of 'create-react-app' projects builds slower than its
JavaScript counterpart without ejecting. It took 2~6 seconds per build while
IIRC, it was <2 seconds for JS. I was keen to find a solution for this, but
after a while it grow on me and I simple stop save after each line of code.

\- JSDoc is still relevant in TS code. It is great to document event emitters,
exceptions etc.

\- tslint and prettier are must in my projects in order to retain sanity for
unnecessary discussions around coding style.

~~~
skn0tt
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...](https://basarat.gitbooks.io/typescript/content/docs/types/typeGuard.html)

Also, +1 on tslint and prettier, they're great tools.

~~~
jjakque
> 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 }

```

------
hki99
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 frustration when a package doesn't have types (although most major ones do have them).
    

Otherwise it has been a joy writing the application, and it does "document"
your components significantly better.

~~~
latchkey
Development time isn't slower when you factor in all the bugs it saves you
from dealing with down the road when you're either wonder what is the type of
an object or why something isn't working during runtime that a compiler could
have caught.

~~~
a_wild_dandan
Also, if you're working with an untyped APIs, define the types you're using.
It doesn't have to be complete or perfect. But having that formal contract
will save you time and make explicit your assumptions. In the best case, you
can contribute those types to the API to everyone's benefit.

------
namelosw
React is more functional favored. It's very recommended for functional
languages having static type systems, at least for language like JavaScript
heavily relies on object literal.

The problem is, dynamic OOP languages like Ruby and Python are Okay to work
with, since you know the class of an object you know a lot of things (schema,
behavior, etc).

But for JavaScript and React, mutable classes are not quite useful since they
mutate themselves, and could stop the app from re-rendering. it's more likely
people are using object literals, which can hardly go far.

With TypeScript's structural and gradual type system, it's flexible and easy
enough to type object literals with the union and intersection types, without
forcing people to use classes.

------
davidjnelson
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
readonly, Readonly<T>, ReadonlyArray<T>, ReadonlyMap<T>.

The language is so much fun to both write and read. There’s a lot of depth to
it as well. Excited to get to use it.

1\.
[https://m.youtube.com/watch?v=wYgSiFaYSSo](https://m.youtube.com/watch?v=wYgSiFaYSSo)

~~~
cryptica
>> 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.

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

Architecture is important regardless of what language you are using.

~~~
cryptica
Thanks. I feel like there should be a lot less discussion about tools and a
lot more discussion about architecture. I find that with good architecture,
the language doesn't really matter at all.

I've built high quality very complex projects in both JavaScript and
TypeScript (both alone and as a team lead). My point is that I (and people of
my skill level) can complete the project/subproject much faster with
JavaScript so it gives me a lot more extra time to write tests.

------
rimher
I see the same response everywhere on TypeScript: when a project becomes big
enough, it's a good way to keep it under control.

And I tend to agree: types can be annoying, but when stability and robustness
come into play, TypeScript is most certainly the way to go. It enforces good
behavior.

And yeah, of course it slows JavaScript down, that's entirely the point..! JS
allows you to do whatever you want, but that doesn't mean it's always the
right choice

------
manishsharan
If you are going to learn a new programming language for web UI, why not go
for Elm ? You get so much more than just static types with Elm.

~~~
iraldir
Looked at Elm and it looks quite interesting. however concerns for going to it

\- Skill transfer. If I learn react, I can use my JavaScript skill to
understand how everything works under the hood. If I learn Typescript with
React, knowing react, I can focus on learning new language feature while not
learning at the same time how to build the application. With Elm, I have to
learn the language and the framework, all at once, basically learning from
scratch.

\- compatibilities with libraries. Here I definitely might be wrong, not
knowing Elm enough, but okay, say you don't need a framework because it's
included. What about utility library. Like i don't know, analytics or fancy
animations?

\- Job Market. I'm not going to learn a language that I cannot use anywhere,
and if I'm a company, I'm not going to choose a language for which is going to
be hard to hire people.

Now Elm sounds real cool and I want to like it. But it doesn't seem very wise
to spend time doing that vs learning something like Apollo+Graphql, or
Typescript, or Vue, which have much more obvious benefits to my career.

~~~
manishsharan
The job market is a chicken and egg type problem. Management would not allow
Elm based projects as there are no othe Em programmers on staff. We cant ask
for Elm programmig experience in resumes as we dont have any Elm based
projects.

I wonder how other languages,like Scala, managed to get traction in the
enterprise whereas Elm has not even though it can solve real issues that we
face with Javascript development.

~~~
aphexairlines
Scala got traction in places I've worked partly by making the pitch that the
team hires people based on software engineering aptitude, not prior knowledge
of specific technologies.

A new hire often has to learn a number of new/different technologies. The
language is one of the easiest of those.

------
wintorez
“TypeScript solves problems that I don’t have, in a way that I don’t like.”

~~~
JoeyJoJoJr
What are the problems that Typescript solves that you don’t have?

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

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

~~~
hombre_fatal
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.

~~~
lifeisstillgood
I disagree.

JS _should_ be like SQL - everyone's second language and a _standard_ that can
be taken from job to job and company to company and still be effective.

But while I this week used my decades old SELECT skills for a quick two day
job, I have also been utterly stumped trying to modify react codebases.

JQuery is probably the closest thing to SQL in the JS world and it is fine -
but there appear to be few technical reasons not to use it and lots of fashion
reasons.

And so while I could just stick to JQuery and some widgets, the weight of
development seems to be in the morass of _change_ that is so very hard to stay
on top of.

Yes this feels like crotchety old timer moaning, even to me. But there is
something there. I am having trouble expressing it however.

~~~
hombre_fatal
Client development was never trivial. Your old iOS/Android skills also expire
due to SDK changes. Apple recently switched out the entire language you're
using.

I don't think SQL is a great example either. Your next company could be using
any database where you aren't even writing SQL. And you're expected to know
more than standard SQL to, say, use Postgres. Your rant here to me is like
getting mad that "just SQL" isn't enough because you constantly have to learn
more at your next job that uses Postgres, DynamoDB, etc or that "just
<language>" isn't enough because your next job uses a different framework than
you're used to. I don't think your rant is consistent, so it just comes off as
confused anger towards JS client development.

Maybe you don't have the stomach for client development where code must run on
a machine you don't control? That isn't a disparaging remark either, it's very
reasonable to prefer the cozier environment of writing code for machines you
do control (like application servers).

------
izolate
I get why TypeScript is quickly becoming the standard, but the problem with it
is that it's still JavaScript, and contains all the warts thereof. If at some
point your attention turns to the very real benefits of static typing, why not
choose an objectively better language?

That's why after ~10 years of being a JS/Node developer, I switched to Dart,
not TypeScript.

------
holografix
For typescript to be very useful to indispensable the tooling needs to
improve.

If there was a checkbox on VSC that said “use typescript” for a project and I
had to do _nothing_ else for it to work then sure, I’d use it.

For a single dev working on a fairly simple React + Redux app it’ll slow you
down like no tomorrow.

~~~
onion2k
What you're asking for _mostly_ exists. You don't even need a checkbox.

TypeScript support has been included with create-react-app since v2.1.0, with
all the features enabled. VS Code ships with syntax highlighting and command
completion for TS.

If you want to try it use;

    
    
        npx create-react-app tsx-test
        yarn add typescript @types/react
        mv ./src/App.js ./src/App.tsx
        yarn start
    

(WARNING: npx runs stuff from the internet on your machine)

That will make a 'typescript' React app run on your machine. Obviously App.tsx
isn't actually doing any TypeScript stuff, but if you add some it will work.

~~~
resurge
Note that they said "React + Redux". And that combo indeed takes a lot more
time to get set up and understand the first time.

I used this lib to get it to work: [https://www.npmjs.com/package/typesafe-
actions](https://www.npmjs.com/package/typesafe-actions) I wouldn't even know
how to get it to work with just the regular react & redux types.

~~~
onion2k
typesafe-actions looks useful but you don't strictly need it. You can use
redux with TS just by adding @types/react-redux.
[https://redux.js.org/recipes/usage-with-typescript#usage-
wit...](https://redux.js.org/recipes/usage-with-typescript#usage-with-react-
redux)

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

~~~
eropple
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.

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

~~~
eropple
I'm sure that, if you're carrying a torch for Haskell, TypeScript can feel
very primitive--though I don't enjoy writing Haskell, in my experience it
turns into an exercise in navel-gazing and write-only code compared to
TypeScript or F#--but on the other hand _normal people can write it and be
productive_ and that's kind of important, yeah? I think the TS folks did a
great job in making something that I can bring into engineering shops to make
average to average-plus developers significantly better and significantly
safer.

I'd really disagree with the notion that discriminated unions/ADTs are
useless; the compiler is clever and will constrain the type in an `if` or a
`switch` (particularly useful with an enum type, too). I use this regularly
and it's really effective; my `nestjs-auth` library makes it more or less a
requirement and its users seem to really dig it. And if you do it as an
abstract class instead of a key, you can use polymorphism to take care of a
lot of what would otherwise be pretty clunky--this is how you can make a solid
maybe/option type in the vein of Scala.

~~~
verttii
Hehe yes the Haskell community certainly suffers from the dynamics you just
described.

I guess my problem with TS ADTs is just that they're done with the TS
primitives whereas they could be true first class citizens. But such a feature
may be too hard to swallow for your typical JS developer whose first
introduction to types is Typescript.

Btw can you elaborate on that Enum with ADTs? Or did you mean that you use
Enums with switch-case? I use it too and find it one of the best bits of TS.

~~~
eropple
I do mean enums/switch, yeah. Makes it easy to have your code yell at you when
all cases aren't dealt with.

The thing about making ADTs first-class citizens means that TypeScript stops
being JavaScript, and one of the most valuable parts of TypeScript to me is
that I can just look at it and know what the underlying JavaScript is. I kind
of equate it to writing C on an old platform--it's going to be munged
significantly but at a glance you can have a high degree of confidence that
the code coming out the other end is going to be what you expect it to be.

------
greenpizza13
In 2019 is this article adding anything to our collective knowledge? There's
nothing new here at all.

------
robmoorman
React is already typed with props. I see no added use for TypeScript. Yet
another list of packages makes maintaining very hard and inconsistent (as
types are declared in variant ways). Explicit (and simple) functions as React
(e.g. hooks) provides won't need strongly typed code, less readability in my
opinion.

If you're building a library / sdk, than Typescript comes in place and can
make life easier for devs.

~~~
underwater
PropTypes are disabled for production builds and runtime only.

The only advantage for using them over TypeScript or Flow that I've seen is
when consuming third party React components.

Otherwise the guarantees, feedback loop and terseness of static types are
superior to PropTypes.

