4 ms·

How are you conscious of types without any tooling? And if you use tooling, then what's the difference?

rglover 5y ago
When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it. For example, JavaScript default args are really helpful for avoiding type errors: const nameString = (name = {}) => { return `${name.first} ${name.last}`; }; Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).
- imbnwa 5y ago
  Not to mention the Typescript parser can be configured to parse JSDoc comments for compiling an index.d.ts file for external users if need be
- jmondi 5y ago
  basically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.
  - deleted 5y ago
    [deleted]
  - rglover 5y ago
    Yes? And I understand why you want to use it, I'm just saying that it's not always necessary (i.e., some of the dogma around it is unwarranted).
- yuretz 5y ago
  > I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.
  - rglover 5y ago
    IMO, same thing. If I see that, I'm going to know what to fix. Still not a sell that I need to add in TypeScript. I get the why, but it's often overkill.
- mattlondon 5y ago
  ...or just use typescript and get red squiggles in your IDE (...or when compiling if not using and IDE) and you don't have to go manually check your UI or write a unit test to make sure you provided the right type. Your approach sounds totally unscalable beyond a small project to me - you can't go manually eye ball your entire UI on every change. Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor
- manigandham 5y ago
  So you do it manually? That's exactly what Typescript was created for, to use tooling and automation to handle these and it's been repeatedly proven to reduce bugs and increase productivity because of it. Using typescript is very progressive, you can add types line by line if you want. There's not much setup really other than using TSC to compile the files.

When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it. For example, JavaScript default args are really helpful for avoiding type errors: const nameString = (name = {}) => { return `${name.first} ${name.last}`; }; Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).

imbnwa 5y ago
Not to mention the Typescript parser can be configured to parse JSDoc comments for compiling an index.d.ts file for external users if need be
jmondi 5y ago
basically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.
- deleted 5y ago
  [deleted]
- rglover 5y ago
  Yes? And I understand why you want to use it, I'm just saying that it's not always necessary (i.e., some of the dogma around it is unwarranted).
yuretz 5y ago
> I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.
- rglover 5y ago
  IMO, same thing. If I see that, I'm going to know what to fix. Still not a sell that I need to add in TypeScript. I get the why, but it's often overkill.
mattlondon 5y ago
...or just use typescript and get red squiggles in your IDE (...or when compiling if not using and IDE) and you don't have to go manually check your UI or write a unit test to make sure you provided the right type. Your approach sounds totally unscalable beyond a small project to me - you can't go manually eye ball your entire UI on every change. Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor
manigandham 5y ago
So you do it manually? That's exactly what Typescript was created for, to use tooling and automation to handle these and it's been repeatedly proven to reduce bugs and increase productivity because of it. Using typescript is very progressive, you can add types line by line if you want. There's not much setup really other than using TSC to compile the files.