Общо показвания

август 25, 2015

Evaluating jsaction library.

From time to time one starts wondering how are the some bigger web applications written, what technology has been used and from the properties of the product attempt to make decision if such technology could be useful for one's workflow.

This week I decided to take a look at jsaction - somewhat small library used in the making of Google+. If you happen to not use G+ (and if you believe the Internets - the chances are you are not, unless you are a Google employee) the web app features fluid design and is very capable on mobile phone (under chrome) - works really great and stays responsive and fast even after using it for a while.

The library itself has an interesting proposition: separate the event registration from the event handling and in this way allow for some interesting situations:

  • render server side and send content to be rendered as HTML
  • send script that basically does nothing else but to queue events 
  • additionally send 'handler' script that contains all the app logic 

As expected this results in HTML that is fast to load and works without waiting for the actual application logic to arrive over the wire. All handlers are registered on the body element and once the application logic is loaded the events are being replayed and dispatched to the designated handlers. 

The handlers themselves are described in the HTML directly via custom attribute (jsaction, thus the name of the library). The system is very similar to the event delegation pattern, but the actual handler code is determined from the html attribute instead of being declared in the code. This means that the handlers do not care much about where the event comes from in the DOM tree, which is kind of powerful.

The library supports custom events as well, unfortunately those cannot be declared in the HTML with the actual custom type of the event, instead the '_custom' type is always used and the actual type is hidden deep in the detail property of he event. In fact there is a global define flag that allows you to use the custom action name in the jsaction property: you can test it like this

    'jsaction.EventContract.CUSTOM_EVENT_SUPPORT': true

Additionally the event's artificial propagation is stopped once a matching handler is found.

This poses and interesting limitation: you cannot use the same combination of event name and handler in a nested tree as the first match will stop the flow. This however can also be controller by a global flag, take a look at eventcontract.js

The library is small and does not contain any 'gotchas' as far as I can tell. Big part of the code is wrappers around IE and other specific cases (mouseenter/mouselave, mac specifics etc). Another big chunk is static description of the library specific syntax. 

In what case would it be useful? 

I could easily imagine pages where certain actions must be available on user input (a la jQuery 'sprinkling' magic) and you would like the application logic to be kept on only one place. In this scenario you would need code that 'finds' elements on the page and add handlers to them (usually in the form of $('whatever').bind(...)).

jsaction allows you to skip the last part and instead of imperatively bind the actual logic to specific elements that JS needs to find in the DOM, one can simply add a property to the needed elements that will automatically bind the correct elements to the correct actions and corresponding handler.

It is important to notice that the library requires closure library and closure compiler (the latter one is optional, but almost inescapable for production), but this is only an implementation detail. The idea of the library could be useful outside the scope of closure tools and reminisce of the inline handler definitions we used back in the 90s, only in this case we have the namespaces to separate the different controls and the custom events. 

In the context of larger apps I believe the concept is becoming too complex to handle as the JS developer and the template developer need to coordinate on what is exposed and where (as the controls can be separated into smaller containers and not necessarily being document level, this is the events are being listened for always on the body, but the resolution of handlers can be scoped to container element, allowing for 'widgets' like boundaries).

For smaller projects I think it could be very useful especially to decouple the application logic from the specific endpoints in the DOM from where it should be triggered. 


Is this library for me?

Probably not, unless you already have experience with closure tools and you do not want to go deeper in the UI frameworks forest and instead you need simple and clean solution to attach application logic to specific points in the view. Note that all default events are supported (so mouse, keyboard, touch) and you can make it as complicated as needed (G+ is using it, and it's not simple), but unless you really want to render mostly server side and not deal with finding elements or constructing DOM on the client or you have very fluid design and you cannot keep up with HTML changes in case you have a large project it might be beneficial to consider other options before electing to go with jsaction. 

Няма коментари: