mirror of
https://github.com/Hopiu/angular.js.git
synced 2026-03-25 02:40:24 +00:00
docs(guide): correct couple of typos
This commit is contained in:
parent
1904596e0c
commit
a57141fd1d
3 changed files with 9 additions and 9 deletions
|
|
@ -133,10 +133,10 @@ to save a clean copy of the `li` element for cloning purposes and as new `action
|
|||
the template `li` element needs to be cloned and inserted into `ul`. But cloning the `li` element
|
||||
is not enough. It also needs to compile the `li` so that its directives such as
|
||||
`{{action.descriptions}}` evaluate against the right {@link api/angular.module.ng.$rootScope.Scope
|
||||
scope}. A naive method would be to simply insert a copy of the `li` elemnt and then compile it.
|
||||
scope}. A naive method would be to simply insert a copy of the `li` element and then compile it.
|
||||
But compiling on every `li` element clone would be slow, since the compilation requires that we
|
||||
traverse the DOM tree and look for directives and execute them. If we put the compilation inside a
|
||||
repeater which needs to unroll 100 items we would quickly run into performance problem.
|
||||
repeater which needs to unroll 100 items we would quickly run into performance problems.
|
||||
|
||||
The solution is to break the compilation process into two phases the compile phase where all of
|
||||
the directives are identified and sorted by priority, and a linking phase where any work which
|
||||
|
|
@ -227,7 +227,7 @@ In this example we will build a directive which displays the current time.
|
|||
|
||||
# Writing directives (long version)
|
||||
|
||||
The full skeleton of the directive is shown here:
|
||||
An example skeleton of the directive is shown here, for the complete list see below.
|
||||
|
||||
<pre>
|
||||
var myModule = angular.module(...);
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
# What is a Module?
|
||||
|
||||
Most applications have a main method which instantiates, wires, and bootstraps the application.
|
||||
Angular apps don't have a main method, instead the modules serves the purpose of declaratively
|
||||
Angular apps don't have a main method, instead modules serve the purpose of declaratively
|
||||
specifying how an application should be bootstrapped. There are several advantages to this
|
||||
approach:
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ approach:
|
|||
|
||||
# The Basics
|
||||
|
||||
Ok, I'm in a hurry how do i get a Hello World module working?
|
||||
Ok, I'm in a hurry. How do I get a Hello World module working?
|
||||
|
||||
Important things to notice:
|
||||
|
||||
|
|
@ -62,9 +62,9 @@ that you break your application to multiple modules like this:
|
|||
initialization code.
|
||||
|
||||
The reason for this breakup is that in your tests, it is often necessary to ignore the
|
||||
initialization code, which tends to be difficult to test. By putting it into separate module it
|
||||
initialization code, which tends to be difficult to test. By putting it into a separate module it
|
||||
can be easily ignored in tests. The tests can also be more focused by only loading the modules
|
||||
which are relevant to tests.
|
||||
that are relevant to tests.
|
||||
|
||||
The above is only a suggestion, so feel free to tailor it to your needs.
|
||||
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ being the element on which the `ngApp` directive was defined.
|
|||
evaluated by Angular in the context of the current model scope, rather than within the scope of
|
||||
the global context (`window`).
|
||||
|
||||
As expected, once this template is processed by Angular, the html page will contains text:
|
||||
As expected, once this template is processed by Angular, the html page contains the text:
|
||||
"Nothing here yet!".
|
||||
|
||||
## Bootstrapping AngularJS apps
|
||||
|
|
@ -226,7 +226,7 @@ There are 3 important things that happen during the app bootstrap:
|
|||
|
||||
|
||||
Once an application is bootstrapped, it will then wait for incoming browser events (such as mouse
|
||||
click, key press or incoming HTTP response) that might change the model. Once such event occurs,
|
||||
click, key press or incoming HTTP response) that might change the model. Once such an event occurs,
|
||||
Angular detects if it caused any model changes and if changes are found, Angular will reflect them
|
||||
in the view by updating all of the affected bindings.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue