4 ms·
OT this is the first time I've seen the arrow function syntax in ES6. My god it is horrible. const Cell = (value, i, j)=>m('button.cell', {onclick
by fnord77 7y ago
OT this is the first time I've seen the arrow function syntax in ES6. My god it is horrible.
const Cell = (value, i, j)=>m('button.cell',
{onclick: ()=>move(value, i, j)}, value
)
I can see why people are using things like clojurescript instead.
- pier25 7y agoIt's not only a syntax for anonymous functions. It also binds the function to the context where it's defined. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Looks weird at first but you get used it pretty quickly. And I gotta say the auto binding thing is awesome.
- fulafel 7y agoRe the Clojure comparison, it's not much of a consolation as the function binding problem doesn't exist there.
- pgt 7y agoWait till you see what it does to scope!
- TheRealPomax 7y agoWe all hate new syntax that we feel isn't "samey" enough to what we already know. That doesn't mean it's gross, it just means you learned something about your own preconceptions of what you thought JS was supposed to look and feel like. Thankfully, most of the time we learn that's just us, and move past that. Arrow functions have been around for nearly five years now: they're fine. You learn that they're just part of JS, and you see them everywhere in modern code, just with normal indentation and sensible white spacing to keep them perfectly readable (because minification will solve the "the code as written is too verbose" part of the dev cycle). The important thing is what they do: bind declaration context as execution context, so `this` keeps meaning the same thing, which drastically simplifies a lot code. In this case, there is simply no reason to use arrow functions at all, because we don't need to preserve the declaration context (there is no `this` that needs to be preserved), so if this were real code you'd probably use a normal function, and your comment should probably be "why not this?" function makeCell(value, i, j) { function onclick() { playMove(value, i, j); } return build('button.cell', { onclick }, value); } Or even, "actually, why not this?" /** * ... */ function clickCell(evt) { const t = evt.target, d = t.dataset; playMove(t.textContent, d.i, d.j); } /** * ... */ function makeCell(value, i, j) { const e = build('button.cell', value); e.setData({ i, j }); e.click(clickCell); return e; } To which the answer of course is "this isn't production code, arrow functions are fine. I mean come on, it's just a fun little JS exercise, stop trying to turn fun into work".
- fnord77 7y agoI don't use javascript regularly so I have no notice of "samey". But I've been exposed to enough of a variety of programming languages from APL to C to Rust to Scala that I have a pretty good idea when some construct looks awkward or unergonomic. ES6 looks like a nightmare. Even compared to the nightmare that is Scala. And remember, Javascript's roots are scheme. Here's the same thing in clojurescript. Tighter, balanced and no chaining of symbols. (defn Cell [value i j] (m 'button.cell' {:onclick #(move value, i, j)}))
- TheRealPomax 7y agoI've never used clojurescript (but have used perl, php, java, prolog, oocaml, js, python, ...), so to me that: looks like a clusterfuck. But of course, if I had a need where clojurescript was the best fit, and I had to use it daily for an appreciable amount of time, I'd acclimatize to it and consider this perfectly fine syntax. The same goes for ES6: it's objectively just syntax. If you think it's a nightmare, that's because you're the one doing the judging. Not because it is.
- hombre_fatal 7y agoadd = (a, b) => a + b xs.filter(x => x > 10) Are so elementary I'm not sure how they can look new to you unless you're new to programming.