Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google open-sources JsAction, a JavaScript event delegation library

github.com

Post reply on HN
Print view View original

21–30 of 48 posts

Re: Google open-sources JsAction, a JavaScript event delegation library

#21

Post by Raynos »

This seems similar to a module I wrote called [html-delegator][1].

The separation of thing that emits named event and listener is a good idea.

I Actually moved away from the HTML attribute DSL and started putting named events in my virtual dom instead (using [mercury][2])

The important part of this approach that is not shown in js action is to ensure you emit data structures instead of dom event objects to the listeners.

  [1]: https://github.com/Raynos/html-delegator/blob/master/README.md
  [2]: https://github.com/Raynos/mercury

Re: Google open-sources JsAction, a JavaScript event delegation library

#23

Post by scotty79 »

cramforce wrote: post #18
scotty79 wrote: post #17

Earlier quoted context omitted.

> It's open for debate which is better. Which is same debate as between onclick and addEventListener only with slightly less verbose syntax on both sides of the debate and some implicit scoping that makes it possible.

Not a zero sum game though (although I do realize this is hackernews :). addEventListener is sometimes strictly better than using jsaction. i.e. it supports removing event listeners. That is fine. Right tool for the job. onclick-like functionality is coming back to frameworks. Angular and Polymer both have variations of what jsaction provides as a single-purpose library. It is sometimes just much nicer to bind stuff…

> onclick-like functionality is coming back to frameworks. Yes. I've noticed and as you might have guessed I'm equally deeply astonished and saddened.

> It is sometimes just much nicer to bind stuff together directly. Yes. It's so much nicer to have your hammer at your desk than to go to a cabinet to fetch it when you need it. But if you own bunch of tools and do various task at your desk it's either cabinet or a pile on you desk that at some point prevents you from making any progress on your projects.

Things should be kept separated out and organised by concern. If they are brought together it is either for convenience or speed. Both perfectly valid reasons so the separation is never strict but should be viewed as exception not as a rule. If you don't watch yourself you might end up with oscommerce PHP source files where everything is together because it's so much nicer to bind stuff directly.

Re: Google open-sources JsAction, a JavaScript event delegation library

#24

Post by scotty79 »

colbyh wrote: post #20
scotty79 wrote: post #11

Yes. Let's reinvent onclick attribute. What's with the recent trend of putting logic and visual configuration back into xmllish html clutter where you can't see it among the =" and meaningless words like div, span, class? Did people forget how much of a good idea was binding stuff to html from far away, from js and css files? Did new programmers evolved some new protein that prevents their eyes from bleeding when the…

