It's a knockout choice I would say, nothing to do with the fact you cannot have an `handleEvent` in there.
Look at [eddy.js](https://github.com/WebReflection/eddy#event-driven-js) or put in in your project and you could handleEvent all the things, DOM and not ^_^ As easy as that, but you confirmed developers are not familiar at all with such pattern: this is bad, IMO, bad for them as massive limit over architectures aimed to deal with the DOM and/or even server side JS. That being said, I understand your very specific knockout base, but that's a surrounding env problem that didn't give you an easy way to solve this if not through bind or `self` addressed variable :-( Thanks for sharing though, libraries/frameworks are always a good example of "already got this problem in here". br On Wed, Oct 2, 2013 at 2:55 PM, Marius Gundersen <[email protected]>wrote: > Look at knockout.js and the way computed properties work. You quickly end > up with multiple bound functions on a single object, which are always > anonymous. The projects I've worked on lately has a lot of `var self = > this` to get things to work. Because we use knockout.js we don't have any > native dom event handlers, so your trick with the eventHandler method won't > work. And we use pubsub, which affect observables on the `this` object, and > Ajax is handled through Promises, which also needs access to the `this` > object. > > Marius Gundersen > On Oct 2, 2013 11:35 PM, "Andrea Giammarchi" <[email protected]> > wrote: > >> when do you need to address at runtime so many methods per >> instance/object ? >> >> I've got the "solve inline" thing but I keep wondering when, where, and >> why, we need so many inline runtime bound method attachments. >> >> Any real code example beside showing how shorter it is ? >> >> Promises could simply implement handleEvent too though, it will make >> objects reusable per each promise lifecycle at any time and with hot-swap >> per each handleMethod possibility. >> >> Very powerful, too bad developers behind didn't propose this approach too >> (yes, handleEvent can be swapped at runtime, that's how you could create a >> whole new world of possibilities through a single object and without even >> bother the DOM through add/remove listeners) >> >> Thanks >> >> >> >> >> On Wed, Oct 2, 2013 at 2:23 PM, Marius Gundersen <[email protected]>wrote: >> >>> >>> Every time someone wants to make a framework in JS they need to consider >>> `this`. For example, a simple pubsu library could look like this: >>> >>> publish("event", arg1, arg2) >>> subscribe("event", function(arg1, arg2){ >>> //do something, e.g. this.something = arg1+arg2 >>> }, this); >>> >>> But now the callback has the wrong this. One way around this is to force >>> people to use bind(this), or you can force developers to always support a >>> boundContext argument for every callback. For example, in promises: >>> >>> doSomething().then(function(result){ >>> this.result = result >>> }, this); >>> >>> Or with Knockout: >>> >>> this.sum = ko.computed(function(){ >>> return this.a() + this.b(); >>> }, this); >>> >>> Or with array functions: >>> >>> this.array.filter(function(a){ >>> return a>5; >>> }).forEach(function(a){ >>> this.sum += a; >>> }, this); >>> >>> These can all be simplified using the fat arrow: >>> >>> subscribe((arg1, arg2) => this.something = arg1 + arg2); >>> >>> doSomething().then((result) => this.result = result); >>> >>> this.sum = ko.computed(() => this.a() + this.b()); >>> >>> this.array.filter((a) => a>5).forEach((a) => this.sum += a); >>> >>> Not only does it reduce the amount of typing, which makes it easy to fit >>> all these examples into a single line, it takes care of the this variable, >>> which is used in a lot more places than DOM event handlers. >>> >>> Marius Gundersen >>> >>> >>> On Wed, Oct 2, 2013 at 8:14 PM, Andrea Giammarchi < >>> [email protected]> wrote: >>> >>>> If you cannot use fat arrow to define prototypes than you cannot >>>> recycle functions per each instance neither. >>>> IIRC you are behind a pretty damn good framework that works on DOM and >>>> indeed I was wondering if `handleEvent` would have been your choice there >>>> too. >>>> >>>> Thanks for your thoughts. >>>> >>>> >>>> On Wed, Oct 2, 2013 at 11:05 AM, Benoit Marchant <[email protected]>wrote: >>>> >>>>> One could say that JavaScript is an object oriented language where >>>>> functions are first class citizen. But JavaScript doesn't have *methods, >>>>> *which in most oo languages have the feature of always running with >>>>> this being the object the methods is executed on. >>>>> >>>>> Was introducing a new type "method" considered? In JavaScript it would >>>>> solve one class of problem we have with functions, which is the one I've >>>>> been most impacted with as I generally use JS in an more oo way than >>>>> functional way. And yes, I used more handleEvent for that reason. >>>>> >>>>> Benoit >>>>> >>>>> EOn Oct 2, 2013, at 10:55, Andrea Giammarchi < >>>>> [email protected]> wrote: >>>>> >>>>> fat arrow does not add any capabilities but create the need to be sure >>>>> about the context. >>>>> >>>>> In use strict fat arrow will bring a lovely `undefined` wich is >>>>> undesired so nothing is solved in there. >>>>> You need to be sure that the function/closure that is defining the fat >>>>> arrow is doing it in a `this` context you expect and I wonder how many >>>>> developers will fall into a `this` hell instead of "_callback hell_" >>>>> forced to define fat arrows inside functions such: >>>>> >>>>> ```javascript >>>>> (function(){ >>>>> >>>>> this.method = () => alert(123); >>>>> >>>>> }).call(theDesiredContext); >>>>> ``` >>>>> >>>>> The good part is that I've already written about so many pattern able >>>>> to solve many common mistakes fat arrow will introduce so at least for me >>>>> this will be a good reference to solve those mistakes/problems later on in >>>>> the future. >>>>> >>>>> Not much to add if not please read again your first answer to my >>>>> question, something not just me found not just rude. >>>>> >>>>> I've asked a question, a honest one, trying to understand. I wasn't >>>>> trolling and I write real code so your "virtually nobody use that" >>>>> approach >>>>> is my daily basis code which is "virtually a better architecture for my >>>>> needs" that I strongly hope W3C won't ever decide to get rid of because it >>>>> avoids massive, expensive, pointless usage of extra objects, GC >>>>> operations, >>>>> and amount of RAM. >>>>> >>>>> Google is usually very keen to these problems, handleEvent solve an >>>>> infinity of them at once, developers should just learn how convenient this >>>>> approach could be for mostly all their DOM based tasks and why not, even >>>>> more. >>>>> >>>>> Best Regards >>>>> >>>>> >>>>> >>>>> On Wed, Oct 2, 2013 at 10:46 AM, Tab Atkins Jr. >>>>> <[email protected]>wrote: >>>>> >>>>>> On Tue, Oct 1, 2013 at 7:35 PM, Andrea Giammarchi >>>>>> <[email protected]> wrote: >>>>>> > setTimeout accept extra arguments ... I write JavaScript that uses >>>>>> this >>>>>> > feature. >>>>>> > >>>>>> > `setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);` >>>>>> > >>>>>> > so fat arrow does not solve much here, I can use self as first >>>>>> argument and >>>>>> > I am good. >>>>>> > >>>>>> > `forEach` and all other arrays accept a second argument >>>>>> > >>>>>> > `array.forEach(doStuff, boundContextObject);` >>>>>> > >>>>>> > so fat arrow does not solve a thing in mostly all Array extras. >>>>>> >>>>>> Having the capability to set 'this' (or pass the current this as a >>>>>> plain argument) doesn't make it any more convenient. 'this' still >>>>>> isn't captured by the closure like every other variable is, which is >>>>>> confusing. As David said, being forced to pollute the signature of >>>>>> every standard callback-taking function with this argument is just >>>>>> silly. As Claude and others have said, the silly 'this'-rebinding >>>>>> kludges we have to adopt *everywhere* just to work around this feature >>>>>> of JS are ridiculous and fragile. Automatic 'this' binding is very >>>>>> convenient in some places. In others, it's very inconvenient. Arrow >>>>>> functions give us something better suited for those latter cases. >>>>>> >>>>>> > for **DOM** I use handlers as specified by **W3C** so that >>>>>> `{handleEvent: >>>>>> > function () {this}}` works better than any mess I could create with >>>>>> > callbacks that I won't be unable to remove later on (as I've said) >>>>>> ... >>>>>> >>>>>> Virtually nobody does this, and newer interfaces specified with the >>>>>> WebIDL 'callback' type don't accept it at all. >>>>>> >>>>>> > so I >>>>>> > can use `removeEventListener(this)` in every method handled by that >>>>>> object. >>>>>> >>>>>> I didn't mention event listeners, actually. There are lots of other >>>>>> things that take callbacks besides event listeners. >>>>>> >>>>>> > So I actually wonder what kind of JavaScript **you** write because >>>>>> this was >>>>>> > a honest question but probably ... people not familiar with JS are >>>>>> the >>>>>> > answer: since developers ignore part of JS specs available since >>>>>> every then >>>>>> > we need a fat arrow to break old syntax to make the creation of >>>>>> self bound >>>>>> > function easier. >>>>>> > >>>>>> > This would be already an answer so thanks for participating. >>>>>> >>>>>> Wow, that's pretty rude. >>>>>> >>>>>> ~TJ >>>>>> >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
