News for hackers. Stuff that matters.
Re:The broken promise of Web Components by kbenson on Wednesday March 15, 2017 @07:50PM (#13881038)
> Yes, it's like with JavaScript itself, it had some issues in the past, all the big issues were resolved but the stigma is still there.

Honest question, because I use Javascript just infrequently enough to have to look this up every time (and it's possible the reported solutions are old), is there a good concise universal way (or two, at most) to determine the type of the variable I may have? It seems it's always a tossup between typeof, instanceof, == null and == undefined, and to my eyes that's way too many.

Re:The broken promise of Web Components by jdmichal on Thursday March 16, 2017 @03:19PM (#13888199)
As far as I know, `typeof` works on everything, but for Objects will only yield "object". You then should use `instanceof` to determine the type of object, if necessary. Typically, once I know it's an object I just use it, so that people can provide "non-traditional" but otherwise valid implementations. Only exception is if I'm specifically looking for a Date or DOM Node or other built-in type.

EDIT: Of course, I forget that arrays also have `typeof` "object"... Again, probably best to just start using length and indexing and hope for the best.

Re:The broken promise of Web Components by comex on Wednesday March 15, 2017 @08:50PM (#13881390)
A somewhat more succinct option could be to coerce to Object and then use instanceof: 'Object(x) instanceof String'. Or you could use Object.getPrototypeOf, which coerces to Object automatically these days. But null and undefined are special: calling Object on them returns {}, and calling Object.getPrototypeOf on them throws.

If the type you're testing for is not one of the builtin literal types, you can just use instanceof.

Re:The broken promise of Web Components by kbenson on Thursday March 16, 2017 @04:34PM (#13888923)
"Object(foo) instanceof Class" does seem to be the most definitive, but unfortunately seems to require specific testing against a literal that must exist or it throws, and doesn't work for null/undefined. That at least brings the things I need to know to check the type of something down to three, two of which are singular special cases (if somewhat common ones), so that's better and possibly adequate, if not what I would consider good. Then again, I'm not sure I'm capable of thinking it could achieve good while there exists both an undefined and null in the language. It still boggles my mind that it has both.
Re:The broken promise of Web Components by comex on Thursday March 16, 2017 @05:48PM (#13889522)
To clarify, by "literal that must exist or it throws" you mean that you don't know whether the class you're testing for exists? Testing against an invalid class would be an error in most languages…

I guess an alternative is foo.constructor and foo.constructor.name, which will give you a string if you want that.

Re:The broken promise of Web Components by kbenson on Friday March 17, 2017 @04:24AM (#13892403)
Since many different js libraries may be loaded from many different sources, I could envision a situation where some utility functions may want to support different inputs depending on what's passed in, and what's passed in might depend on what's loaded, and what's loaded can change at runtime.

That's why many dynamic languages allow access to the type through a string representation.

Re:The broken promise of Web Components by Roboprog on Thursday March 16, 2017 @11:55AM (#13886054)
Not really. Also, typeof doesn't work at all on object literals.

Best just to see if it quacks, or barks :-)

(i.e. - does the object define a given function/"method")