Having actions tied to the object declaratively is a paradigm that javascript frameworks have been moving towards, rather than away from, for the past few years. When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Instead of digging through javascript (especially jquery heavy code wit…

> When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like.

Except that what you see in your html is not your element. It's just a forced structure required by w3c (described with xml syntax) for some aspects of visual representation of your element.

Your element should be described in js where it can be fairly easily separated out to a single file, and where binding configuration (as well as other concerns such as communication with backend or other app components for example) might be in one place instead of being interspersed with html tags unrelated to that behavior. See how backbone does event binding in views to understand what I'm talking about.

> So yes, let's please reinvent HTML

HTML is not so much an invention as result of glacial (or w3c-ish in other words) process of semi-(mis)directed evolution.

I'm guessing you never had to implement a layout using tables and 1px transparent gifs. I encourage you to try. It might make you understand how rigid and misaligned with the goal HTML in its spirit is. It got some improvements over the years but there was nothing revolutionary in its development even for fairly mild definitions of "revolutionary". Flexbox might become one such mini-revolution when few generations of IE do world a favor and die already.

JavaScript is far from being perfect and you can make a horrible mess of it as well, but at least it's general purpose language that supports various mechanisms for abstracting and organizing things and fairly minimalist syntax (as compared to xml, html) for declaring/organizing things that got wide appreciation as JSON.

Re: Google open-sources JsAction, a JavaScript event delegation library

#25

Post by scotty79 »

So this (with specialized lib, and fairly large unintuitive js code to set whole thing up):
is pretty much the same as this:
without any abusing or manipulating of html and dom and with setup as simple and understandable as this:

        window.Actions = {
            leftNav: {
                clickAction: function() {
                    myApp.LeftNav.doSomeSeriousStuff();
                },
                doubleClickAction: function() {
                    // very late loading of implementation
                    require("LeftNavActions", function(LeftNavActions) { 
                        LeftNavActions.doSomeOtherSeriousStuff();
                    })
                },
                // if you want add handlers from other places 
                // with Actions.leftNav._anotherAction.push()
                _anotherAction: [],
                anotherAction: function() {
                    this._anotherAction.forEach(function(a) { a(); });
                }

            }
        }
Actions is a good idea that I remember from Delphi 4. It is just one additional layer of indirection that enables you to attach same behavior for example to menu option and toolbar button.

Re: Google open-sources JsAction, a JavaScript event delegation library

#26

Post by couchand »

floatrock wrote: post #19

The API could use some work. To implement the simplest example, I need to remember patterns like: > eventContract.dispatchTo(goog.bind(dispatcher.dispatch, dispatcher)); imho, there's a problem if you need to dust off your gang of four book to understand the API. Might as well include an AbstractSingletonProxyFactoryBean.

The API could certainly use some work, and it's worse than you mention. If it were just a matter of applying widely-known Gang of Four patterns it would be fine. All over the place it looks like the designer didn't realize there's a built-in Function.prototype.bind.

Re: Google open-sources JsAction, a JavaScript event delegation library

#27

Post by colbyh »

scotty79 wrote: post #24
colbyh wrote: post #20

Earlier quoted context omitted.

Having actions tied to the object declaratively is a paradigm that javascript frameworks have been moving towards, rather than away from, for the past few years. When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Instead of digging through javascript (especially jquery heavy code wit…

> When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Except that what you see in your html is not your element. It's just a forced structure required by w3c (described with xml syntax) for some aspects of visual representation of your element. Your element should be described in js w…

Javascript, in a browser, exists to manipulate the document. If your opinion is that decoupling the elements of that document from the actions that might happen as a result of interacting with that element then so be it, but I couldn't disagree more. Even if it allows them to live in a "nicer" language (JS vs HTML), I'd rather everything be declared up front.

Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me. YMMV though. Luckily for me, most modern JS frameworks are similarly opinionated.

Re: Google open-sources JsAction, a JavaScript event delegation library

#28

Post by espeed »

wldlyinaccurate wrote: post #5

Is it just me, or does this not seem "tiny" at all? It seems to require a bunch of Closure modules, and on top of that the source itself is hundreds of lines (albeit with comments). Nitpicking aside, it looks like an interesting approach to decoupling the DOM from your event handlers. Personally I'm happy sticking with the standard on{event} attributes for really simple stuff.

The Closure advanced compiler can reduce the size significantly (https://developers.google.com/closure/compiler/docs/compilat...).

Re: Google open-sources JsAction, a JavaScript event delegation library

#29

Post by espeed »

dudus wrote: post #9

Seems like this has to be "compiled" with clojure compiler. I'm not very familiar with this. Can someone provide some rough instructions to actually get the "compiled" library?

The Google Closure compiler [1] (not Clojure); however, this is easy to mix up since ClojureScript [2] is built on Google Closure and uses the Google Closure compiler.

[1] https://developers.google.com/closure/compiler/docs/compilat...

[2] https://github.com/clojure/clojurescript

Re: Google open-sources JsAction, a JavaScript event delegation library

#30

Post by scotty79 »

colbyh wrote: post #27
scotty79 wrote: post #24

Earlier quoted context omitted.

> When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Except that what you see in your html is not your element. It's just a forced structure required by w3c (described with xml syntax) for some aspects of visual representation of your element. Your element should be described in js w…

Javascript, in a browser, exists to manipulate the document. If your opinion is that decoupling the elements of that document from the actions that might happen as a result of interacting with that element then so be it, but I couldn't disagree more. Even if it allows them to live in a "nicer" language (JS vs HTML), I'd rather everything be declared up front. Reading someone else's Backbone code (as compared to Angul…

> I'd rather everything be declared up front.

I'm all for declaring up front, just not in html.

> Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me.

Backbone is far from what I consider good readability. If encourages bad habits by not providing templating and sort of encouraging use of jQuery for dom modification. Binding events to backbone view is what I consider good readability.

Post reply on HN