I think this is the best Medium article I've read in a long time. Don't get me wrong, there are a lot of "good" ones -- but if I could brush my shoulders off, put my dirty body soap back in its box, so I can stand on it, and split that already split-end of a hair -- I would say I'm rather bored of articles from the hoard of authors without any pride, experience, or basic thought put into their approaches. There's only one thing on the ripe vine of gripes I make whine out of: any of the "no closing ')', so..." should be either inlined or indented. That is, with method-chaining, one should inline or indent because it is a break from the normal flow ... as far as the next line is concerned.
Otherwise, I appreciate your appreciation of Promises (over "Observables -- don't get me going on Golden Hammers) and the knock on Silicon Overloards who love making painful predictions of how the world should work on the smallest of scales.
Chances are, this article will ONLY be read in 2-8 years -- BUT -- it will be hailed as "a solid read for serious developers ... if you're interested in that kinda thing and looking for something to solve 'that problem'". I'm waiting for that day. I'm begging for that day. I'm waiting for the "Have you heard of CONCRETE?!!! It's amazing... It's a mata-acronym for [x]. Yeah, I guess it's basically what old farts born in the last millennium called 'SOLID' ... except it's like, ya know -- components, man ... gotta think in components" -- day. That's what I'm waiting for. That day.
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Two wee caveats here. One is that this is ultimately a matter of taste, and two is that closure is not (as mentioned in other comments here) the only approach to achieve our goals.
one should inline or indent because it is a break from the normal flow ... as far as the next line is concerned.
In this specific case, we can view these closures not as breaks from the normal top level flow, but continuations of the same flow, however with an assignment thrown in to the expression. Normally a JS assignment would require a new statement, but closure and lambdas let us do that without breaking the flow of the expression. In that regard, everything after the => is really part of the same fluent flow.
My aim here is to get developers out of the mindset that they need to mentally execute every char of source. I don't think you have to read these as "then, execute a callback which takes users, and the body of the callback is such and such, blah blah blah, close the closure and pop the callstack, move on.". I'd prefer to read this as "then, with the cooked and ordered dishes in hand, fetch the guest list. Keep both in the back of your mind while inviting the guests, then when they arrive, serve them."
It's not that developers should ever think in terms of the callstack, it's that when considering the expression as a whole, they should have the mental agility to abstract over it.
I dunno, does that make a lick of sense?
Anyways, you're right 100% that closure is not the only way to get'er done here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Benny Powers,
I think this is the best Medium article I've read in a long time. Don't get me wrong, there are a lot of "good" ones -- but if I could brush my shoulders off, put my dirty body soap back in its box, so I can stand on it, and split that already split-end of a hair -- I would say I'm rather bored of articles from the hoard of authors without any pride, experience, or basic thought put into their approaches. There's only one thing on the ripe vine of gripes I make whine out of: any of the "no closing ')', so..." should be either inlined or indented. That is, with method-chaining, one should inline or indent because it is a break from the normal flow ... as far as the next line is concerned.
Otherwise, I appreciate your appreciation of Promises (over "Observables -- don't get me going on Golden Hammers) and the knock on Silicon Overloards who love making painful predictions of how the world should work on the smallest of scales.
Chances are, this article will ONLY be read in 2-8 years -- BUT -- it will be hailed as "a solid read for serious developers ... if you're interested in that kinda thing and looking for something to solve 'that problem'". I'm waiting for that day. I'm begging for that day. I'm waiting for the "Have you heard of CONCRETE?!!! It's amazing... It's a mata-acronym for [x]. Yeah, I guess it's basically what old farts born in the last millennium called 'SOLID' ... except it's like, ya know -- components, man ... gotta think in components" -- day. That's what I'm waiting for. That day.
Two wee caveats here. One is that this is ultimately a matter of taste, and two is that closure is not (as mentioned in other comments here) the only approach to achieve our goals.
In this specific case, we can view these closures not as breaks from the normal top level flow, but continuations of the same flow, however with an assignment thrown in to the expression. Normally a JS assignment would require a new statement, but closure and lambdas let us do that without breaking the flow of the expression. In that regard, everything after the
=>is really part of the same fluent flow.My aim here is to get developers out of the mindset that they need to mentally execute every char of source. I don't think you have to read these as "then, execute a callback which takes users, and the body of the callback is such and such, blah blah blah, close the closure and pop the callstack, move on.". I'd prefer to read this as "then, with the cooked and ordered dishes in hand, fetch the guest list. Keep both in the back of your mind while inviting the guests, then when they arrive, serve them."
It's not that developers should ever think in terms of the callstack, it's that when considering the expression as a whole, they should have the mental agility to abstract over it.
I dunno, does that make a lick of sense?
Anyways, you're right 100% that closure is not the only way to get'er done here.