4 ms·
And the source code of the library is: function isPromise(obj) { return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.t
by chvid 7y ago
And the source code of the library is:
function isPromise(obj) {
return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function';
}
- artursapek 7y agoMy prior decision to never work with JavaScript again has just grown firmer.
- mothsonasloth 7y agoI second this, JavaScript Devs are near the bottom of the food chain, just above VB Devs. Myself as a Java developer is middle of the pyramid. The apex predators are embedded developers, followed by c Devs then game Devs.
- smt88 7y agoIt's not useful, interesting, or accurate to stratify people this way. You have no idea what someone's intelligence level or background is based on their usage of JS or C. I loathe JS, but one of the best devs I know likes it. People's mileage varies. For me personally, there's much more money in easy React products than making games. I'm not a great dev, but I'd be doing this same work even if I were.
- TechBro8615 7y agoThe “food chain?” What do you mean by that?
- deleted 7y ago[deleted]
- gombosg 7y agoI sincerely hope you're being sarcastic here.
- fortran77 7y agoActually VHDL / Verilog programmers are on top of the food chain.
- CydeWeys 7y agoAnd is that reflected by their compensation, or ... ?
- temac 7y agoThey will eat you.
- recursive 7y agoI don't know much about VHDL, but there seems to be a non-scientifically-measured negative correlation between the quality of candidates I've interviewed claiming VHDL experience vs. those without.
- bronson 7y agoAnd the ways you can fund it are here: https://github.com/then/is-promise/blob/master/.github/FUNDING.yml https://github.com/then/is-promise/blob/master/.github/FUNDI...
- staticassertion 7y agoHere's my off-the-cuff take that will not be popular. A function like this should be a package. Or, really, part of standard js, maybe. A) The problem it solves is real. It's dumb, but JS has tons of dumb stuff, so that changes nothing. Sometimes you want to know "is this thing a promise", and that's not trivial (for reasons). B) The problem it solves is not straightforward. If you Google around you'll get people saying "Anything with a .then is a promise' or other different ways of testing it. The code being convoluted shows that. Should this problem be solved elsewhere? Sure, again, JavaScript is bad and no one's on the other side of that argument, but it's what we have. Is "just copy paste a wrong answer from SO and end up with 50 different functions in your codebase to check something" like other languages that make package management hard so much better ? I don't think so.
- degraafc 7y agoI'd say that it should rather be a part of the type system. Some kind of `obj isa Promise` should be the way to do this, not random property checks. But that's JS...
- staticassertion 7y agoI'm totally with you on this. It's dumb that this is a problem but it is actually a problem.
- odensc 7y agoIn theory `x instanceof Promise` would work, but the reason for this package is that there are many non-standard Promise implementations in the JS world.
- 2ion 7y agoWow just wow. So here's your new Promise object: class World { then () { return 0; } } isPromise(new World) // true If there really isn't a safe and better way to tell if an object is an instance of Promise…then color me impressed.
- chrisoverzero 7y agoAccording this this library, maybe. According to the specification, no: https://promisesaplus.com/ https://promisesaplus.com/
- TurplePurtle 7y agoThere are custom Promise implementations (for reasons), such as bluebird.js. If you're supporting legacy browsers, there will be no standard Promise object. So the simplest way to check for the Promise contract is the code posted. But yes, in an ideal world, one would be able to just do `promise instanceof Promise`.
- stagas 7y agoThese cases should really be handled at the compilation/transpilation level, since there is one, and users should just write latest generation JavaScript without these concerns.
- ehsankia 7y agoOr just: const p = {then: () => 0}
- hombre_fatal 7y agoWell, an object with a then() method is a promise. Promise.resolve({then: () => console.log('called')}) Promises autoflatten since you can't have Promise<Promise<T>>, so you'll see that this code prints 'called'.
- throwanem 7y agoI mean, if you have to assume deliberately adversarial action on the part of your own codebase, you may have worse problems than having to duck-type promises.
- jcelerier 7y agohow does that make sense in any universe. Just because I have a function named "then" does not mean that my object is a promise. Maybe "then" is the name of a domain thing in my project, for instance a small DSL or something like that. arghhhhhh !
- krapp 7y agoIt's almost as if treating a dynamically typed interpreted language as if it had static types like C++ is fundamentally broken.
- jhanschoo 7y agoobjects with a .then(...) methods are treated as though they have Promise semantics by the language See Promise.resolve https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- LudwigNagasena 7y agoConsider it a special function like "__init__" in Python. I think this is one of the problems with duck typing, existence of a public function introduces possible name collision onto the whole codebase.
- stagas 7y agoAnd it doesn't even check if it's a Promise. It's violating it's own naming contract. At least it should be called: isPromiseLike? To check if something is actually a Promise all you need to do is a `foo instanceof Promise`.
- exogen 7y agoThat won't work across window boundaries, since each window environment gets its own distinct version of Promise.
- stagas 7y agoThen instanceof will break for all native objects. Who writes code that checks instances across window boundaries? This is flawed beyond the idea of how to properly check an instance, it's bad architecture - the result? This post, and probably more subtle bugs surfacing along the way.
- matt2000 7y agoA nice one line argument for type safety.
- ufo 7y agoDoes anyone know if it really needs the !!obj&& at the start? Isn't that redundant with checking that the type is either "object" or "function"? And is there a reason to use '!!' inside a conditional? Wouldn't obj&& do basically the same thing?
- stefan_ 7y agoIt didn't break because of the source, it broke because of all the packaging/module bullshit around it. It seems the Javascript ec(h)osystem has firmly come down on the philosophy of "make modules very easy to use, but very difficult to make (correctly)". The predictable explosion in dependency trees has caused the predictable problems like this one. I feel I much prefer the C/C++ way of "modules are easy to make, but difficult to use".
- adrianbbarkus 6y agoIrony is there's a simpler way to do it, making the library even less necessary. `const isPromise = x => Promise.resolve(x) === x`