chore: remove deprecated `clear=` and use clear layout helpers (#2822)
* define clear layout helpers * replace deprecated clear= with helper
This commit is contained in:
Eric Jimenez
Kathy Walrath
parent
bde8fe1478
commit
e59cd9abc9
|
|
@ -55,7 +55,7 @@ figure
|
|||
|
||||
A typical module is a cohesive block of code dedicated to a single purpose.
|
||||
A module **exports** something of value in that code, typically one thing such as a class.
|
||||
<br clear="all"><br>
|
||||
<br class="l-clear-both">
|
||||
|
||||
block modules-in-dart
|
||||
//- N/A
|
||||
|
|
@ -118,7 +118,7 @@ block angular-library-modules
|
|||
|
||||
:marked
|
||||
`!{_at_angular}/core` is the primary Angular library from which we get most of what we need.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
|
||||
There are other important Angular libraries too, such as `!{_at_angular}/common`<span if-docs="ts">,
|
||||
`!{_at_angular}/http`</span> and `!{_at_angular}/router`.
|
||||
|
|
@ -229,7 +229,7 @@ figure
|
|||
We can and _will_ mix our custom components with native HTML in the same layouts.
|
||||
|
||||
In this manner we'll compose complex component trees to build out our richly featured application.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
|
||||
.l-main-section
|
||||
:marked
|
||||
|
|
@ -239,7 +239,7 @@ figure
|
|||
|
||||
:marked
|
||||
<p style="padding-top:10px">Metadata tells Angular how to process a class.</p>
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
[Looking back at the code](#component-code) for `HeroListComponent`, we see that it's just a class.
|
||||
There is no evidence of a framework, no "Angular" in it at all.
|
||||
|
|
@ -294,7 +294,7 @@ figure
|
|||
We apply other metadata !{_decorator}s in a similar fashion to guide Angular behavior.
|
||||
`@Injectable`, `@Input`, and `@Output` are a few of the more popular !{_decorator}s
|
||||
we'll master as our Angular knowledge grows.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
The architectural takeaway is that we must add metadata to our code
|
||||
so that Angular knows what to do.
|
||||
|
|
@ -314,7 +314,7 @@ figure
|
|||
|
||||
There are four forms of data binding syntax. Each form has a direction — to the DOM, from the DOM, or in both directions —
|
||||
as indicated by the arrows in the diagram.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
We saw three forms of data binding in our [example](#templates) template:
|
||||
|
||||
|
|
@ -350,12 +350,12 @@ figure
|
|||
We don't know all the details yet,
|
||||
but it's clear from these examples that data binding plays an important role in communication
|
||||
between a template and its component.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
figure
|
||||
img(src="/resources/images/devguide/architecture/parent-child-binding.png" alt="Parent/Child binding" style="float:left; width:300px; margin-left:-40px;margin-right:10px" )
|
||||
:marked
|
||||
Data binding is also important for communication between parent and child components.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
|
||||
.l-main-section
|
||||
:marked
|
||||
|
|
@ -368,7 +368,7 @@ figure
|
|||
|
||||
A directive is a class with directive metadata. In !{_Lang} we apply the `@Directive` !{_decorator}
|
||||
to attach metadata to the class.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
We already met one form of directive: the component. A component is a *directive-with-a-template*;
|
||||
a `@Component` !{_decorator} is actually a `@Directive` !{_decorator} extended with template-oriented features.
|
||||
|
|
@ -427,7 +427,7 @@ figure
|
|||
|
||||
Almost anything can be a service.
|
||||
A service is typically a class with a narrow, well-defined purpose. It should do something specific and do it well.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
Examples include:
|
||||
* logging service
|
||||
|
|
@ -478,7 +478,7 @@ figure
|
|||
_Dependency injection_ is a way to supply a new instance of a class
|
||||
with the fully-formed dependencies it requires. Most dependencies are services.
|
||||
Angular uses dependency injection to provide new components with the services they need.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
Angular can tell which services a component needs by looking at the types of its constructor parameters.
|
||||
For example, the constructor of our `HeroListComponent` needs a `HeroService`:
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ figure
|
|||
_Angular modules_ are a big deal.
|
||||
This page introduces modules; the [Angular modules](ngmodule.html) page covers them in depth.
|
||||
|
||||
<br clear="all"><br>
|
||||
<br class="l-clear-both"><br>
|
||||
:marked
|
||||
Every Angular app has at least one module, the _root module_, conventionally named `AppModule`.
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ figure
|
|||
Each Angular library name begins with the `!{_at_angular}` prefix.
|
||||
|
||||
You install them with the **npm** package manager and import parts of them with JavaScript `import` statements.
|
||||
<br clear="all"><br>
|
||||
<br class="l-clear-both"><br>
|
||||
:marked
|
||||
For example, import Angular's `Component` decorator from the `@angular/core` library like this:
|
||||
+makeExample('app/app.component.ts', 'import', '')(format='.')
|
||||
|
|
@ -214,7 +214,7 @@ figure
|
|||
:marked
|
||||
Notice how `<hero-detail>` rests comfortably among native HTML elements. Custom components mix seamlessly with native HTML in the same layouts.
|
||||
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
|
||||
.l-hr
|
||||
|
||||
|
|
@ -226,7 +226,7 @@ figure
|
|||
|
||||
:marked
|
||||
<p style="padding-top:10px">Metadata tells Angular how to process a class.</p>
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
[Looking back at the code](#component-code) for `HeroListComponent`, you can see that it's just a class.
|
||||
There is no evidence of a framework, no "Angular" in it at all.
|
||||
|
|
@ -275,7 +275,7 @@ figure
|
|||
|
||||
Apply other metadata !{_decorator}s in a similar fashion to guide Angular behavior.
|
||||
`@Injectable`, `@Input`, and `@Output` are a few of the more popular !{_decorator}s.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
The architectural takeaway is that you must add metadata to your code
|
||||
so that Angular knows what to do.
|
||||
|
|
@ -296,7 +296,7 @@ figure
|
|||
Add binding markup to the template HTML to tell Angular how to connect both sides.
|
||||
|
||||
As the diagram shows, there are four forms of data binding syntax. Each form has a direction — to the DOM, from the DOM, or in both directions.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
The `HeroListComponent` [example](#templates) template has three forms:
|
||||
|
||||
|
|
@ -330,12 +330,12 @@ figure
|
|||
:marked
|
||||
Data binding plays an important role in communication
|
||||
between a template and its component.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
figure
|
||||
img(src="/resources/images/devguide/architecture/parent-child-binding.png" alt="Parent/Child binding" style="float:left; width:300px; margin-left:-40px;margin-right:10px" )
|
||||
:marked
|
||||
Data binding is also important for communication between parent and child components.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
|
||||
.l-hr
|
||||
|
||||
|
|
@ -350,7 +350,7 @@ figure
|
|||
|
||||
A directive is a class with directive metadata. In !{_Lang}, apply the `@Directive` !{_decorator}
|
||||
to attach metadata to the class.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
A component is a *directive-with-a-template*;
|
||||
a `@Component` !{_decorator} is actually a `@Directive` !{_decorator} extended with template-oriented features.
|
||||
|
|
@ -410,7 +410,7 @@ figure
|
|||
|
||||
Almost anything can be a service.
|
||||
A service is typically a class with a narrow, well-defined purpose. It should do something specific and do it well.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
Examples include:
|
||||
* logging service
|
||||
|
|
@ -463,7 +463,7 @@ figure
|
|||
_Dependency injection_ is a way to supply a new instance of a class
|
||||
with the fully-formed dependencies it requires. Most dependencies are services.
|
||||
Angular uses dependency injection to provide new components with the services they need.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
:marked
|
||||
Angular can tell which services a component needs by looking at the types of its constructor parameters.
|
||||
For example, the constructor of your `HeroListComponent` needs a `HeroService`:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ figure
|
|||
:marked
|
||||
This is a practical guide to Angular for experienced programmers who
|
||||
are building client applications in HTML and #{_Lang}.
|
||||
<br style="clear:left;">
|
||||
<br class="l-clear-left">
|
||||
|
||||
:marked
|
||||
## Organization
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ figure
|
|||
that provide visibility into these key life moments and the ability to act when they occur.
|
||||
|
||||
A directive has the same set of lifecycle hooks, minus the hooks that are specific to component content and views.
|
||||
<br clear="all">
|
||||
<br class="l-clear-both">
|
||||
## Table of Contents
|
||||
* [Overview](#hooks-overview)
|
||||
<br><br>
|
||||
|
|
|
|||
|
|
@ -296,3 +296,15 @@ button.verbose.on {display: none}
|
|||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
}
|
||||
|
||||
.l-clear-left {
|
||||
clear: left;
|
||||
}
|
||||
|
||||
.l-clear-right {
|
||||
clear: right;
|
||||
}
|
||||
|
||||
.l-clear-both {
|
||||
clear: both;
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue