4 ms·
It's always interesting to see real world applications of new Web functionality, so kudos to the Stripe team for pushing the envelope in an environment where mi
by Silhouette 9y ago
It's always interesting to see real world applications of new Web functionality, so kudos to the Stripe team for pushing the envelope in an environment where mistakes could surely be expensive. I hadn't realised that CSS Grid Layout was a viable option for production use yet, for example, so TIL.
I do wonder whether sometimes the code here is using trendy tools just to be trendy, though. For example, is
const getDistance = (state, rotate) =>
["x", "y"].reduce((object, axis) => {
object[axis] = Math.abs(state[axis] + rotate[axis]);
return object;
}, {});
really an improvement on grandpa's version
function getDistance(state, rotate) {
return {
x: Math.abs(state.x + rotate.x),
y: Math.abs(state.y + rotate.y)
};
}
?
- benaiah 9y agoYeah, that's a strange piece of code, particularly since it introduces mutation (object[axis] = ...) and additional processing (reduce loop and inner function construction) that the naive example doesn't. It is slightly more generalizable to additional dimensions, but that seems awfully YAGNI to me. I suppose it prevents repetition of the Math.abs call and addition, but again that seems like massive overkill. I'd write it as follows, similar to yours: const getDistance = (state, rotate) => ({ x: Math.abs(state.x + rotate.x), y: Math.abs(state.y + rotate.y), }) TBH, this thread is pretty nitpicky, but I do agree with your assessment.
- Silhouette 9y agoTBH, this thread is pretty nitpicky, but I do agree with your assessment. Yes and no. On the one hand, the much more interesting parts here are the new APIs they've been using (and also IMHO the intelligent way they're handling compatibility and polyfills). All credit to the Stripe team both for making these tools work and for sharing what they've learned in the process for the benefit of others. On the other hand, I think there is a real cultural problem in the JS community where newer is equated with better, and those defending that position will not infrequently appeal to authority by saying that Facebook or Stripe or Google or whoever does it so it must be a best practice. Grandpa here is getting awfully bored of young whippersnappers telling him code using new ES6 tricks is better (or, just as bad, that there's something wrong with clear, working code that does things in some older way). A gentle challenge to that assumption in a discussion about how these high profile organisations are using the new technologies doesn't seem either impolite or unjustified.
- barrkel 9y agoUsing an object literal is significantly superior than using a dynamic construction in any case where parameterization isn't needed. The body of that reduce looks like what you'd expect the implementation of a custom object literal initialization to look like - something where the members being iterated over are parameterized. I'm far less fussed about function vs lambda literal bound to a const. Usually that kind of decision comes down to tooling in debuggers - depending on the runtime, turning lambdas back into names may be difficult, if you have lambdas bound to event handlers and the like.
- rockostrich 9y agoIf you were trying to create a generalized getDistance function then the former would be preferred, but for this specific use case the latter outperforms the former by 2 orders of magnitude: https://jsperf.com/reduce-vs-standard/1 https://jsperf.com/reduce-vs-standard/1