5 ms·

TypeScript is fine. I used it for about half a year when wokring on an Angular app. But for new projects with React now I seldom see the need to include it. Su

by erokar 8y ago

TypeScript is fine. I used it for about half a year when wokring on an Angular app. But for new projects with React now I seldom see the need to include it. Sure, TS gives you a little bit better autocompletion in VS Code, you can document your function signatures a little bit better and you can catch a few trivial type errors — but it also has some costs: Extra set up, extra build steps, the need to also import type definitions when including a library, cluttering the code with interfaces and type definitions. I find the extra value it gives over PropTypes in React is pretty low. And while types in function signatures arguably increase understanding, elaborate interface definitions, sometimes in their owen files with the need to import them, can clutter up the code and be a detriment to readability. Also, VS Code's auto completion is very good even without TS.

erokar 8y ago
^ I knew this would get downvoted, but it would be nice to see some arguments as to why people think the benefits of TS outweigh the costs.
- vosper 8y ago
  As a React developer who hasn't used TypeScript yet, I think of PropTypes as a pretty weak alternative to proper static types. 1. You have to manually keep the PropTypes in sync with the type of props actually being passed to the function. But nothing makes you do that, and it's pretty easy to neglect them - your editor's not going to complain (at least, WebStorm doesn't) so the first you'll see of a mismatch is if you happen to get an error (not really an error, it doesn't stop your code from running) in the browser or in your tests. 2. They don't actually enforce anything. Sure, React will complain about a prop type mismatch when you call the function, but your code will still run, and then it's up to you to figure out whether the PropType definition is wrong, or whether the prop itself is wrong. Maybe only one usage of the component is passing in the wrong prop type, maybe only under a specific set of conditions, and it's easy enough to miss that in tests (your test data matches the PropType, but your actual API data that ends up being a prop doesn't match the PropType - eg your PropType is a number but the API returns a string and you didn't convert it to a number, now you have a error-warning in production. That's your fault, sure, but you get no help with it from the tooling). 3. They're not very expressive. eg I can't define the shape of an object being passed into my component, I can only tell React that it's some object. 4. PropTypes only work at the boundaries of components. What about my functions inside the components? Or my helper functions that aren't part of a component at all? PropTypes do nothing to help me be sure I'm passing the right data to those.
  - erokar 8y ago
    These are good points. A agree that PropTypes are neither as expressive/spesific nor as strict as using e.g. an interface with TS. I still think they are often good enough. You are also correct to point out PropTypes offer no way of adding typing to component or utility functions. I've seldom seen errors arise from the lack of typing here, and if they do you'll usually discover them at runtime. However types as added documentation of function signatures would be nice.
  - liamdanielduffy 8y ago
    Regarding 3, you actually can use PropTypes to define the shape of an object passed as a prop using PropTypes.shape({...})! You can also specify the types of all of the keys of the object. I find this super useful in many of my projects, I hope it helps with some of yours! https://reactjs.org/docs/typechecking-with-proptypes.html https://reactjs.org/docs/typechecking-with-proptypes.html
  - tym0 8y ago
    You're making some good points and I feel ambivalent about prop types however I wanted give a few solutions to some of the things you said. You can use eslint to enforce the use of prop types, it'll read through your code and will give you a warning if you are using a prop without a corresponding prop types declaration, the rule is called react/prop-types You can us PropTypes.shape and PropTypes.exact to define the shape of props that are objects, see https://www.npmjs.com/package/prop-types https://www.npmjs.com/package/prop-types
- alangpierce 8y ago
  I think your points are some of the best reasons to avoid TypeScript, but I still definitely prefer TypeScript. I think I just find the disadvantages less cumbersome and the advantages more compelling. Even though editors can give reasonable autocomplete for JS these days, I think there's a certain amount of trust and comfort that you lose, and I find it really nice to have little mistakes flagged right as I'm typing rather than when running the code (even when I have a fast iteration cycle). I also greatly prefer TypeScript when trying to use code I've never seen before, whether that's code written by someone else on my team or third-party code. The types add an extra layer of explanation that's hard to convey in docs or function/variable names. And as discussed separately, PropTypes is much better than nothing, but I think it has plenty of gaps, and I feel much more confident and comfortable in a codebase with full typechecking. (I didn't downvote; I upvoted you since I think your post is a good contribution to the discussion.)
MBCook 8y ago
I thought PropTypes was being phased out?
- erokar 8y ago
  I'm not aware of that. In any case they still work fine in React v16.
  - MBCook 8y ago
    That was an impression I’ve gotten. I’m not sure if it’s true.
    - acemarke 8y ago
      PropTypes aren't being phased out, but they were moved to a separate package since the actual implementation isn't React-specific.
pferdone 8y ago
Static vs dynamic typing aka catching type errors on compile and not on runtime. Easily refactor code and all references there of. I would also say that I‘m faster using TypeScript BECAUSE of autocompletion, implicit code documentation through types, etc. The cost you listed are solved during the setup of a project. I can just talk for myself, but I started a project at work and pushed for TypeScript. We now have automatically generated Swagger-clients fully typed, with a GraphQL layer infront of it with generated types for queries. Basically everything is typed now and I don‘t have to test or check incomming data or guess what kind of object I have to expect from our backend. The tooling is so good now, that the benefits outweigh any setup hassle you have upfront IMHO.
- erokar 8y ago
  Good points. I'm not against using TS, I just think the it should be aknwoledged that it does have costs. The nice thing about TS is that once included you can use it as much or as little as you like (for function signatures only, for instance). I also think project scope and team size is important -- the larger these are, the more I would consider TS.
