I'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...
The thing is that there is the Promise "class", which is provided by the environment, but there is a interface called PromiseLike, which is defined as having a method called then that takes one or two functions. Now, JS doesn't have nominal typing for interfaces, so you have to do "random property checks".
Typescript partially solves that by declaring types, but if you have a any variable, you still need to do some probing to be able to safely convert it to a PromiseLike, because TypeScript goes to great lengths to not actually produce physical code on its output, attempting to be just a type checker.
Perhaps if TS or an extension allowed "materializing" TS, that is `value instanceof SomeInterface` generated code to check for the existence of appropriate interface members, this could be avoided, but alas, this is not the case.
shouldn't it then be called is-promise-like? Also, if you're being loose about it anyways, can't you simply just go for `if (obj && typeof obj.then == 'function')` and call it a day? I'd say that's short enough to include your own version and not rely on a package for.
I think that module over complicates it as it is, and most people don't need that level of complication in their code.
> Perhaps if TS or an extension allowed "materializing" TS, that is `value instanceof SomeInterface` generated code to check for the existence of appropriate interface members, this could be avoided
It's not perfect and a bit of a bolt-on, but io.ts works reasonably well in this area:
In 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.
Promises were not always part of the standard and for many years were implemented in user space, by many different implementations. Using duck typing like this was the only way to allow packages to interact with each other, as requiring an entire stack to say only use Bluebird promises is not realistic at all.
kroltan|5 years ago
Typescript partially solves that by declaring types, but if you have a any variable, you still need to do some probing to be able to safely convert it to a PromiseLike, because TypeScript goes to great lengths to not actually produce physical code on its output, attempting to be just a type checker.
Perhaps if TS or an extension allowed "materializing" TS, that is `value instanceof SomeInterface` generated code to check for the existence of appropriate interface members, this could be avoided, but alas, this is not the case.
ehsankia|5 years ago
I think that module over complicates it as it is, and most people don't need that level of complication in their code.
zbentley|5 years ago
It's not perfect and a bit of a bolt-on, but io.ts works reasonably well in this area:
https://github.com/gcanti/io-ts
odensc|5 years ago
exogen|5 years ago
city41|5 years ago
staticassertion|5 years ago