Some common AngularJS anti-patterns include: - Using jQuery to manipulate the DOM instead of directives - Checking $scope.$$phase instead of moving $apply calls appropriately - Not making ng-model bindings objects which can break child scopes - Creating bloated controllers that do too much like DOM manipulation instead of focusing on data - Not programming in an "Angular way" by manipulating views instead of models - Failing to encapsulate third party libraries in Angular services

1. Angularjs
Anti-Patterns

2. The List
● Using $() instead of angular.element()
● Using jQuery to manipulate the DOM
● Looking at $scope.$$phase
● Not making ng-model an object
● Controllers doing too much or too bloated
o Manipulating DOM or model/data
o Throwing everything on $scope
o Overusing $rootscope
● Not doing things the “Angular” way
o Programing like you would in jQuery
o Manipulating the view instead of the model
o Not using Angular built-ins ($timeout, ng-show, ng-click, etc.)
● Not encapsulating 3rd party libraries in an Angular service

3. $() vs. angular.element
If jQuery is available, angular.element is an alias for the jQuery
function. If jQuery is not available, angular.element delegates to Angular's
built-in subset of jQuery, called "jQuery lite" or "jqLite."“
Thus, angular.element is $(), so just use angular.element.
Side note: don’t wrap in $element in a directive in angular.element, it already
is one.
From the docs:

4. jQuery DOM manipulation
jQuery DOM manipulation isn’t detected by Angular’s dirty checker.
Generating DOM with jQuery doesn’t create any Angular bindings.
From the docs:
Stop trying to use jQuery to modify the DOM… . Really. That includes
adding elements, removing elements, retrieving their contents, showing
and hiding them. Use built-in directives, or write your own where
necessary, to do your DOM manipulation
“

5. $scope.$$phase
For future-proofing reasons, you should not use $$phase
“
From Angular:
Typically $scope.$$phase is used to conditionally call $apply.
Instead, move the $apply to where you know you’re outside Angular.
If nothing else, use $timeout.
Code example

6. ng-model not an object
Code example
If ng-model is a primitive type (string, number, boolean, null, undefined) any
references in a child controller or directive won’t be doubly bound.
If it’s a complex type (object or array), it will be doubly bound.
Always make ng-model an object.

7. Controller Bloat
Don’t just throw everything on $scope or you’ll end up with $scope soup.
Think of $scope as the public interface from your view to your data. Only
expose what you need in the view.
This goes for $rootscope as well.
Think of $rootscope as the global namespace, and we all know not to pollute
the global namespace.

8. Controller Bloat
Controllers should be small and lean.
Things that don’t belong in a controller:
● DOM manipulation (belongs in a directive)
● Ajax or $http (belongs in a service)
● Model/data (belongs in a service)
● Model/data manipulation (belongs in the same service as the data)
● Business logic (belongs in a service)
Exercise: convert bloated controller to lean controller

9. The “Angular” Way
Exercise: convert jQuery to Angular
Programing in Angular is very different than programming in jQuery
When using Angular, try not to manipulate the view (DOM), instead
manipulate the model (data and how it is presented)
Don’t forget about all the Angular built-in goodies like ng-show, ng-click, etc.

10. 3rd Party Libraries
When using 3rd party libraries, always wrap them in an Angular service.
angular.module(‘myApp’).factory(‘_’, function() {
return window._;
});
angular.module(‘myApp’).controller(‘myCtrl’, function(_) {
// can now use library as _
});

11. 3rd Party Libraries
By wrapping the library, you now allow Angular’s dependency injection to
handle everything.
This also makes testing easier as you can now inject a mock of the library
into the unit test.