5 ms·
What would be the downsides of TypeScript, from your perspective? In a large codebase, having typings, even basic ones, go a long way. I don't know about the
by tony 7y ago
What would be the downsides of TypeScript, from your perspective?
In a large codebase, having typings, even basic ones, go a long way.
I don't know about the term static typing or if that's what really helps. I also annotate for readabilities sake. For instance, it's nice to know a variable in python is only intended to be 'ACTIVE' or 'INACTIVE':
from typing_extensions import Literal
ActivityStateLiteral = Literal['ACTIVE', 'INACTIVE']
# Lower in the code, e.g. inside a flask view
activity_state = ActivityStateLiteral = request.GET.get('activityState')
For TypeScript:
type ActivityStateLiteral = 'ACTIVE' | 'INACTIVE'
// e.g. react component
const activityState: ActivityStateLiteral = props.activityState || 'ACTIVE'
That leaves me no doubt when I/a team member comes back 3/6 months later that I'm only dealing with 2 possibilities of what that variable can be (or should be). The intention itself also valuable, even if incorrect.
- benatkin 7y agoFor your example, I would prefer a variable called active that can be true or false (True or False in python). This is just an example but I see stuff like this in statically typed projects, where integer enums are used when a string will suffice, and strings are used where booleans will suffice. If I wasn't aware of valid values, I might search my codebase for uses of it. Usually if something is being set to true or false, it's a variable that can be true or false, or true, false, or empty (None in python, null or undefined in JavaScript).
- ajxs 7y ago"I see stuff like this in statically typed projects, where integer enums are used when a string will suffice, and strings are used where booleans will suffice." Typescript has proper enumerated types, so you really shouldn't be using either? Using magic number values for an enum is even poor programming practice in C. You've already listed one reason why you'd use a proper enumerated type over boolean, the fact that NULL is not part of the type's domain. The other big reason is that it is semantically correct. You can limit the type's domain to only values that make sense semantically. No more comments like: // A value of '1' means the missile is armed.
- benatkin 7y agoI'm aware of this capability in TypeScript, which is why I specified integer enums instead of just calling it an enum. However, integer enums are still an option, and with TypeScript it would be easy to use an integer as a micro-optimization, which could be a pain if JSON gets exported and the person looking at it doesn't know what the numbers mean.
- ajxs 7y agoAh, I thought you were referring to an integer taking the place of an enum, which is a terrible practice that for some reason is more common than you'd think. I'm not too sure what you mean by 'micro-optimization' here, these kind of languages are so high level that the term 'optimisation' really doesn't apply. Regarding the JSON serialisation point: The internal representation of an enumerated type would probably depend on the needs of its serialisation medium. If it's going in a binary file, then an integer is probably your best bet. If it's going into a database, you might not have that limitation. This all depends on the scenario. As long as you're referencing the enum by its proper handle, that is.
- benatkin 7y agoI was thinking of it as a storage optimization. "inactive" is going to take more storage than the number 2, both serialized and deserialized. Might seem like a bigger deal than the difference in CPU usage.
- spiralx 7y agoIf you use a const enum in TypeScript it gets transpiled down to just the plain integer or string without any additional overhead. It just means you can't use a variable to get a value from the enum e.g. State[ currentState ] - which I'm not sure is a good pattern to use anyway.