mirror of
https://github.com/Hopiu/angular.js.git
synced 2026-03-22 09:30:28 +00:00
doc(faq): Add Common Pitfalls section
Describes several common pitfalls new users of Angular fall into that I've observed in #angularjs.
This commit is contained in:
parent
66505ffc40
commit
d930a410fb
1 changed files with 99 additions and 0 deletions
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
#FAQ
|
||||
|
||||
## Questions
|
||||
|
||||
### Why is this project called "AngularJS"? Why is the namespace called "ng"?
|
||||
|
||||
Because HTML has Angular brackets and "ng" sounds like "Angular".
|
||||
|
|
@ -96,3 +98,100 @@ AJAX Apps}".
|
|||
### How is Angular licensed?
|
||||
|
||||
The MIT License.
|
||||
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
The Angular support channel (#angularjs on Freenode) sees a number of recurring pitfalls that new users of Angular fall into.
|
||||
This document aims to point them out before you discover them the hard way.
|
||||
|
||||
### DOM Manipulation
|
||||
|
||||
Stop trying to use jQuery to modify the DOM in controllers. 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.
|
||||
See below about duplicating functionality.
|
||||
|
||||
If you're struggling to break the habit, consider removing jQuery from your app.
|
||||
Really. Angular has the $http service and powerful directives that make it almost always unnecessary.
|
||||
Angular's bundled jQLite has a handful of the features most commonly used in writing Angular directives, especially binding to events.
|
||||
|
||||
### Trying to duplicate functionality that already exists
|
||||
|
||||
There's a good chance that your app isn't the first to require certain functionality.
|
||||
There are a few pieces of Angular that are particularly likely to be reimplemented out of old habits.
|
||||
|
||||
**ng-repeat**
|
||||
|
||||
`ng-repeat` gets this a lot.
|
||||
People try to use jQuery (see above) to add more elements to some container as they're fetched from the server.
|
||||
No, bad dog.
|
||||
This is what `ng-repeat` is for, and it does its job very well.
|
||||
Store the data from the server in an array on your `$scope`, and bind it to the DOM with `ng-repeat`.
|
||||
|
||||
**ng-show**
|
||||
|
||||
`ng-show` gets this frequently too.
|
||||
Conditionally showing and hiding things using jQuery is a common pattern in other apps, but Angular has a better way.
|
||||
`ng-show` (and `ng-hide`) conditionally show and hide elements based on boolean expressions.
|
||||
Describe the conditions for showing and hiding an element in terms of `$scope` variables:
|
||||
|
||||
<div ng-show="!loggedIn">Click <a href="#/login">here</a> to log in</div>
|
||||
|
||||
Note also the counterpart `ng-hide` and similar `ng-disabled`.
|
||||
Note especially the powerful `ng-switch` that should be used instead of several mutually exclusive `ng-show`s.
|
||||
|
||||
**ng-class**
|
||||
|
||||
`ng-class` is the last of the big three.
|
||||
Conditionally applying classes to elements is another thing commonly done manually using jQuery.
|
||||
Angular, of course, has a better way.
|
||||
You can give `ng-class` a whitespace-separated set of class names, and then it's identical to ordinary `class`.
|
||||
That's not very exciting, so there's a second syntax:
|
||||
|
||||
<div ng-class="{ errorClass: isError, warningClass: isWarning, okClass: !isError && !isWarning }">...</div>
|
||||
|
||||
Where you give `ng-class` an object, whose keys are CSS class names and whose values are conditional expressions using `$scope` variables.
|
||||
The element will then have all the classes whose conditions are truthy, and none of those whose conditions are falsy.
|
||||
|
||||
Note also the handy `ng-class-even` and `ng-class-odd`, and the related though somewhat different `ng-style`.
|
||||
|
||||
|
||||
### `$watch` and `$apply`
|
||||
|
||||
Angular's two-way data binding is the root of all awesome in Angular.
|
||||
However, it's not magic, and there are some situations where you need to give it a nudge in the right direction.
|
||||
|
||||
When you bind a value to an element in Angular using `ng-model`, `ng-repeat`, etc., Angular creates a `$watch` on that value.
|
||||
Then whenever a value on a scope changes, all `$watch`es observing that element are executed, and everything updates.
|
||||
|
||||
Sometimes, usually when you're writing a custom directive, you will have to define your own `$watch` on a scope value to make the directive react to changes.
|
||||
|
||||
On the flip side, sometimes you change a scope value in some code but the app doesn't react to it.
|
||||
Angular checks for scope variable changes after pieces of your code have finished running; for example, when `ng-click` calls a function on your scope, Angular will check for changes and react.
|
||||
However, some code is outside of Angular and you'll have to call `scope.$apply()` yourself to trigger the update.
|
||||
This is most commonly seen in event handlers in custom directives.
|
||||
|
||||
### Combining `ng-repeat` with other directives
|
||||
|
||||
`ng-repeat` is extremely useful, one of the most powerful directives in Angular.
|
||||
However the transformation it applies to the DOM is substantial.
|
||||
Therefore applying other directives (such as `ng-show`, `ng-controller` and others) to the same element as `ng-repeat` generally leads to problems.
|
||||
|
||||
If you want to apply a directive to the whole repeat, wrap the repeat in a parent element and put it there.
|
||||
If you want to apply a directive to each inner piece of the repeat, put it on a child of the element with `ng-repeat`.
|
||||
|
||||
### `$rootScope` exists, but it can be used for evil
|
||||
|
||||
Scopes in Angular form a hierarchy, prototypically inheriting from a root scope at the top of the tree.
|
||||
Usually this can be ignored, since most views have a controller, and therefore a scope, of their own.
|
||||
|
||||
Occasionally there are pieces of data that you want to make global to the whole app.
|
||||
For these, you can inject `$rootScope` and set values on it like any other scope.
|
||||
Since the scopes inherit from the root scope, these values will be available to the expressions attached to directives like `ng-show` just like values on your local `$scope`.
|
||||
|
||||
Of course, global state sucks and you should use `$rootScope` sparingly, like you would (hopefully) use with global variables in any language.
|
||||
In particular, don't use it for code, only data.
|
||||
If you're tempted to put a function on `$rootScope`, it's almost always better to put it in a service that can be injected where it's needed, and more easily tested.
|
||||
|
||||
Conversely, don't create a service whose only purpose in life is to store and return bits of data.
|
||||
|
|
|
|||
Loading…
Reference in a new issue