- Bizarro 8y ago
  I used Typescript for years and found that the costs didn't outweigh the benefits for us. It slowed us down tremendously.

by erokar 8y ago

erokar 8y ago

^ I knew this would get downvoted, but it would be nice to see some arguments as to why people think the benefits of TS outweigh the costs.

vosper 8y ago
As a React developer who hasn't used TypeScript yet, I think of PropTypes as a pretty weak alternative to proper static types. 1. You have to manually keep the PropTypes in sync with the type of props actually being passed to the function. But nothing makes you do that, and it's pretty easy to neglect them - your editor's not going to complain (at least, WebStorm doesn't) so the first you'll see of a mismatch is if you happen to get an error (not really an error, it doesn't stop your code from running) in the browser or in your tests. 2. They don't actually enforce anything. Sure, React will complain about a prop type mismatch when you call the function, but your code will still run, and then it's up to you to figure out whether the PropType definition is wrong, or whether the prop itself is wrong. Maybe only one usage of the component is passing in the wrong prop type, maybe only under a specific set of conditions, and it's easy enough to miss that in tests (your test data matches the PropType, but your actual API data that ends up being a prop doesn't match the PropType - eg your PropType is a number but the API returns a string and you didn't convert it to a number, now you have a error-warning in production. That's your fault, sure, but you get no help with it from the tooling). 3. They're not very expressive. eg I can't define the shape of an object being passed into my component, I can only tell React that it's some object. 4. PropTypes only work at the boundaries of components. What about my functions inside the components? Or my helper functions that aren't part of a component at all? PropTypes do nothing to help me be sure I'm passing the right data to those.
- erokar 8y ago
  These are good points. A agree that PropTypes are neither as expressive/spesific nor as strict as using e.g. an interface with TS. I still think they are often good enough. You are also correct to point out PropTypes offer no way of adding typing to component or utility functions. I've seldom seen errors arise from the lack of typing here, and if they do you'll usually discover them at runtime. However types as added documentation of function signatures would be nice.
- liamdanielduffy 8y ago
  Regarding 3, you actually can use PropTypes to define the shape of an object passed as a prop using PropTypes.shape({...})! You can also specify the types of all of the keys of the object. I find this super useful in many of my projects, I hope it helps with some of yours! https://reactjs.org/docs/typechecking-with-proptypes.html https://reactjs.org/docs/typechecking-with-proptypes.html
- tym0 8y ago
  You're making some good points and I feel ambivalent about prop types however I wanted give a few solutions to some of the things you said. You can use eslint to enforce the use of prop types, it'll read through your code and will give you a warning if you are using a prop without a corresponding prop types declaration, the rule is called react/prop-types You can us PropTypes.shape and PropTypes.exact to define the shape of props that are objects, see https://www.npmjs.com/package/prop-types https://www.npmjs.com/package/prop-types
alangpierce 8y ago
I think your points are some of the best reasons to avoid TypeScript, but I still definitely prefer TypeScript. I think I just find the disadvantages less cumbersome and the advantages more compelling. Even though editors can give reasonable autocomplete for JS these days, I think there's a certain amount of trust and comfort that you lose, and I find it really nice to have little mistakes flagged right as I'm typing rather than when running the code (even when I have a fast iteration cycle). I also greatly prefer TypeScript when trying to use code I've never seen before, whether that's code written by someone else on my team or third-party code. The types add an extra layer of explanation that's hard to convey in docs or function/variable names. And as discussed separately, PropTypes is much better than nothing, but I think it has plenty of gaps, and I feel much more confident and comfortable in a codebase with full typechecking. (I didn't downvote; I upvoted you since I think your post is a good contribution to the discussion.)

MBCook 8y ago

I thought PropTypes was being phased out?

erokar 8y ago
I'm not aware of that. In any case they still work fine in React v16.
- MBCook 8y ago
  That was an impression I’ve gotten. I’m not sure if it’s true.
  - acemarke 8y ago
    PropTypes aren't being phased out, but they were moved to a separate package since the actual implementation isn't React-specific.

pferdone 8y ago

Static vs dynamic typing aka catching type errors on compile and not on runtime. Easily refactor code and all references there of. I would also say that I‘m faster using TypeScript BECAUSE of autocompletion, implicit code documentation through types, etc. The cost you listed are solved during the setup of a project. I can just talk for myself, but I started a project at work and pushed for TypeScript. We now have automatically generated Swagger-clients fully typed, with a GraphQL layer infront of it with generated types for queries. Basically everything is typed now and I don‘t have to test or check incomming data or guess what kind of object I have to expect from our backend. The tooling is so good now, that the benefits outweigh any setup hassle you have upfront IMHO.

erokar 8y ago
Good points. I'm not against using TS, I just think the it should be aknwoledged that it does have costs. The nice thing about TS is that once included you can use it as much or as little as you like (for function signatures only, for instance). I also think project scope and team size is important -- the larger these are, the more I would consider TS.
Bizarro 8y ago
I used Typescript for years and found that the costs didn't outweigh the benefits for us. It slowed us down tremendously.