Sorry, what I was trying to say is why isnt there an option to infer all types across module boundaries?
For me it is exactly what you would expect it to look like : https://github.com/alm-tools/alm/blob/c667da03cd4f02bf68c7f07bf0b5c5417efbd5cd/src/app/components/buttons.tsx#L37-L40
I dont get your point. Have you tried flow? it doesnt feel like a new language, it just adds type annotations.
That is also the reason I prefer flow above typescript. It just compiles away in production. It doesnt compile into something else.
we actually always extract the props type for each component (usually even function components) to a separate interface. Mainly because it is great documentation (components are shared among many teams), but you can also easily extend other proptypes from thereon (or
React.Props<any> to allow the predefined react properties). In the end it is pretty similar to specifying propTypes, a little less verbose maybe.
Type inference is great for legacy code and for small functions and clear assignments it’s sufficient.
But in more complex cases, I really like explicit type annotations. They help from the first minute, even when …
When you’re trying to hack something together for the first time you don’t want to spend half your time (or more) fixing up every error just so your code compiles and you can try it out.
I never add type annotations afterwards. IMO typings provide even faster feedback and are more effective finding errors than most unit-tests. And it helps to understand code (yours and that of your fellows). I don’t have the feeling that adding type annotations costs any time at all, because it pays off immediately.
I don’t even know how I would survive in a ES5/ES6/react world without typescript, specially for projects that involve more than 2 developers. I am on my 4th react project by now, and since the 2nd project I have been using typescript and haven’t looked back in any way. Things like
- Refactoring … something as simple as changing the name of a class member or a variable
- Sharing/understanding code with peers … how can I know what a function takes as a parameter, which class members are optional and which are not, etc.
- Understanding how the specifics of a third-party library works … I usually look into type definitions (.d.ts files) of my dependencies for answers
- Catching typo (mis-spelt property, class, variable names) errors compile time (though tests exist)
I can’t live without.
This is a healthy discussion. This is a more recent discussion on TypeScript vs Babel, which to use and why. Let us know what you think:
React is an important project of Facebook, so FB engineers don’t want to be depended on a Microsoft’s project (TypeScript). Furthermore, they are smart folks that have a lot of funding to spare, so they want to invent better tools for their development purposes.
Unlike FB engineers, we don’t have that luxury. We could rely on whatever open source projects if we would like, Google/FB/Microsoft is ok for us. In my last year’s research for choosing FlowType or TypeScript, I tried to favor FlowType, but in the end… TypeScript is the right tool for my job.
Reason is the future of Facebook’s projects. Again, that’s why FB engineers don’t want to fully “support” TypeScript for their top project.
ReactJS Training in Hyderabad
Writing Flow in JS would have allow:
- To use Flow against Flow source code (eating your own dog food)
- Attract contributors: nobody writes OCaml code (specially in the JS community)
- Fix Windows support/perf issues has you mentioned
Writing Flow in OCaml is a non-sense That’s probably why TypeScript is thriving and Flow is not being used outside Facebook.
This reply seems one-sided and incomplete. I understand that probably your focus has been mostly on Flow, but you must be for sure aware of the problems it has. Try to check out the other comments in support of TS, maybe you’ll refresh/improve your TS knowledge
Disclaimer: I work at Microsoft in a team using React/TS/Babel/Webpack.
I think that for 99% of the cases, TS and Flow will both meet your needs in terms of language features. Both are being designed by very talented people and are in good hands (at least of TS side, the team handling TS dev has very strong roots in c# design).
The reasons I would pick TS are:
- great productivity tools and integration
- great cross-plat performance
- abundance of resources, both in docs and from the community
- stellar community support for libraries and package typings (I’d like to underline this 5 times to showcase how important it is)
TypeScript is dominating outside of React IMOP. I build all my repos pretty much with TS now.
I hope to see more TS inside of react as I find most of the jobs in London focused on React.
So much this. Flow breaks all the time on windows and it is not a recent project. I love the theory of flow but sadly it is not a realiable option (at least windows users)
Similar thing with this argument, “Is Unit Testing good or bad?”. So the answer is it depends on your client or your boss. If your boss wants a rush project, go with Flow. If not, use TypeScript.
When you say “whatever works for you,” does that mean I can stick with normal JS?
I like the libraries, but I hate the transcompiler languages like TypeScript. Is it big enough for me to have to work with it, or can I ignore it and still make decent money?