docs(ts/architecture): Fix small typos/grammar.
closes #539 Fix various typos and grammatical/formatting errors: - pluralize words - add missing words - add punctuation - fix code blocks - etc.
This commit is contained in:
parent
fde1828a92
commit
aad9aaf8c7
|
@ -62,8 +62,8 @@ figure
|
|||
Look inside such a file and we'll see an `export` statement like this one.
|
||||
+makeExample('architecture/ts/app/app.component.ts', 'export', 'app/app.component.ts (excerpt)')(format=".")
|
||||
:marked
|
||||
The `export` statement tells TypeScript that is a module whose
|
||||
`AppComponent` class is public and accessible to other modules of the application
|
||||
The `export` statement tells TypeScript that this is a module whose
|
||||
`AppComponent` class is public and accessible to other modules of the application.
|
||||
|
||||
When we need a reference to the `AppComponent`, we **import** it like this:
|
||||
+makeExample('architecture/ts/app/boot.ts', 'import', 'app/boot.ts (excerpt)')(format=".")
|
||||
|
@ -159,12 +159,13 @@ figure
|
|||
that tells Angular how to render the Component.
|
||||
|
||||
A template looks like regular HTML much of the time ... and then it gets a bit strange. Here is a
|
||||
template for our `HeroList` component
|
||||
template for our `HeroList` component.
|
||||
+makeExample('architecture/ts/app/hero-list.component.html',null,'app/hero-list.component.html')
|
||||
:marked
|
||||
We recognize `<h2>` and `<div>`.
|
||||
But there's other markup that no one told us about in school.
|
||||
What is`*ngFor`, {{hero.name}}, `(click)`, `[hero]`, and `<hero-detail>`?
|
||||
What are `*ngFor`, `{{hero.name}}`, `(click)`, `[hero]`, and `<hero-detail>`?
|
||||
|
||||
These are examples of Angular's [template syntax](template-syntax.html).
|
||||
We will grow accustomed to that syntax and may even learn to love it.
|
||||
We'll begin to explain it in a moment.
|
||||
|
@ -258,7 +259,7 @@ figure
|
|||
## Data Binding
|
||||
Without a framework, we would be responsible for pushing data values into the HTML controls and turning user responses
|
||||
into actions and value updates. Writing such push/pull logic by hand is tedious, error-prone and a nightmare to
|
||||
read as the experienced jQuery programmer can attest
|
||||
read as the experienced jQuery programmer can attest.
|
||||
figure
|
||||
img(src="/resources/images/devguide/architecture/databinding.png" alt="Data Binding" style="width:220px; float:left; margin-left:-40px;margin-right:20px" )
|
||||
:marked
|
||||
|
@ -383,18 +384,17 @@ figure
|
|||
There is nothing specifically "Angular" about services. Angular itself has no definition of a "service".
|
||||
There is no service base class, no place to register a "service".
|
||||
|
||||
Yet services are fundamental to any Angular application. Our components are big consumers of service.
|
||||
Yet services are fundamental to any Angular application. Our components are big consumers of services.
|
||||
|
||||
We prefer our component classes lean. Our components don't fetch data from the server,
|
||||
they don't validate user input, they don't log directly to console. They delegate such task to services.
|
||||
they don't validate user input, they don't log directly to the console. They delegate such tasks to services.
|
||||
|
||||
A component's job is to enable the user experience and nothing more. It mediates between the view (rendered by the template)
|
||||
and the application logic (which often includes some notion of a "model").
|
||||
A good component presents properties and methods for data binding.
|
||||
It delegates everything non-trivial to services.
|
||||
and the application logic (which often includes some notion of a "model"). A good component presents
|
||||
properties and methods for data binding. It delegates everything non-trivial to services.
|
||||
|
||||
Angular doesn't *enforce* these principles.
|
||||
It won't complain if write a "kitchen sink" component with 3000 lines.
|
||||
It won't complain if we write a "kitchen sink" component with 3000 lines.
|
||||
|
||||
Angular does help us *follow* these principles ... by making it easy to factor our
|
||||
application logic into services and make those services available to components through *dependency injection*.
|
||||
|
@ -496,7 +496,7 @@ figure
|
|||
>**Component Router** - With the Component Router service, users can navigate a multi-screen application
|
||||
in a familiar web browsing style using URLs.
|
||||
|
||||
>**Events** - The DOM raise events. So can components and services. Angular offers mechanisms for
|
||||
>**Events** - The DOM raises events. So can components and services. Angular offers mechanisms for
|
||||
publishing and subscribing to events including an implementation of the [RxJS Observable](https://github.com/zenparsing/es-observable) proposal.
|
||||
|
||||
>**[Forms](forms.html)** - Support complex data entry scenarios with HTML-based validation and dirty checking.
|
||||
|
@ -511,7 +511,7 @@ figure
|
|||
this `currency` pipe expression,
|
||||
<div style="margin-left:40px">
|
||||
code-example(language="javascript" linenumbers=".").
|
||||
price | currency:'USD':true'
|
||||
price | currency:'USD':true
|
||||
</div>
|
||||
:marked
|
||||
>displays a price of "42.33" as `$42.33`.
|
||||
|
|
Loading…
Reference in New Issue