I think the evolution and increased popularity of TypeScript over the past year or so means that it is a good time to migrate towards using it on DEV.
Nick Taylor has been the biggest proponent, but it all jives with my view of things.
Read more here:
dev.to with a TypeScript or Flow frontend codebase?
Nick Taylor ・ Apr 8 '19 ・ 2 min read
I think this initiative can pretty effectively be led by the community rather than top down from our team, because we won't need to provide a lot of specific instruction in order to make improvements in these areas.
Any pull requests to provide good instructions for this approach in the README and/or docs would be appreciated to get the ball rolling on this.
Part of the reason I feel like we can get moving on some of this now is that GitPod might be useful for helping frontend developers get up and running with the codebase and making changes without the worry of installing and getting the app running locally.
Spin up a "local" instance of DEV in the cloud with GitPod (It's incredibly simple)
Ben Halpern ・ Apr 8 '19 ・ 2 min read
Only time will tell if GitPod leads to true productivity enhancements for frontend developers looking to contribute, but I think it's something worth exploring.
Top comments (21)
I find one of the easiest and most comfortable ways to slide into TypeScript are to leave the current code base as-is and first add
Second ... once comfortable ... I recommend adding new files as TypeScript. You'd likely want to create a
tsconfig.jsonfile and a
What's the biggest hangup in typescript I see? One of the big ones I try to help folks with is avoiding the feeling that everything must be typed.
anyis ok. Embrace it when you start out. You can always get more specific later if it helps. Also, if the type can be implicitly determined, then don't explicitly type it. Here is an example ...
Notice that the second one is still a string. We defined it as such. Why bother adding more code? More code is more to maintain and it can make code harder to read. Not buying it yet ... try this one ...
This could be much more readable like this ...
Thanks for indulging my stray thoughts :)
In total you'll get:
Thanks for replying! These are good questions to ask. They are not "stupid" in my opinion :)
You do write more code with TS, but you also get a stronger sense of finding issues while coding vs finding them while they code is in production. To me, one of the biggest values in TS is that many potential bugs surface themselves at dev time vs run time.
Is there value in only having new code in TS? There can be as this new code would make me feel more confident. You can also add the
Again, thanks for the great questions. Always good to ask - especially if something isn't quite feeling right.
Set allowJs to true in the tsconfig.json file to tell typescript to look at the js.
Why didn't you just recommend this from the start? Seems a lot simpler than to add
// @ts-checkto every single JS file like you said in your original comment :P
I work on a large older codebase that we decided to convert to TypeScript. While it has taken us some time to get there, we are at probably 95% TypeScript, and the rest should be taken care of within a month. It is definitely possible, and is easier to do the more you realize it helps you with code quality and developer happiness. It went from being a chore to being an exciting thing to convert a file over here and there.
Love this approach!
If you use tslint, you can enforce this with the no-inferrable-types rule 🙂
ReasonML plzkthxbye 🙃
I'd be open to multiple approaches in different areas if it doesn't add up to more and more bytes needing to be shipped.
This is also a good time to try it out–there's been a new ReasonReact release that supports writing zero-overhead React components, with hooks support: reasonml.github.io/reason-react/bl...
On top of all that, ReasonML output minifies really well with Rollup (dead code elimination).
I've just freed up from some other TypeScript OSS, so I'm going to start jamming on this to provide a POC.
For those interested, this is what has been taking most of my OSS bandwidth.
Enable strict-mode for TypeScript #1783
Basically going with the non-null assertion operator in almost all places, because as mentioned in github.com/sindresorhus/refined-gi..., the assumption with the extension is that the DOM nodes referenced in most cases are expected to be there. If they aren't, the extension breaks, a bug is filed and it's fixed.
One thing to note @bfred-it, is currently dom-chef types need to handle JSX (Element and IntrinsicElements) or we import
I think it's a solid move. It will also make your devs less bored if you give them new tools to play.
To my mind, Flow has always made more sense than Typescript.
Any change you want to make Ben I'll support.
As someone who works on a Rails codebase, it's really nice to see other Rails applications in the wild and I appreciate DEV.to for it.