angular 中的$event 对象包含了浏览器原生的event对象

ou can pass the $event object as an argument when calling the function.

The $event object contains the browser's event object:

Example

<div ng-app="myApp" ng-controller="myCtrl">

<h1 ng-mousemove="myFunc($event)">Mouse Over Me!</h1>

<p>Coordinates: {{x + ', ' + y}}</p>

</div>
<script>
var app = angular.module('myApp', []);
app.controller('myCtrl', function($scope) {
    $scope.myFunc = function(myE) {
        $scope.x = myE.clientX;
        $scope.y = myE.clientY;
    }
});
</script>
-----------------------------------------------------------------------------------

Is Injecting The $element And $event Objects An Anti-Pattern In AngularJS?

By Ben Nadel on November 24, 2015

In the "Angular Way," there is a strict separation of concerns. The Controllers aren't supposed to know anything about the DOM (Document Object Model); the Controllers simply manage the view-model and leave it up to the Directives to "glue" the view-model to the DOM. In the "Angular Way," the Directives are the only thing that should know about the DOM. And yet, you can inject the $element into your Controller constructor and you can pass the $event into your Controller using scope methods. Which begs the question: should injecting the $element and $event objects be considered an anti-pattern in AngularJS?

Personally, I lean towards Yes on this one - that it is an anti-pattern.

However, I will caveat that with saying that sometimes the simplicity of doing so (injecting $element or $event) may substantially outweigh the complexity of keeping things separate. I don't think there's anything that can't be accomplished with $watch() bindings and event-bindings inside a link() function. But, especially for one-off events, mutating the $element directly can be more straightforward than worrying about $watch() bindings.

A good example of that might be the native Form Controller that ships with AngularJS. In the Form Controller, the $element injectable is used to add various pristine, dirty, and other state-indicating classes onto the Form element in response to method invocation (ex, form.$setDirty()). Could each of these classes be added or removed by a $watch() binding in a link() function that was observing the changes in the Form Controller's view-model? Probably. But, it may be hard to argue that such a strict separation would make the code more peformant, easier to reason about, and easier to maintain.

So, personally, I think you should avoid injecting the $element object into the Controller constructor or passing the $event object into a Controller method. I think doing so blurs the lines and breaks-down the strict separation of concerns outlined in the "Angular Way." But, as Morpheus said about rules, "some of them can be bent; others can be broken." Just make sure you're operating based on educated decisions.

原文地址:https://www.cnblogs.com/oxspirt/p/9116370.html