6 ms·
Well, let's see var mostRecent = ''; if (type(c.messages) === 'array' || type(c.messages[0]) === 'object' || type(c.messages[0].text)
by marijn 13y ago
Well, let's see
var mostRecent = '';
if (type(c.messages) === 'array' ||
type(c.messages[0]) === 'object' ||
type(c.messages[0].text) === 'string') {
mostRecent = c.messages[0].text.substring(0, 30);
}
return name + ': ' + mostRecent;
.. apart from the fact that he probably meant && instead of || in that condition, we've also now got a system that silently swallows errors. Bugs can lurk in it without any more symptoms than producing empty strings where more interesting strings were expected.
I much prefer my systems to crash when a programmer made an error, and do so noisily and detectably, so that the problem can be fixed. I also prefer the actual logic of my code to make up more than 20% of the lines. If you're going to add boilerplate type checks all over, the signal-to-noise ratio gets really bad.
So don't do this. Use Typescript if you want to check types.
- annnnd 13y agoAgree with you 100%. One could use this system for asserts though: assert(type.isObject({}))); assert(type.isNumber(NaN)); // fails assert(type.isElement(document.createElement('div'))); assert(type.isRegExp(/abc/); This could increase readability (because it documents the data type expectations) and would also break on some errors as soon as possible.
- ghiculescu 13y agoIt's still a lot of code being run without real benefit. Use Typescript if you really want static types, write sufficient unit tests either way, and you don't need this.
- rimo 13y agoStatic types and unit tests don't solve or catch all problems. I'm thinking about event-driven messaging systems, which is pretty common in js; Static typing will not be of any help in that situation.
- embwbam 13y agoYou can use a different observer pattern sometimes that can be caught by static typing, like Signals
- danbruc 13y agoSufficiently advanced type systems can enforce an enormous range of constraints. You can for example create a type for trees enforcing that the tree must be balanced; code that would unbalance a tree will just not compile.
- annnnd 13y agoSure - and you can test types in your unit tests using the OP's technique. :)
- jonbretman 13y agoFirstly good spot on the '||' instead of an '&&'. Will fix that now. Secondly I completely agree about wanting a program to crash noisily and detectably in development, but in production I would prefer that the error is handled and the user can continue to use the app. Finally I also agree that if type checking is really important to you, a compile to JS language like TypeScript or Dart are the best options. The techniques / approach I am discussing in this article are really for people who already have a large vanilla JS code base or want to learn a bit more about types in JavaScript.
- vladiliescu 13y agoJust wanted to add that TypeScript is backwards compatible with JS, so having a large vanilla JS code base doesn't really matter - it's already valid TypeScript code, so you can go and start adding type annotations and whatnot.
- hrjet 13y agoTypescript is a superset of Javascript. So any vanilla JS code base can be easily ported to Typescript.
- nfoz 13y ago> in production I would prefer that the error is handled and the user can continue to use the app. Maybe that's ok if it's a game or something, but this is a dangerous strategy. How do you know it's ok to use the app if there's an error? You have to very carefully isolate and control where your errors can be, and I'm not sure this approach allows you to do that.
- spion 13y agoTypescript has its own issues: interface IA { } interface IB { foo(): void; } function fn(passedFn: (a: IA) => void) { passedFn({}); } // compiles but throws TypeError at runtime! fn((b: IB) => b.foo());