3 ms·
Do these promises work differently from most other implementations? Just sticking a `.then(console.log)` seems like it would yield `undefined` to the next funct
by bilalq 13y ago
Do these promises work differently from most other implementations? Just sticking a `.then(console.log)` seems like it would yield `undefined` to the next function in the promise chain, no?
- esailija 13y agoMaybe the code was untested or only tested in firefox or node, where `console.log` is bound (which is sane default for singletons if you ask me)
- bendrucker 13y agoIt's true that console.log is bound in FF and Node but that s not the issue here. Passing console.log to then will cause the next handler to receive the return value of the console.log call, i.e. undefined.
- esailija 13y agoIn mithril promises if you return undefined from then, the promise will fulfill with the previous value, I.E. it behaves like .tap in other promise libraries (because doing this in a .then like mithril does violates the spec - which is evidently surprising) However, with unbound console.log the code doesn't work at all, this is the case in Chrome for example.
- bendrucker 13y agoThe breaks from A+ are pretty serious, both the treatment of undefined and releasing zalgo (http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony http://blog.izs.me/post/59142742143/designing-apis-for-async...) and calling it a feature. Not on the hunt for a client side micro-framework but since I use a lot of modules that supply promises there's no way I'd use this.
- phpnode 13y agoagree, this sounds like a bug, console.log() returns undefined so that's what the next promise in the chain should receive.