Shout out to @rhymes for giving this post a review. 👏
Before the dev.to codebase was opensourced, I was working on it in the private repository and created an issue in there that has since been copied to the public repository (thanks @maestromac!).
Consider using Flow or TypeScript in the Front-End Codebase
#383
@nickytonline commented on Sun Apr 29 2018
I'm not saying we need to do this, but yes I am a convert of static typing in JavaScript, so I do have some bias on this.
Having worked on several projects with large JS codebases, I can definitely say that it eliminates a lot of silly mistakes, improves dx and it gives developers a clearer view of what contracts and shapes of things are in the codebase. I've even written about it in the context of TypeScript.
The reason why I'm proposing this is twofold. The first is everything above, the second reason is it may (no guarantees) pique developers interest in contributing to dev.to OSS on the front-end more than say on a project that does not use TypeScript or Flow.
I've used Preact with TypeScript and the support seems solid since their last release, but for Flow, I'm not sure as I haven't really used Flow. I threw out this question to the Twitterverse, https://twitter.com/nickytonline/status/990768742178152448.
A third proposal, if this was a no go for everyone, is you can still get some type checking from TypeScript if you're using VS Code without event having a whole TypeScript build pipeline set up. If you add a // @ts-check comment at the top of the file, you get type checking. See https://code.visualstudio.com/docs/languages/javascript#_type-checking.
I was wondering what peoples' thoughts are on this?
@benhalpern commented on Tue May 01 2018
I"m in favor of this. And I think we're getting towards the end of a sprint where I and we collectively haven't been in the mindset to go back to the drawing board, but we're getting there now. This is definitely a convo I'd like to be having.
@nickytonline commented on Mon Jul 09 2018
@ben, this is probably something good to discuss before open sourcing the code base.
Looking at Flow and TS, I would probably lean more towards TypeScript. Not just because it's what I've been using professionally for quite some time, but because I think the ecosystem of types is larger and it has more adoption/tooling.
For reference, my blog post, Consider Using TypeScript mentions some fairly large/popular projects using TS, e.g. Slack, MobX, LinkedIn, RxJS etc.
Even though the new Preact components are currently just JS, you can go into a hybrid mode and slowly convert things to TS while still having JS live in TS land as valid JS is valid TS. This is what we do at the moment with a large project that we're converting slowly to TS.
This could also be a good way to have some live sessions about contributing to the code base. Maybe a few sessions about TS.
@nickytonline commented on Thu Aug 16 2018
@maestromac, when you have a chance, can you migrate this issue to the public repo? No rush as I'm off for another week. Thanks.
For those new to types, here's a post from Preethi Kasireddy about types.
Also, here's a fairly recent episode from the Script and Style podcast about types in JavaScript, Static Typing for JavaScript.
TypeScript
I'm partial to TypeScript myself. I've written about it here before.
There appears to be a shift towards TypeScript for those that are interested in types. I wrote a bit about it here
There is also a great episode on the React Podcast that talks about TypeScript with Jared Palmer.
Take TypeScript for a spin in one of the playgrounds:
- Unofficial Playground
Flow
Flow is another option in the frontend in regards to types, although I've never used it myself.
Here are some links if you want to read up on Flow.
- Writing Better JavaScript with Flow
- An Introduction to Flow
- Flow: A Static Type Checker for JavaScript
- I honestly did not really find many posts on dev.to about Flow, but feel free to check out the flowtype tag.
Take Flow for a spin in the Flow REPL
Other Options
I've narrowed it down to TypeScript and Flow as they are the most popular, but feel free to bring others to the table to discuss, e.g. Elm, Reason. (Thanks for chiming in on Twitter @magellol!)
Vanilla JS🍦
If you really don't want to see the codebase converted to use types, that's OK too.
Are static types something that would interest people in the dev.to community who are contributing to or are thinking about contributing to the frontend codebase? Feel free to discuss in the comments here and/or jump on over to the GitHub issue and comment there.
Top comments (10)
I read the GitHub issue all over again and I have some observations and questions (mostly questions :D)
What you propose would be a rewrite or something like "from this day forward all the new client code will be written with TS/Flow" ?
What happens to third party libraries that do not provide types or support for TS or Flow? Can they be used? Will they require the user to define all the unspecified types?
I really like the idea of using Visual Studio code's "ts-check", it could be a starting point helping to cleanup the code and migrate the code that's not on ES2015+ to it before one commits to TS or Flow.
Would Flow be less of an on/off switch transition? Would the path JS + ts-check -> JS + Flow -> TypeScript make sense?
At one point in the issue you say
The opposite could also happen: people willing to "casually" contribute (especially beginners who might not be knowledgeable of TS) might be deterred because TS is another whole of tools and syntax to learn because it's a separate language. We'll never know, which is probably a reason not to use this as a deciding factor after all :D
Currently the frontend code requires knowledge of ES5/ES2015+ and Preact at least. TS or Flow will help in having a more robust code base which is a great point in itself.
I left more questions than answers, sorry :D
Agreed that "the pique devs interest" shouldn't be a deciding factor. That was just a side note.
You can enable TypeScript (TS) and all existing JS is considered valid in TS. From there you can incrementally add types. If we went the TypeScript route, I would probably promote TS with Babel since this is the easiest way to get started when migrating an existing codebase. Perhaps longterm the TypeScript compiler could be used. As far as I know there are only two things you can't do with the babel preset for TypeScript. const enums and the use of namespaces.
In regards to Flow, JS is valid there as well and types could be incrementally added that way as well.
3rd party libraries that are written in TypeScript do not have this issue as they ship (or should be shipping with their types). For everything else, there is a project called DefinitelyTyped.
The repository for high quality TypeScript type definitions.
DefinitelyTyped
Also see the definitelytyped.org website, although information in this README is more up-to-date.
You can also read this README in Spanish, Korean, and Russian!
Current status
This section tracks the health of the repository and publishing process It may be helpful for contributors experiencing any issues with their PRs and packages.
If anything here seems wrong, or any of the above are failing, please raise an issue in the DefinitelyTyped Gitter channel.
What are declaration files?
See the TypeScript handbook.
How do I get them?
npm
This is the preferred method. This is only available for TypeScript 2.0+ users. For example:
The types should then be automatically included by the…
This is the repo that allows you to install types via npm, e.g.
npm install @types/axios-case-converter. Most 3rd party libraries have types for them thanks to the TypeScript community.For everything else, you can add types in your project for a 3rd party library, if necessary. Even better, put a PR up to DefinitelyTyped 😉
In regards to Flow they have 3rd party types as well via the flow-typed project, but not as many as TypeScript.
A central repository for Flow library definitions
flow-typedis a repository of third-party library interface definitions for use with Flow.You can grab definitions directly from this GitHub repo, or you can use the CLI (currently in beta) to install a libdef for a given library:
Huh?
When you start a project with Flow, you likely want to use some third-party libraries that were not written with Flow. By default, Flow will just ignore these libraries leaving them untyped. As a result, Flow can't give errors if you accidentally mis-use the library (nor will it be able to auto-complete the library).
To address this, Flow supports library definitions which allow you to describe the interface of a module or library separate from the implementation of that module/library.
The
flow-typedrepo is a collection…I imagine the same thing can be done in Flow where if necessary, you can write types in your app that are missing for 3rd party apps. For all the Flow experts out there, please chime in.
👍 if people are using VS Code. If not, I don't think this works.
Not sure I understand the question. Do you mean is it less invasive than TypeScript?
If the transition would be more gradual
They'd be the same in term of doing things gradually.
BTW thanks for the explanations :)
I read this post, largely agreed with it, but wanted to give this some thought.
I feel like my role needs to be that of allowing progress to happen while trying to re-enforce core values. My biggest opinion on frontend to this point has been to try to time the technology appropriately. I just haven't wanted to be on the front of too many waves even if they are great choices in and of themselves.
I'm probably down with this, and I feel like this could be a fairly community-led initiative. Me and the rest of the team just have to come up with a good shared understanding of the path forward.
We still have a whole bundle of JS that is definitely "legacy" at this point. So overdue to be made modern, so a pretty decent time to put some work into all of this, add better testing and make things more concrete on the frontend in general.
All of these arguments are the same ones I made at work last year, and our projects will be in TypeScript moving forward. I can't tell you how many times I've looked at a library for the first time and used the supplied type definitions to really find my way around. Of course, for us the deciding factor was my demo of TypeScript vs PropTypes. I recently saw someone mention on twitter that props have intellisense with PropTypes, but that's not something I've experienced. 🤷
Glad to hear your moving to TypeScript. Not sure about intellisense with prop types, but even if it did work, that only covers props in React, not the rest of your codebase.
My bias comes from starting with Angular, but I've used it for simple projects, too. I feel like I tell this story all the time. Is VanillaTS a thing now?
I started with TypeScript (TS) using a custom front-end library light years ago (late fall 2014). At that time VS Code did not support extensions! Crazy times. After that all my professional TS experience was/is in Node/React. YOLO