4 ms·

Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times

by exogen 6y ago

Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise false Congrats! Your isPromise function was given a Promise and returned the incorrect result. The library returns the correct result. Try again!

suyjuris 6y ago
In case someone else is also confused by this, it seems that instanceof checks whether the objects prototype matches, and these prototypes are not shared across different contexts, which iframes are [0]. (Though I would still like to know why it works like this.) [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#Description https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- odensc 6y ago
  For security reasons - you can modify the prototypes and you wouldn't want iframes to inherit that.
hombre_fatal 6y ago
Though, let's also appreciate just how niche that case is. I'd be surprised if more than 0.5% of the JS devs reading this will ever encounter that scenario where they are reaching across VMs like that in their life. `obj instanceof Promise` and `typeof obj.then === 'function'` (is-promise) are much different checks. Frankly, I don't think either belongs in a library. You should just write that code yourself and ponder the trade-offs. Do you really just want to check if an object has a then() method or do you want to check its prototype chain?
stagas 6y ago
No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing with multiple windows become a concern of a single layer and not your entire codebase. Implicitly and magically treating a foreign window as this window, will fail in many subtle and unknown ways. The "brokenness" you mention is not in that implementation, it is correctly breaking, telling you that what you are doing is wrong, then you try to bypass the error instead of fixing your approach.
- foepys 6y ago
  GP's comment screams XY problem which seem to be increasingly common these days.
  - exogen 6y ago
    If you think pointing out a bug due to an edge case someone didn't think of is the XY problem, I'm afraid you don't know what the XY problem is.
    - foepys 6y ago
      The problem was to get the promise out of the iframe when you shouldn't do this directly in the first place. This literally is an XY problem: "I need to do A but it's giving me bad results, what do I need to add?" - "Don't use A, it's bad practice. Use B instead and keep using built-in tools instead of hacking something together" In this case use instanceof instead of is-promise because it's a hack around the actual problem of getting objects out of a different context that was explicitly designed to behave this way. I'm afraid that you don't know what an XY problem is. JavaScript developers always seem to think they are the smart ones after their 6 weeks of some random bootcamp and then you end up with some crap like NPM where a single line in a package out of hundreds maintained by amateurs can break everybody's development environment.

by exogen 6y ago

suyjuris 6y ago

In case someone else is also confused by this, it seems that instanceof checks whether the objects prototype matches, and these prototypes are not shared across different contexts, which iframes are [0]. (Though I would still like to know why it works like this.) [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#Description https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

odensc 6y ago
For security reasons - you can modify the prototypes and you wouldn't want iframes to inherit that.

hombre_fatal 6y ago

Though, let's also appreciate just how niche that case is. I'd be surprised if more than 0.5% of the JS devs reading this will ever encounter that scenario where they are reaching across VMs like that in their life. `obj instanceof Promise` and `typeof obj.then === 'function'` (is-promise) are much different checks. Frankly, I don't think either belongs in a library. You should just write that code yourself and ponder the trade-offs. Do you really just want to check if an object has a then() method or do you want to check its prototype chain?

stagas 6y ago

No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing with multiple windows become a concern of a single layer and not your entire codebase. Implicitly and magically treating a foreign window as this window, will fail in many subtle and unknown ways. The "brokenness" you mention is not in that implementation, it is correctly breaking, telling you that what you are doing is wrong, then you try to bypass the error instead of fixing your approach.

foepys 6y ago
GP's comment screams XY problem which seem to be increasingly common these days.
- exogen 6y ago
  If you think pointing out a bug due to an edge case someone didn't think of is the XY problem, I'm afraid you don't know what the XY problem is.
  - foepys 6y ago
    The problem was to get the promise out of the iframe when you shouldn't do this directly in the first place. This literally is an XY problem: "I need to do A but it's giving me bad results, what do I need to add?" - "Don't use A, it's bad practice. Use B instead and keep using built-in tools instead of hacking something together" In this case use instanceof instead of is-promise because it's a hack around the actual problem of getting objects out of a different context that was explicitly designed to behave this way. I'm afraid that you don't know what an XY problem is. JavaScript developers always seem to think they are the smart ones after their 6 weeks of some random bootcamp and then you end up with some crap like NPM where a single line in a package out of hundreds maintained by amateurs can break everybody's development environment.