TypeScript support added to Create React App
github.com
github.com
If you haven't found any yet, that should be a Big Red Flag to you. It means you've let yourself get blinded by hype. The good news is that you're part of a team, and your team will probably be able to point some out to you.
Listen to them.
Once you've finally gotten yourself a sense of both the upsides and downsides, and have considered the latter seriously, work with your team to make a decision together. Then try to let yourself buy into whatever decision gets made!
There are definite benefits to TypeScript, but remember that no change comes for free!
I'm not blinded by the hype, im here asking people for what they see as the downsides, the reasons they may have or have heard of why teams didn't pick TS (or better yet did and had some reason it didn't work out).
In any case, happy coding
* 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...
"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...
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...
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.
I've been doing the same thing on our Angular app, but it has become clear that most of the frontend developers here lack the understanding on type safety, they're just unable to comprehend it for some reason. I've seen PRs that were just completely wrong because they couldn't understand how to do things correctly now that it's all typed. These are purely frontend people tho, they hardly work with any other language than JavaScript. But I don't consider Typescript a massive change from JavaScript, it just adds typing to it. Which any programmer should be able to comprehend.
Personally for me it has been great, it forced me to refactor really bad code, because I noticed that multiple methods kept returning different things, so the backend codebase is a lot cleaner now. Tests also have improved a lot because of all this.
Perhaps it might be worth trying to figure out how your team thinks about this, they might just be worried that they won't be able to work on it.
The other issue is that if people don't know what they are doing with TS, then imo it's worthless. I don't know your experience level with TS, but it is a non-trivial problem to build types such that it provides all the benefits you describe.
It is, in a lot of ways, a different language with its own set of problems to "solve."
Tread lightly, because adopting TS could be a blessing or a massive time sink for people not familiar with it.
If we bailed out and typed anything more complicated as `any` it would still be a huge improvement over writing vanilla js IMO.
https://users.rust-lang.org/t/what-have-been-the-drawbacks-o...
I've not used TS, but from what I've read the types from TS are not js compatible, so once you go into TS you have code that just isnt js.
(As opposed to flow, where you can just have it not be used)
While transpiling is normal, I'm as hesitant to tie myself to TS as I am to, say, a non-standard decorators syntax. Anyone coming to me with "there are no downsides" in such a case doesnt sound very credible.
Assuming I'm wrong, how would you address this?
TypeScript obviously compiles into JavaScript, and any valid JavaScript is also "valid" compilable TypeScript (the compiler will complain, but it will still compile it into JavaScript that does the same thing). With the right assertions (and @ts-ignore where necessary), you can even get the compiler to stop complaining!
TypeScript does have some differences beyond just type annotations: namespaces and enums come to mind. But it's easy enough to just not to use those features - they're not even supported by Babel.
The main downside is that you have a compile step where you might not have had one before. And it can be frustrating to deal with situations where there's no way to "fix" an error except by suppressing it – but these are really rare. But these are relatively minor issues.
Also, if that was a concern I would be willing to say we start out with jsdoc style types - I would much prefer the regular syntax and would like to use things like enums, but it would be a massive improvement over not having it.
In my mind, you are writing javascript with types whether you use typescript or not - using TS makes those types explicit and allow a compiler to check your work, on top of the other benefits.
I will rephrase though - instead of "there are no downsides" I'll say "Any downsides I have found are minute in comparison to the benefits", but my intent behind bringing this up in the first place is to hear from anyone else who does see more downsides than I do and to understand those.
Once you transpile the TS, you have standardized ECMAScript. Want to stop using TS? No problem. Just delete your TS files and work from your JS files.
And, beyond that, TS is intended to be a superset -- never incompatible, just "extra".
Finally, you can use TypeScript the same way Flow is used, through comments.
Tying yourself to TS isn't really something you can do, and there's zero risk in using it. You can always throw it out later.
This is quite an irresponsible comment.
The JS code generated isn't really meant for editing especially if you used a feature that isn't present on the runtime (like async/await in browser), not to mention all the formatting is rearranged.
If you're willing to go back to JS, you want to keep the original source.
Also, the async/await thing isn't an issue if you target the latest ECMAScript version. That's the only really ugly thing, and it's been easily avoidable for over a year.
That comment could make people throw away the original and end up with machine generated code when going back.
I used to have a problem where I'd be debugging the JS instead of TS file because visually, they were almost identical.
You do not want to work on that. It readable to an extent, but it's definitely not pleasant.
I don't think you could just go back.
Otherwise you can just prettify it and be on your way.
Sure you don't want to go back, but that's the whole reason TS exists: writing JS with good organization and discipline is impossible at worst, full of boilerplate at best.
The thing is, I found you have to be very diligent about how you organize your interfaces and how you might namespace them. I had some C# background, and had made a PR or two to the vscode repo -- so I had an idea of "good" code.
I think without some background in how you'll organize you types and, most importantly, types themselves you'll have some legwork in proving Typescript useful.
___
A suggestion I might have, because I found this mentally pleasing: start your project off small (get a few endpoints and some minimal database interaction). Let your co-workers look over it / maybe even do some small amount of work.
Create a typescript branch, where you convert each file to `.ts`. Typescript's compiler `tsc` can copy over all files `.js` and converted `.ts` so it's not essential you do this all at once, but I also found it not-so-painful either.
Demo this branch and show your co-workers that Typescript provides:
- A nice boost in productivity (autocomplete, hurray)
- Some confidence in how you're using types (this isn't a sound type system like flow)
- A way for people who don't have a background in javascript to feel more comfortable
Type safety isn’t worth having more complex prototypes, and having to keep up with both JS and Tyoescript, for us.
It’s very easy and forgiving to do a proof of concept though, because it integrates so easily into your existing code base.
Just be sure it actually adds real value and isn’t something you do for hype.
I’d certainly utilise it if we were building something as complex as VSC, but we aren’t, and I think it’s important to keep in mind that typescript isn’t all positive gains but that it also has downsides.
And then, you can code with TS on the server side as well as take that approach and write with modern language features on the browser side where you still have to write in ES5 (IE11) if it isn't for transpilation and develop with 1 consistent language throughout.
I've only used TS as a single dev but with multiple editors and they could have different version of TS from the other, I wonder what's the best way. Do you just help a guy with vim/vs code/IntelliJ/sublime/etc to set up to use auto TS compile and ask everyone to stick with a specific TS version? Or is it better to use something like Prepros to handle all the builds?
That way, everyone has an identical dev environment and we don't depend on any particular IDE (want to use Emacs? sure). No setup steps, just running one script to create a new namespace with all applications running inside. Broke it, messed up an upgrade? Just destroy and redeploy.
We hacked Arcanist[1] to run linters in the cluster. Modified a TypeScript file? "arc lint" will make sure your TypeScript pod is up-to-date and run the linter there, etc.
We're using custom tooling which is faster than https://github.com/GoogleContainerTools/skaffold, but it's the same approach.
Thinking about open sourcing it.
[1]: Phabricator's CLI client
It seems everyone is doing their own way of build process from local build, gulp, webpack or custom server processing and all has their downsides.
It does seem like a hurdle when this process isn't easy for everyone involved when switching to TS.
That's as much as I know about it. I don't use that feature because transpiling is such a minor issue that I can't imagine any universe in which I would use comment-style types, which are slightly more cumbersome to use.
This just isn't true. TS was designed from the beginning to allow gradually adding types. Whether transpiling or using comments, you can change one file at a time.
You don't realise what you had till it's gone!
And while I like that JSX is built-in, I don’t like that it’s so different. And having to use <div> ReasonReact.stringToElement("Blah") </div> (The spaces are required) everywhere instead of <div>Blah<div> makes it feel like a poor imitation of JSX and isn’t fun at all. But maybe they’ve fixed some of that.
Someone else said Reason is “better”. The type system might be more sound but TS is far more flexible and forgiving, and doesn’t have ugly and off-putting syntax for promises/async and interop.
Types are inferred, i only had to write a type once to disambiguate. Fearless Refactoring. If it compiles it works, except if you built in some logic errors. The compiler will find all syntactic and type errors, which might feel annoying at first but if you reframe it into the compiler is helping you then it is fine.
tldr: Reason is better than both TypeScript and Flow and has equally good interop with native untyped Javascript code.
I think this is a solid direction to go.
Let's just say I give the React devs... props.
https://github.com/wmonk/create-react-app-typescript/issues/...
I assume the real TypeScript compiler still does the type-checking and that would be unaffected by Babel.
SO: Any good way to learn TypeScript, particularly the more complicated types?
If you're using Create-React-App-TS, that's a separate fork of CRA 1.x that adds TS support, and has _horribly_ restrictive lint rules (many common style practices are treated as _compile_ errors). See https://github.com/wmonk/create-react-app-typescript/issues/... for discussion. (I ran across this while trying to set up a TS project for another team.)
I'm happy to see the TS support in CRA 2.x, because now I can actually recommend that people use it to get started with TS support.
I personally had never actually _used_ TS at all until this last week, when I was helping that same team rework some of their code. They'd been slapping `someVar : any` across the entire codebase just to make the compiler shut up. I tried adding a type representing their API response object, added it as a prop to the appropriate React component, and showed them how you could start getting autocomplete and compile-time catching of mistakes, and suddenly they began to see that there were actually benefits of using TS, not just overhead. I'm hoping to try adding TS support in to my own team's codebase in the near future.
In that _specific_ example, I think the key part is the "... is not assignable to ServerRoute | ServerRoute[]". It's just giving you all the fields in the type of the object you _are_ returning, and trying to tell you "I can't go from an A to a B". But yes, hard to pick out the key bits of info in there.
Still getting frustratingly long and nested error messages that are impossible to read within a tooltip or error pane of vscode. More often than not I just missed or misspelled a single property off an object, but the best source of information for that ctrl+space to see what the non-optional properties are with autocomplete.
Maybe I'm spoilt from what I've seen in Rust and Elm, but either the error messages are useless or I need to copy and paste the tooltip contents into another editor window to spend 5 minutes to decipher them.
It could be that I'm just dealing with complex types with the various libraries I'm using, and so there isn't much TS can do. Some of the React types do seem to get complicated.
I ask because you say that you want to learn the more complicated types, but I'd say it is better to stick to the basic types for your own code.
It seems obvious to me now, but It took me a while to realize: the reason TS type system is so advanced is to be able to accommodate all the crazy JavaScript APIs that are already out there in the real world. New code doesn't need (and most likely should not) use many of those complicated patterns.
This is also why other compile-to-JS languages have an advantage over TS: they don't have the burden of having to express all the craziness that is JS, and will probably be built around a much simpler/cohesive core of ideas.
TS is still an amazing compiler that provides lots of value: many projects other than TS benefit from TS type definitions. But I'd rather use something else if I'm writing an app from scratch. I'm exploring ClojureScript these days.
However, absolutist statements are not very useful... It shouldn't even need saying, but clearly large javascript projects do succeed from time to time.