61–70 of 116 posts
> They're both (subjectively) wrong: the natural place for data in JS is the this parameter. ... said the person not understanding the language semantics. Passing arbitrary data as this is a terrible idea. It has to be an object and as such all primitives end up boxed.
I didn't have to box anything to pass a primitive as this. Maybe some other versions are different, but this works in Chrome 40 and Firefox 33.
Earlier quoted context omitted.
I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…
I haven't touched JavaScript in years, so I'm curious about one detail: why does the second snippet need you to alias "this" to "my" and the first doesn't? If it wasn't for that, it would look like mere syntactic sugar for lambdas, but this difference makes me think there's something more to it.
foo.bar()
quux(function() { console.log(this); })
Hence people have for years used bind():
quux(function() { console.log(this); }.bind(this));
quux(function() { console.log(this); }, this);
The lambda (arrow) syntax fixes all of this [pun] by preserving "this" as a lexically scoped reference:
quux(() => console.log(this));Earlier quoted context omitted.
I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…
I haven't touched JavaScript in years, so I'm curious about one detail: why does the second snippet need you to alias "this" to "my" and the first doesn't? If it wasn't for that, it would look like mere syntactic sugar for lambdas, but this difference makes me think there's something more to it.
Earlier quoted context omitted.
I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…
I haven't touched JavaScript in years, so I'm curious about one detail: why does the second snippet need you to alias "this" to "my" and the first doesn't? If it wasn't for that, it would look like mere syntactic sugar for lambdas, but this difference makes me think there's something more to it.
Earlier quoted context omitted.
I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…
A better example, in my opinion: let names = persons.map(p => p.name); Compared to ES5: var names = persons.map(function(p) { return p.name; }); The arrow syntaxes increases readability pretty much everywhere. Promises, for example: save(value) .then(result => this.update(result)) .catch(err => Application.showError(err, "Could not save.")) (The use of a function in the "then" here is to avoid having to bind() the fu…
And your second example; I was going to re-write it, but then I realized I couldn't because I didn't know what `this` was. I don't think `this` is useful, and I try to avoid it because of its malleability and the confusion it often brings because of its overly dynamic nature.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... , Ctrl-F for `Person` or something
(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…
(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…
var process = items => items.filter(isOk).map(toOtherType).flatten()Earlier quoted context omitted.
A better example, in my opinion: let names = persons.map(p => p.name); Compared to ES5: var names = persons.map(function(p) { return p.name; }); The arrow syntaxes increases readability pretty much everywhere. Promises, for example: save(value) .then(result => this.update(result)) .catch(err => Application.showError(err, "Could not save.")) (The use of a function in the "then" here is to avoid having to bind() the fu…
MDN thought it was a good example... [1] And your second example; I was going to re-write it, but then I realized I couldn't because I didn't know what `this` was. I don't think `this` is useful, and I try to avoid it because of its malleability and the confusion it often brings because of its overly dynamic nature. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... , Ctrl-F for `Person` or somethin…
Not sure why you don't know what "this" is in the second example. The whole point is that it's predictable. "this" is always the instance your method is defined in, unless you bind it to something else, which requires being explicit. I intentionally didn't include any context, but think about it this way:
class Store {
save(object) {
this.client.put("/objects", JSON.stringify(object))
.then(result => this.update(result))
.catch(err => Application.showError(err, "Could not save.")) }
}
}
this._socket = new WebSocket(`ws://${url}`);
this._socket.onopen = () => {
this._state = 'connected';
this.emit('connected');
};
(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…
Seems like you could just do var process = items => items.filter(isOk).map(toOtherType).flatten()
(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…
Agreed. And btw thank you for Ramda, which is a very beautiful thing. Too sad in day-to-day web development lodash is just enough.
It was finding that those tools were no longer supporting the way I wanted to work that got me started on Ramda. I'm guessing the same is true for the author of Trine.