Can someone explain why this:
<input ui-event="{ blur : 'blurCallback()' }">
is better than this: <input onblur="blurCallback();" />
I thought binding data/events in HTML was a bad thing. Is it just a matter of preference?Can someone explain why this:
<input ui-event="{ blur : 'blurCallback()' }">
is better than this: <input onblur="blurCallback();" />
I thought binding data/events in HTML was a bad thing. Is it just a matter of preference?If you're talking about the general idea of binding events in HTML, they are the same, but combined with Angular's design the choice has a lot of advantages. From the docs (http://docs.angularjs.org/guide/concepts):
"The separation of the controller and the view is important because:
1. The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).
2. The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.
3. Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability."
So, instead of using
<input "ui-keypress="{13:'keypressCallback($event)'}">
where keypressCallback does a form submit or something, you would write a directive that is just "form-submitter" and you would have your DOM be
<input form-submitter >
So that way you can easily scan your view to see what elements have what behaviors, but not how.
And Angular also allows you to bind events within javascript and really that is what the "form-submitter" directive in this example would be doing as well, but it should not be happening in general within the view/dom.
Although many times it is too heavy weight to make a directive for everything, but that is where the scope concepts of Angular comes in as well as the controllers so that at least the functions that are being triggered are still more expressive as they are localized to the containing scope. So, for instance you could have a directive "my-form" which is just an enhancement of the standard html form. In my directive I can then define a "validate()" method which validates the inputs. So, instead of having a "form-validator" directive I can instead do:
<my-form> <input type="text" >
<button ng-click="validate()"/>
</my-form>Because of the scoping rules of Angular it is generally easier to infer the behavior of the method that is being called as it is scoped to my-form and as long as you are playing by the best practices there is not any real concern for functionality within that method to leak outside of "my-form" thus maintaining the ability to look at the DOM and have a pretty good idea of what the application is doing without digging through javascript as well.
Thanks for the explanation! That helped shed some light.
As I understand, Angular is its team's vision on how browsers will natively support client-side apps in the future, in which case there will probably be a more streamlined syntax for such things.