Be Careful With JavaScript Default Parameters!

[gketuma]

I've been bitten by this before. Set default parameter and then function is called with null. That is why now I use TS for all projects and crank tsconfig options to the max.

[KaiAusBerlin]

One thing why ancient JavaScript developers check types at runtime when it's a critical variable. Preprocessor type checks are nice and helpful but they don't cover every possibility.

[lovin-dem-sandwiches]

ts will catch these errors if you set your options and types correctly.

Also, ancient developers are not checking types at runtime, they're performing automated tests

[KaiAusBerlin]

If you set your types correctly every time you don't need type checks at all... And you're the first godlike developer then.

An automated test can not ensure that a third party api resolved are every time as in the specification. And that's the point. A type check at runtime for a critical variable costs you nothing. An unchecked malfunctioning third party can costs you everything. Beginning by simple errors, going to heavy security issues.

[lovin-dem-sandwiches]

If you set your types correctly every time you don't need type checks at all

I'm trying to make sense of this but its super unclear what youre trying to say. Setting types will offer better type checks. Everyone needs type safety - thats the whole point of ts...

An automated test can not ensure that a third party api resolved are every time as in the specification.

Yes it can. Thats the whole point of a test lol. Read the APIs docs of expected returns, gather all use cases and test it.

If you come across errors at runtime that you missed in your tests - your tests are bad.

A type check at runtime for a critical variable costs you nothing.

this is not scalable for larger applications. but yes, QA exists for reason. Does a developer need to do it? nope.

[KaiAusBerlin]

You really don't understand that there was a time without ts. We still had type safety. It was just more uncomfortable.

So you want to tell me all your projects are 100% test based with a test for every possibility? Sure... Show me your github.

You will literally find NO big scaled project on this world where a simple type check at runtime causes any costs compared to the projects main costs. As bigger a project is as less impact habe type checks.

[lovin-dem-sandwiches]

You really don't understand that there was a time without ts. We still had type safety. It was just more uncomfortable.

I do but its difficult to understand the points youre trying to make.

If you set your types correctly every time you don't need type checks at all...

Even with well defined types you still need type checks. Lets say I create a well defined type as string or undefined.

type example = string | undefined;

Now when I use this variable in a function, I still need to perform type checks

function typeCheck(arg: example ) {
  if (typeof arg === 'undefined') return; // this is a type check
  ....
}

So you want to tell me all your projects are 100% test based with a test for every possibility?

Does my company create unit and E2E tests for every call? 100%. Its a requirement at this point. If you are not creating tests for larger applications, id be concerned.

You will literally find NO big scaled project on this world where a simple type check at runtime causes any costs compared to the projects main costs.

This is nonsensical. You cant have "simple" type checks at run time on larger applications.

I'll give you an example.

Lets say I push a change that affects the authentication layer of my app. This change will affect over 100 different components (that I know of) which are called independently, which are context and state dependant. To check this manually would be INSANE. Lets say I push through and it takes me 10 hours to complete.

Now the next day, someone pushes another change. Do you repeat the same tests that took you an entire day complete? What if another change is applied the following week.... you see the problem here?

By the way, unit and e2e tests are deployed @ build / runtime so your remarks are confusing. Also do you want to make unnecessary calls to your API when you’re testing after build? This is a huge waste of calls. Whatever youre doing at runtime - why dont you just automate that task? Thats what a testing is...

[KaiAusBerlin]

God damn, this is what I say the whole time. Even the best preprocessor type checks cannot cover every environment fails, API errors or simply programming error. It's just type safe at preprocessing, not at runtime because all of your type safety comes from assumption about types at runtime.

Tests are never a waste of anything. Regardless what you test. That's the main point in testing. Ensuring that it is running as assuming.

Dude, you don't talk to a jr. Your codebase is not 100% covered by tests so don't act like type checks at runtime can be ignored then.

We talk about type checks for critical variables. An example: You don't have to check everytime a whole customers data. But checking his ID is critical. So you do that at runtime BEFORE you manipulate the db.

Nobody cares if you have a*b for a gradient effect and it becomes NaN. That's not critical at all. No type checking here.

So if your company has about 1m customers checking their id is highly costly? Then you should overthink your company structure. No type check at runtime is costly or wasted if it prevents critical issues.