Judy Bogart
atscott
parent
9e0583045c
commit
efdf347f9c
|
|
@ -1,4 +1,4 @@
|
|||
# AngularJS to Angular Concepts: Quick Reference
|
||||
# AngularJS to Angular concepts: Quick reference
|
||||
|
||||
|
||||
{@a top}
|
||||
|
|
@ -1271,4 +1271,3 @@ also encapsulate a style sheet within a specific component.
|
|||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# The Ahead-of-Time (AOT) compiler
|
||||
# Ahead-of-time (AOT) compilation
|
||||
|
||||
An Angular application consists mainly of components and their HTML templates. Because the components and templates provided by Angular cannot be understood by the browser directly, Angular applications require a compilation process before they can run in a browser.
|
||||
|
||||
The Angular Ahead-of-Time (AOT) compiler converts your Angular HTML and TypeScript code into efficient JavaScript code during the build phase _before_ the browser downloads and runs that code. Compiling your application during the build process provides a faster rendering in the browser.
|
||||
The Angular [ahead-of-time (AOT) compiler](guide/glossary#aot) converts your Angular HTML and TypeScript code into efficient JavaScript code during the build phase _before_ the browser downloads and runs that code. Compiling your application during the build process provides a faster rendering in the browser.
|
||||
|
||||
This guide explains how to specify metadata and apply available compiler options to compile your applications efficiently using the AOT compiler.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# AoT metadata errors
|
||||
# AOT metadata errors
|
||||
|
||||
The following are metadata errors you may encounter, with explanations and suggested corrections.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Attribute Directives
|
||||
# Attribute directives
|
||||
|
||||
An **Attribute** directive changes the appearance or behavior of a DOM element.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Angular CLI Builders
|
||||
# Angular CLI builders
|
||||
|
||||
A number of Angular CLI commands run a complex process on your code, such as linting, building, or testing.
|
||||
The commands use an internal tool called Architect to run *CLI builders*, which apply another tool to accomplish the desired task.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Component Interaction
|
||||
# Component interaction
|
||||
|
||||
{@a top}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Component Styles
|
||||
# Component styles
|
||||
|
||||
Angular applications are styled with standard CSS. That means you can apply
|
||||
everything you know about CSS stylesheets, selectors, rules, and media queries
|
||||
|
|
@ -289,7 +289,7 @@ Choose from the following modes:
|
|||
|
||||
* `Emulated` view encapsulation (the default) emulates the behavior of shadow DOM by preprocessing
|
||||
(and renaming) the CSS code to effectively scope the CSS to the component's view.
|
||||
For details, see [Appendix 1](guide/component-styles#inspect-generated-css).
|
||||
For details, see [Inspecting generated CSS](guide/component-styles#inspect-generated-css) below.
|
||||
|
||||
* `None` means that Angular does no view encapsulation.
|
||||
Angular adds the CSS to the global styles.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Creating Libraries
|
||||
# Creating libraries
|
||||
|
||||
You can create and publish new libraries to extend Angular functionality. If you find that you need to solve the same problem in more than one app (or want to share your solution with other developers), you have a candidate for a library.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Dependency Injection in Action
|
||||
# Dependency injection in action
|
||||
|
||||
This section explores many of the features of dependency injection (DI) in Angular.
|
||||
{@a toc}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Dependency Providers
|
||||
# Dependency providers
|
||||
|
||||
A dependency [provider](guide/glossary#provider) configures an injector
|
||||
with a [DI token](guide/glossary#di-token),
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Dependency Injection in Angular
|
||||
# Dependency injection in Angular
|
||||
|
||||
Dependency injection (DI), is an important application design pattern.
|
||||
Angular has its own DI framework, which is typically
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Deprecated APIs and Features
|
||||
# Deprecated APIs and features
|
||||
|
||||
Angular strives to balance innovation and stability.
|
||||
Sometimes, APIs and features become obsolete and need to be removed or replaced so that Angular can stay current with new best practices, changing dependencies, or changes in the (web) platform itself.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Displaying Data
|
||||
# Displaying data
|
||||
|
||||
You can display data by binding controls in an HTML template to properties of an Angular component.
|
||||
|
||||
|
|
@ -361,4 +361,3 @@ Here's the final code:
|
|||
</code-pane>
|
||||
|
||||
</code-tabs>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Angular Documentation Style Guide
|
||||
# Angular documentation style guide
|
||||
<!-- formerly Authors Style Guide -->
|
||||
|
||||
This Style Guide is for anyone who contributes to the Angular documentation (this site).
|
||||
This style guide is for anyone who contributes to the Angular documentation (this site).
|
||||
These guidelines should be followed by all authors.
|
||||
Deviations must be approved by a documentation editor.
|
||||
|
||||
|
|
@ -139,24 +139,26 @@ The title should appear at the top of the physical page.
|
|||
Begin the title with the markdown `#` character. Alternatively, you can write the equivalent `<h1>`.
|
||||
|
||||
```html
|
||||
# Authors Style Guide
|
||||
# Angular documentation style guide
|
||||
```
|
||||
|
||||
**Only one title (`<h1>`) per document!**
|
||||
|
||||
Title text should be in "Title Case", which means that you use capital letters to start the first words and all _principal_ words. Use lower case letters for _secondary_ words such as "in", "of", and "the".
|
||||
Title text should be in "Sentence case", which means the first word is capitalized and all other words are lower case (unless they are technical terms that are always capitalized, like "Angular").
|
||||
|
||||
```html
|
||||
# The Meat of the Matter
|
||||
# Deprecation policy in Angular
|
||||
```
|
||||
|
||||
**Always follow the title with at least one blank line.**
|
||||
|
||||
Note that the corresponding left-nav TOC text should be in "title case", which means that you use capital letters to start the first words and all principal words. Use lower case letters for secondary words such as "in", "of", and "the". The TOC title can also be shortened to fit in the column.
|
||||
|
||||
## Sections
|
||||
|
||||
A typical document is divided into sections.
|
||||
|
||||
All section heading text should be in "Sentence case", which means the first word is capitalized and all other words are lower case.
|
||||
All heading text should be in "Sentence case", which means the first word is capitalized and all other words are lower case.
|
||||
|
||||
**Always follow the section heading with at least one blank line.**
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Dynamic Component Loader
|
||||
# Dynamic component loader
|
||||
|
||||
Component templates are not always fixed. An application may need to load new components at runtime.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Dynamic Forms
|
||||
# Dynamic forms
|
||||
|
||||
{@a top}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Angular Elements Overview
|
||||
# Angular elements overview
|
||||
|
||||
_Angular elements_ are Angular components packaged as _custom elements_ (also called Web Components), a web standard for defining new HTML elements in a framework-agnostic way.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Entry Components
|
||||
# Entry components
|
||||
|
||||
An entry component is any component that Angular loads imperatively, (which means you’re not referencing it in the template), by type. You specify an entry component by bootstrapping it in an NgModule, or including it in a routing definition.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Feature Modules
|
||||
# Feature modules
|
||||
|
||||
Feature modules are NgModules for the purpose of organizing code.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Form Validation
|
||||
# Form validation
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Frequently Used Modules
|
||||
# Frequently-used modules
|
||||
|
||||
An Angular app needs at least one module that serves as the root module.
|
||||
As you add features to your app, you can add them in modules.
|
||||
|
|
|
|||
|
|
@ -478,6 +478,15 @@ or displayed between element tags, as in this example.
|
|||
|
||||
Read more about [interpolation](guide/template-syntax#interpolation) in [Template Syntax](guide/template-syntax).
|
||||
|
||||
{@a ivy}
|
||||
|
||||
## Ivy
|
||||
|
||||
Ivy is the code name for Angular's [next-generation compilation and rendering pipeline](https://blog.angular.io/a-plan-for-version-8-0-and-ivy-b3318dfc19f7).
|
||||
With the version 9 release of Angular, the new compiler and runtime instructions are used by default instead of the older compiler and runtime, known as [View Engine](#ve).
|
||||
|
||||
See [Angular Ivy](guide/ivy).
|
||||
|
||||
|
||||
{@a J}
|
||||
|
||||
|
|
@ -572,6 +581,14 @@ Compare to [NgModule](#ngmodule).
|
|||
|
||||
{@a N}
|
||||
|
||||
{@a ngcc}
|
||||
|
||||
## ngcc (Angular Compatability Compiler)
|
||||
|
||||
The CLI automatically runs the `ngcc` process to compile all your libraries with [Ivy](#ivy).
|
||||
If your app uses Ivy, but depends on libraries that don't use Ivy, `ngcc` automatically updates the dependent libraries to use Ivy when you compile your app.
|
||||
|
||||
|
||||
{@a ngmodule}
|
||||
|
||||
## NgModule
|
||||
|
|
@ -951,6 +968,13 @@ You can change the structure of elements by inserting, moving, or removing neste
|
|||
|
||||
View hierarchies can be loaded and unloaded dynamically as the user navigates through the application, typically under the control of a [router](#router).
|
||||
|
||||
{@a ve}
|
||||
|
||||
## View Engine
|
||||
|
||||
The compilation and rendering pipeline used by Angular before version 9. Compare [Ivy](#ivy).
|
||||
|
||||
|
||||
{@a view-tree}
|
||||
|
||||
## view hierarchy
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Appendix: Ivy Compatibility Examples
|
||||
# Ivy compatibility examples
|
||||
|
||||
This appendix is intended to provide more background on Ivy changes. Many of these examples list error messages you may see, so searching by error message might be a good idea if you are debugging.
|
||||
|
||||
|
|
@ -8,10 +8,10 @@ NOTE: Most of these issues affect a small percentage of applications encounterin
|
|||
|
||||
|
||||
{@a content-children-descendants}
|
||||
## @ContentChildren Queries Only Match Direct Children By Default
|
||||
## @ContentChildren queries only match direct children by default
|
||||
|
||||
|
||||
### Basic example of change
|
||||
### Basic example of change
|
||||
|
||||
Let's say a component (`Comp`) has a `@ContentChildren` query for `'foo'`:
|
||||
|
||||
|
|
@ -23,15 +23,15 @@ Let's say a component (`Comp`) has a `@ContentChildren` query for `'foo'`:
|
|||
</comp>
|
||||
```
|
||||
|
||||
In the previous runtime, the `<div>` with `#foo` would match.
|
||||
In the previous runtime, the `<div>` with `#foo` would match.
|
||||
With Ivy, that `<div>` does not match because it is not a direct child of `<comp>`.
|
||||
|
||||
|
||||
### Background
|
||||
|
||||
By default, `@ContentChildren` queries have the `descendants` flag set to `false`.
|
||||
By default, `@ContentChildren` queries have the `descendants` flag set to `false`.
|
||||
|
||||
In the previous rendering engine, "descendants" referred to "descendant directives".
|
||||
In the previous rendering engine, "descendants" referred to "descendant directives".
|
||||
An element could be a match as long as there were no other directives between the element and the requesting directive.
|
||||
This made sense for directives with nesting like tabs, where nested tab directives might not be desirable to match.
|
||||
However, this caused surprising behavior for users because adding an unrelated directive like `ngClass` to a wrapper element could invalidate query results.
|
||||
|
|
@ -49,7 +49,7 @@ For example, with the content query and template below, the last two `Tab` direc
|
|||
</div>
|
||||
<tab> <!-- match (top level) -->
|
||||
<tab> A </tab> <!-- not a match (nested in tab) -->
|
||||
</tab>
|
||||
</tab>
|
||||
<div [ngClass]="classes">
|
||||
<tab> Two </tab> <!-- not a match (nested in ngClass) -->
|
||||
</div>
|
||||
|
|
@ -70,7 +70,7 @@ For example, if you replace the type predicate above with a `'foo'` string predi
|
|||
</div>
|
||||
<tab #foo> <!-- match (top level) -->
|
||||
<div #foo> A </div> <!-- match (nested in tab) -->
|
||||
</tab>
|
||||
</tab>
|
||||
<div [ngClass]="classes">
|
||||
<div #foo> Two </div> <!-- match (nested in ngClass) -->
|
||||
</div>
|
||||
|
|
@ -78,7 +78,7 @@ For example, if you replace the type predicate above with a `'foo'` string predi
|
|||
```
|
||||
|
||||
Because the previous behavior was inconsistent and surprising to users, we did not want to reproduce it in Ivy.
|
||||
Instead, we simplified the mental model so that "descendants" refers to DOM nesting only.
|
||||
Instead, we simplified the mental model so that "descendants" refers to DOM nesting only.
|
||||
Any DOM element between the requesting component and a potential match will invalidate that match.
|
||||
Type predicates and string predicates also have identical matching behavior.
|
||||
|
||||
|
|
@ -90,7 +90,7 @@ Ivy behavior for directive/string predicates:
|
|||
</div>
|
||||
<tab> <!-- match (top level) -->
|
||||
<tab> A </tab> <!-- not a match (nested in tab) -->
|
||||
</tab>
|
||||
</tab>
|
||||
<div [ngClass]="classes">
|
||||
<tab> Two </tab> <!-- not a match (nested in div) -->
|
||||
</div>
|
||||
|
|
@ -101,7 +101,7 @@ Ivy behavior for directive/string predicates:
|
|||
### Example of error
|
||||
|
||||
The error message that you see will depend on how the particular content query is used in the application code.
|
||||
Frequently, an error is thrown when a property is referenced on the content query result (which is now `undefined`).
|
||||
Frequently, an error is thrown when a property is referenced on the content query result (which is now `undefined`).
|
||||
|
||||
For example, if the component sets the content query results to a property, `foos`, `foos.first.bar` would throw the error:
|
||||
|
||||
|
|
@ -109,19 +109,19 @@ For example, if the component sets the content query results to a property, `foo
|
|||
Uncaught TypeError: Cannot read property 'bar' of undefined
|
||||
```
|
||||
|
||||
If you see an error like this, and the `undefined` property refers to the result of a `@ContentChildren` query, it may well be caused by this change.
|
||||
If you see an error like this, and the `undefined` property refers to the result of a `@ContentChildren` query, it may well be caused by this change.
|
||||
|
||||
|
||||
### Recommended fix
|
||||
|
||||
You can either add the `descendants: true` flag to ignore wrapper elements or remove the wrapper elements themselves.
|
||||
|
||||
Option 1:
|
||||
Option 1:
|
||||
```
|
||||
@ContentChildren('foo', {descendants: true}) foos: QueryList<ElementRef>;
|
||||
```
|
||||
|
||||
Option 2:
|
||||
Option 2:
|
||||
```
|
||||
<comp>
|
||||
<div #foo></div> <!-- matches in both old runtime and new runtime -->
|
||||
|
|
@ -129,10 +129,10 @@ Option 2:
|
|||
```
|
||||
|
||||
{@a undecorated-classes}
|
||||
## All Classes That Use Angular DI Must Have An Angular Class-level Decorator
|
||||
## All classes that use Angular DI must have an Angular class-level decorator
|
||||
|
||||
|
||||
### Basic example of change:
|
||||
### Basic example of change:
|
||||
|
||||
In the previous rendering engine, the following would work:
|
||||
|
||||
|
|
@ -165,13 +165,13 @@ However, as you're adding new code in version 9, you may run into this differenc
|
|||
|
||||
### Background
|
||||
|
||||
When a class has an Angular decorator like `@Injectable` or `@Directive`, the Angular compiler generates extra code to support injecting dependencies into the constructor of your class.
|
||||
When using inheritance, Ivy needs both the parent class and the child class to apply a decorator to generate the correct code.
|
||||
When a class has an Angular decorator like `@Injectable` or `@Directive`, the Angular compiler generates extra code to support injecting dependencies into the constructor of your class.
|
||||
When using inheritance, Ivy needs both the parent class and the child class to apply a decorator to generate the correct code.
|
||||
Otherwise, when the decorator is missing from the parent class, the subclass will inherit a constructor from a class for which the compiler did not generate special constructor info, and Angular won't have the dependency info it needs to create it properly.
|
||||
|
||||
In the previous rendering engine, the compiler had global knowledge, so in some cases (such as AOT mode or the presence of certain injection flags), it could look up the missing data.
|
||||
However, the Ivy compiler only processes each class in isolation.
|
||||
This means that compilation has the potential to be faster (and opens the framework up for optimizations and features going forward), but the compiler can't automatically infer the same information as before.
|
||||
In the previous rendering engine, the compiler had global knowledge, so in some cases (such as AOT mode or the presence of certain injection flags), it could look up the missing data.
|
||||
However, the Ivy compiler only processes each class in isolation.
|
||||
This means that compilation has the potential to be faster (and opens the framework up for optimizations and features going forward), but the compiler can't automatically infer the same information as before.
|
||||
|
||||
Adding the proper decorator explicitly provides this information.
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ Adding the proper decorator explicitly provides this information.
|
|||
In JIT mode, the framework will throw the following error:
|
||||
|
||||
```
|
||||
ERROR: This constructor is not compatible with Angular Dependency Injection because its dependency at index X of the parameter list is invalid.
|
||||
ERROR: This constructor is not compatible with Angular Dependency Injection because its dependency at index X of the parameter list is invalid.
|
||||
This can happen if the dependency type is a primitive like a string or if an ancestor of this class is missing an Angular decorator.
|
||||
|
||||
Please check that 1) the type for the parameter at index X is correct and 2) the correct Angular decorators are defined for this class and its ancestors.
|
||||
|
|
@ -189,14 +189,14 @@ Please check that 1) the type for the parameter at index X is correct and 2) the
|
|||
In AOT mode, you'll see something like:
|
||||
|
||||
```
|
||||
X inherits its constructor from Y, but the latter does not have an Angular decorator of its own.
|
||||
Dependency injection will not be able to resolve the parameters of Y's constructor. Either add a
|
||||
X inherits its constructor from Y, but the latter does not have an Angular decorator of its own.
|
||||
Dependency injection will not be able to resolve the parameters of Y's constructor. Either add a
|
||||
@Directive decorator to Y, or add an explicit constructor to X.
|
||||
```
|
||||
|
||||
In some cases, the framework may not be able to detect the missing decorator.
|
||||
In some cases, the framework may not be able to detect the missing decorator.
|
||||
In these cases, you'll generally see a runtime error thrown when there is a property access attempted on the missing dependency.
|
||||
If dependency was `foo`, you'd see an error when accessing something like `foo.bar`:
|
||||
If dependency was `foo`, you'd see an error when accessing something like `foo.bar`:
|
||||
|
||||
```
|
||||
Uncaught TypeError: Cannot read property 'bar' of undefined
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Ivy Compatibility Guide
|
||||
# Ivy compatibility guide
|
||||
|
||||
The Angular team has worked hard to ensure Ivy is as backwards-compatible with the previous rendering engine ("View Engine") as possible.
|
||||
However, in rare cases, minor changes were necessary to ensure that the Angular's behavior was predictable and consistent, correcting issues in the View Engine implementation.
|
||||
|
|
@ -6,7 +6,7 @@ In order to smooth the transition, we have provided [automated migrations](guide
|
|||
That said, some applications will likely need to apply some manual updates.
|
||||
|
||||
{@a debugging}
|
||||
## How to Debug Errors with Ivy
|
||||
## How to debug errors with Ivy
|
||||
|
||||
In version 9, [a few deprecated APIs have been removed](guide/updating-to-version-9#removals) and there are a [few breaking changes](guide/updating-to-version-9#breaking-changes) unrelated to Ivy.
|
||||
If you're seeing errors after updating to version 9, you'll first want to rule those changes out.
|
||||
|
|
@ -19,16 +19,16 @@ If the errors are gone, switch back to Ivy by removing the changes to the `tscon
|
|||
|
||||
|
||||
{@a common-changes}
|
||||
### Changes You May See
|
||||
### Changes you may see
|
||||
|
||||
* By default, `@ContentChildren` queries will only search direct child nodes in the DOM hierarchy (previously, they would search any nesting level in the DOM as long as another directive wasn't matched above it). [details](guide/ivy-compatibility-examples#content-children-descendants)
|
||||
* By default, `@ContentChildren` queries will only search direct child nodes in the DOM hierarchy (previously, they would search any nesting level in the DOM as long as another directive wasn't matched above it). See further [details](guide/ivy-compatibility-examples#content-children-descendants).
|
||||
|
||||
* All classes that use Angular DI must have an Angular decorator like `@Directive()` or `@Injectable` (previously, undecorated classes were allowed in AOT mode only or if injection flags were used). [details](guide/ivy-compatibility-examples#undecorated-classes)
|
||||
* All classes that use Angular DI must have an Angular decorator like `@Directive()` or `@Injectable` (previously, undecorated classes were allowed in AOT mode only or if injection flags were used). See further [details](guide/ivy-compatibility-examples#undecorated-classes).
|
||||
|
||||
* Unbound inputs for directives (e.g. name in `<my-comp name="">`) are now set upon creation of the view, before change detection runs (previously, all inputs were set during change detection).
|
||||
|
||||
{@a less-common-changes}
|
||||
### Less Common Changes
|
||||
### Less common changes
|
||||
|
||||
* Properties like `host` inside `@Component` and `@Directive` decorators can be inherited (previously, only properties with explicit field decorators like `@HostBinding` would be inherited).
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ When using application internationalization (i18n) with Ivy, [translation mergin
|
|||
|
||||
Ivy applications can be built with libraries that were created with the View Engine compiler.
|
||||
This compatibility is provided by a tool known as the Angular compatibility compiler (`ngcc`).
|
||||
CLI commands run `ngcc` as needed performing an Angular build.
|
||||
CLI commands run `ngcc` as needed when performing an Angular build.
|
||||
|
||||
{@a speeding-up-ngcc-compilation}
|
||||
### Speeding up ngcc compilation
|
||||
|
|
@ -142,7 +142,7 @@ To revert the compiler default, set the build option `aot: false` in the `angula
|
|||
|
||||
If you disable Ivy and the project uses internationalization, you can also remove the `@angular/localize` runtime component from the project's polyfills file located be default at `src/polyfills.ts`.
|
||||
|
||||
To remove, delete the `import '@angular/localize/init';` line from the polyfills file.
|
||||
To remove, delete the `import '@angular/localize/init';` line from the polyfills file.
|
||||
|
||||
<code-example language="typescript" header="polyfills.ts">
|
||||
/***************************************************************************************************
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Lazy Loading Feature Modules
|
||||
# Lazy-loading feature modules
|
||||
|
||||
## High level view
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Overview of Angular Libraries
|
||||
# Overview of Angular libraries
|
||||
|
||||
Many applications need to solve the same general problems, such as presenting a unified user interface, presenting data, and allowing data entry.
|
||||
Developers can create general solutions for particular domains that can be adapted for re-use in different apps.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Lifecycle Hooks
|
||||
# Lifecycle hooks
|
||||
|
||||
A component has a lifecycle managed by Angular.
|
||||
|
||||
|
|
|
|||
|
|
@ -74,5 +74,4 @@ Libraries should add the generic type to any usages of the `ModuleWithProviders`
|
|||
|
||||
## What about applications using non-migrated libraries?
|
||||
|
||||
`ngcc` should transform any non-migrated libraries to generate the proper code.
|
||||
For more information on `ngcc` see the [ngcc guide](guide/ngcc).
|
||||
The [Angular compatibility compiler](guide/glossary#ngcc) (`ngcc`) should automatically transform any non-migrated libraries to generate the proper code.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Missing `@Directive()`/`@Component()` Decorator Migration
|
||||
# Missing `@Directive()`/`@Component()` decorator migration
|
||||
|
||||
## What does this migration do?
|
||||
|
||||
|
|
@ -185,4 +185,4 @@ You can either add `@Directive()` with a selector or move the Angular-specific f
|
|||
|
||||
## What about applications using non-migrated libraries?
|
||||
|
||||
`ngcc` should transform any non-migrated libraries to generate the proper code.
|
||||
The [Angular compatibility compiler](guide/glossary#ngcc) (`ngcc`) should automatically transform any non-migrated libraries to generate the proper code.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Types of Feature Modules
|
||||
# Types of feature modules
|
||||
|
||||
There are five general categories of feature modules which
|
||||
tend to fall into the following groups:
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
|
||||
# `ngcc`
|
||||
|
||||
## What is `ngcc`?
|
||||
|
||||
The Angular Compatibility Compiler, or `ngcc`, is a process that the CLI automatically runs which compiles all your libraries with Ivy.
|
||||
This means that even if the libraries your app depends on don't use Ivy, `ngcc` will update them to use Ivy for you.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# NgModule FAQs
|
||||
# NgModule FAQ
|
||||
|
||||
NgModules help organize an application into cohesive blocks of functionality.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# JavaScript Modules vs. NgModules
|
||||
# JavaScript modules vs. NgModules
|
||||
|
||||
JavaScript and Angular use modules to organize code, and
|
||||
though they organize it differently, Angular apps rely on both.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Reactive Forms
|
||||
# Reactive forms
|
||||
|
||||
*Reactive forms* provide a model-driven approach to handling form inputs whose values change over time. This guide shows you how to create and update a simple form control, progress to using multiple controls in a group, validate form values, and implement more advanced forms.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Angular Versioning and Releases
|
||||
# Angular versioning and releases
|
||||
|
||||
We recognize that you need stability from the Angular framework. Stability ensures that reusable components and libraries, tutorials, tools, and learned practices don't become obsolete unexpectedly. Stability is essential for the ecosystem around Angular to thrive.
|
||||
|
||||
|
|
@ -17,16 +17,16 @@ The practices described in this document apply to Angular 2.0 and later. If you
|
|||
{@a versioning}
|
||||
## Angular versioning
|
||||
|
||||
Angular version numbers indicate the level of changes that are introduced by the release. This use of [semantic versioning](https://semver.org/ "Semantic Versioning Specification") helps you understand the potential impact of updating to a new version.
|
||||
Angular version numbers indicate the level of changes that are introduced by the release. This use of [semantic versioning](https://semver.org/ "Semantic Versioning Specification") helps you understand the potential impact of updating to a new version.
|
||||
|
||||
Angular version numbers have three parts: `major.minor.patch`. For example, version 7.2.11 indicates major version 7, minor version 2, and patch level 11.
|
||||
Angular version numbers have three parts: `major.minor.patch`. For example, version 7.2.11 indicates major version 7, minor version 2, and patch level 11.
|
||||
|
||||
The version number is incremented based on the level of change included in the release.
|
||||
The version number is incremented based on the level of change included in the release.
|
||||
|
||||
* **Major releases** contain significant new features, some but minimal developer assistance is expected during the update. When updating to a new major release, you may need to run update scripts, refactor code, run additional tests, and learn new APIs.
|
||||
* **Major releases** contain significant new features, some but minimal developer assistance is expected during the update. When updating to a new major release, you may need to run update scripts, refactor code, run additional tests, and learn new APIs.
|
||||
|
||||
|
||||
* **Minor releases** contain new smaller features. Minor releases are fully backward-compatible; no developer assistance is expected during update, but you can optionally modify your apps and libraries to begin using new APIs, features, and capabilities that were added in the release. We update peer dependencies in minor versions by expanding the supported versions, but we do not require projects to update these dependencies.
|
||||
* **Minor releases** contain new smaller features. Minor releases are fully backward-compatible; no developer assistance is expected during update, but you can optionally modify your apps and libraries to begin using new APIs, features, and capabilities that were added in the release. We update peer dependencies in minor versions by expanding the supported versions, but we do not require projects to update these dependencies.
|
||||
|
||||
|
||||
* **Patch releases** are low risk, bug fix releases. No developer assistance is expected during update.
|
||||
|
|
@ -45,26 +45,26 @@ In alignment with the versioning scheme described above, we commit to support th
|
|||
* If you are updating within the **same major version,** then you can skip any intermediate versions and update directly to the targeted version. For example, you can update directly from 7.0.0 to 7.2.11.
|
||||
|
||||
|
||||
* If you are updating from **one major version to another,** then we recommend that you **don't skip major versions.** Follow the instructions to incrementally update to the next major version, testing and validating at each step. For example, if you want to update from version 6.x.x to version 8.x.x, we recommend that you update to the latest 7.x.x release first. After successfully updating to 7.x.x, you can then update to 8.x.x.
|
||||
* If you are updating from **one major version to another,** then we recommend that you **don't skip major versions.** Follow the instructions to incrementally update to the next major version, testing and validating at each step. For example, if you want to update from version 6.x.x to version 8.x.x, we recommend that you update to the latest 7.x.x release first. After successfully updating to 7.x.x, you can then update to 8.x.x.
|
||||
|
||||
|
||||
See [Keeping Up-to-Date](guide/updating "Updating your projects") for more information about updating your Angular projects to the most recent version.
|
||||
See [Keeping Up-to-Date](guide/updating "Updating your projects") for more information about updating your Angular projects to the most recent version.
|
||||
|
||||
|
||||
{@a previews}
|
||||
### Preview releases
|
||||
|
||||
We let you preview what's coming by providing Beta releases and Release Candidates (`rc`) for each major and minor release:
|
||||
We let you preview what's coming by providing Beta releases and Release Candidates (`rc`) for each major and minor release:
|
||||
|
||||
<!--
|
||||
* **Next:** The release that is under active development. The next release is indicated by a release tag appended with the `next` identifier, such as `8.1.0-next.0`. For the next version of the documentation, see [next.angular.io](https://next.angular.io).
|
||||
<!--
|
||||
* **Next:** The release that is under active development. The next release is indicated by a release tag appended with the `next` identifier, such as `8.1.0-next.0`. For the next version of the documentation, see [next.angular.io](https://next.angular.io).
|
||||
-->
|
||||
|
||||
* **Beta:** A release that is under active development and testing. A Beta release is indicated by a release tag appended with the `beta` identifier, such as `8.0.0-beta.0`.
|
||||
* **Beta:** A release that is under active development and testing. A Beta release is indicated by a release tag appended with the `beta` identifier, such as `8.0.0-beta.0`.
|
||||
|
||||
* **Release candidate:** A release that is feature complete and in final testing. A release candidate is indicated by a release tag appended with the `rc` identifier, such as version `8.1.0-rc`.
|
||||
|
||||
The next version of the documentation is available at [next.angular.io](https://next.angular.io). This includes any documentation for Beta or Release Candidate features and APIs.
|
||||
The next version of the documentation is available at [next.angular.io](https://next.angular.io). This includes any documentation for Beta or Release Candidate features and APIs.
|
||||
|
||||
|
||||
{@a frequency}
|
||||
|
|
@ -89,17 +89,17 @@ This cadence of releases gives you access to new features as soon as they are re
|
|||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Disclaimer: The dates are offered as general guidance and may be adjusted by us when necessary to ensure delivery of a high-quality platform.
|
||||
Disclaimer: The dates are offered as general guidance and may be adjusted by us when necessary to ensure delivery of a high-quality platform.
|
||||
|
||||
</div>
|
||||
|
||||
The following table contains our current target release dates for the next two major versions of Angular:
|
||||
The following table contains our current target release dates for the next two major versions of Angular:
|
||||
|
||||
Date | Stable Release | Compatibility
|
||||
Date | Stable Release | Compatibility
|
||||
---------------------- | -------------- | -------------
|
||||
October/November 2019 | 9.0.0 | ^8.0.0
|
||||
May 2020 | 10.0.0 | ^9.0.0
|
||||
|
||||
|
||||
Compatibility note: The primary goal of the backward compatibility promise is to ensure that changes in the core framework and tooling don't break the existing ecosystem of components and applications and don't put undue upgrade/migration burden on Angular application and component authors.
|
||||
|
||||
|
||||
|
|
@ -109,43 +109,43 @@ The following table contains our current target release dates for the next two m
|
|||
{@a support}
|
||||
## Support policy and schedule
|
||||
|
||||
All of our major releases are supported for 18 months.
|
||||
All of our major releases are supported for 18 months.
|
||||
|
||||
* 6 months of *active support*, during which regularly-scheduled updates and patches are released.
|
||||
|
||||
* 12 months of *long-term support (LTS)*, during which only critical fixes and security patches are released.
|
||||
* 12 months of *long-term support (LTS)*, during which only critical fixes and security patches are released.
|
||||
|
||||
The following table provides the status for Angular versions under support.
|
||||
The following table provides the status for Angular versions under support.
|
||||
|
||||
|
||||
Version | Status | Released | Active Ends | LTS Ends
|
||||
------- | ------ | ------------ | ------------ | ------------
|
||||
------- | ------ | ------------ | ------------ | ------------
|
||||
^8.0.0 | Active | May 28, 2019 | Nov 28, 2019 | Nov 28, 2020
|
||||
^7.0.0 | LTS | Oct 18, 2018 | Apr 18, 2019 | Apr 18, 2020
|
||||
|
||||
Angular versions ^4.0.0, ^5.0.0 and ^6.0.0 are no longer under support.
|
||||
Angular versions ^4.0.0, ^5.0.0 and ^6.0.0 are no longer under support.
|
||||
|
||||
{@a deprecation}
|
||||
## Deprecation practices
|
||||
|
||||
|
||||
Sometimes "breaking changes", such as the removal of support for select APIs and features, are necessary to innovate and stay current with new best practices, changing dependencies, or changes in the (web) platform itself.
|
||||
Sometimes "breaking changes", such as the removal of support for select APIs and features, are necessary to innovate and stay current with new best practices, changing dependencies, or changes in the (web) platform itself.
|
||||
|
||||
To make these transitions as easy as possible, we make these commitments to you:
|
||||
|
||||
* We work hard to minimize the number of breaking changes and to provide migration tools when possible.
|
||||
* We work hard to minimize the number of breaking changes and to provide migration tools when possible.
|
||||
|
||||
* We follow the deprecation policy described here, so you have time to update your apps to the latest APIs and best practices.
|
||||
|
||||
To help ensure that you have sufficient time and a clear path to update, this is our deprecation policy:
|
||||
|
||||
* **Announcement:** We announce deprecated APIs and features in the [change log](https://github.com/angular/angular/blob/master/CHANGELOG.md "Angular change log"). Deprecated APIs appear in the [documentation](api?status=deprecated) with ~~strikethrough.~~ When we announce a deprecation, we also announce a recommended update path. For convenience, [Deprecations](guide/deprecations) contains a summary of deprecated APIs and features.
|
||||
* **Announcement:** We announce deprecated APIs and features in the [change log](https://github.com/angular/angular/blob/master/CHANGELOG.md "Angular change log"). Deprecated APIs appear in the [documentation](api?status=deprecated) with ~~strikethrough.~~ When we announce a deprecation, we also announce a recommended update path. For convenience, [Deprecations](guide/deprecations) contains a summary of deprecated APIs and features.
|
||||
|
||||
|
||||
* **Deprecation period:** When an API or a feature is deprecated, it will still be present in the [next two major releases](#schedule). After that, deprecated APIs and features will be candidates for removal. A deprecation can be announced in any release, but the removal of a deprecated API or feature will happen only in major release. Until a deprecated API or feature is removed, it will be maintained according to the LTS support policy, meaning that only critical and security issues will be fixed.
|
||||
* **Deprecation period:** When an API or a feature is deprecated, it will still be present in the [next two major releases](#schedule). After that, deprecated APIs and features will be candidates for removal. A deprecation can be announced in any release, but the removal of a deprecated API or feature will happen only in major release. Until a deprecated API or feature is removed, it will be maintained according to the LTS support policy, meaning that only critical and security issues will be fixed.
|
||||
|
||||
|
||||
* **npm dependencies:** We only make npm dependency updates that require changes to your apps in a major release.
|
||||
* **npm dependencies:** We only make npm dependency updates that require changes to your apps in a major release.
|
||||
In minor releases, we update peer dependencies by expanding the supported versions, but we do not require projects to update these dependencies until a future major version. This means that during minor Angular releases, npm dependency updates within Angular applications and libraries are optional.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Routing & Navigation
|
||||
# Routing and navigation
|
||||
|
||||
The Angular **`Router`** enables navigation from one [view](guide/glossary#view) to the next
|
||||
as users perform application tasks.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Authoring Schematics
|
||||
# Authoring schematics
|
||||
|
||||
You can create your own schematics to operate on Angular projects.
|
||||
Library developers typically package schematics with their libraries in order to integrate them with the Angular CLI.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Schematics for Libraries
|
||||
# Schematics for libraries
|
||||
|
||||
When you create an Angular library, you can provide and package it with schematics that integrate it with the Angular CLI.
|
||||
With your schematics, your users can use `ng add` to install an initial version of your library,
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
{@a top}
|
||||
|
||||
# Set the Document Title
|
||||
# Set the document title
|
||||
|
||||
Your app should be able to make the browser title bar say whatever you want it to say.
|
||||
This cookbook explains how to do it.
|
||||
|
|
|
|||
|
|
@ -1,24 +1,24 @@
|
|||
# Setting up the Local Environment and Workspace
|
||||
# Setting up the local environment and workspace
|
||||
|
||||
|
||||
This guide explains how to set up your environment for Angular development using the [Angular CLI tool](cli "CLI command reference").
|
||||
It includes information about prerequisites, installing the CLI, creating an initial workspace and starter app, and running that app locally to verify your setup.
|
||||
This guide explains how to set up your environment for Angular development using the [Angular CLI tool](cli "CLI command reference").
|
||||
It includes information about prerequisites, installing the CLI, creating an initial workspace and starter app, and running that app locally to verify your setup.
|
||||
|
||||
|
||||
<div class="callout is-helpful">
|
||||
<header>Learning Angular</header>
|
||||
|
||||
If you are new to Angular, see [Getting Started](start). Getting Started helps you quickly learn the essentials of Angular, in the context of building a basic online store app. It leverages the [StackBlitz](https://stackblitz.com/) online development environment, so you don't need to set up your local environment until you're ready.
|
||||
If you are new to Angular, see [Getting Started](start). Getting Started helps you quickly learn the essentials of Angular, in the context of building a basic online store app. It leverages the [StackBlitz](https://stackblitz.com/) online development environment, so you don't need to set up your local environment until you're ready.
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
{@a devenv}
|
||||
{@a prerequisites}
|
||||
## Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
Before you begin, make sure your development environment includes `Node.js®` and an npm package manager.
|
||||
Before you begin, make sure your development environment includes `Node.js®` and an npm package manager.
|
||||
|
||||
{@a nodejs}
|
||||
### Node.js
|
||||
|
|
@ -32,9 +32,9 @@ Angular requires `Node.js` version 10.9.0 or later.
|
|||
{@a npm}
|
||||
### npm package manager
|
||||
|
||||
Angular, the Angular CLI, and Angular apps depend on features and functionality provided by libraries that are available as [npm packages](https://docs.npmjs.com/getting-started/what-is-npm). To download and install npm packages, you must have an npm package manager.
|
||||
Angular, the Angular CLI, and Angular apps depend on features and functionality provided by libraries that are available as [npm packages](https://docs.npmjs.com/getting-started/what-is-npm). To download and install npm packages, you must have an npm package manager.
|
||||
|
||||
This setup guide uses the [npm client](https://docs.npmjs.com/cli/install) command line interface, which is installed with `Node.js` by default.
|
||||
This setup guide uses the [npm client](https://docs.npmjs.com/cli/install) command line interface, which is installed with `Node.js` by default.
|
||||
|
||||
To check that you have the npm client installed, run `npm -v` in a terminal/console window.
|
||||
|
||||
|
|
@ -43,10 +43,10 @@ To check that you have the npm client installed, run `npm -v` in a terminal/cons
|
|||
|
||||
## Step 1: Install the Angular CLI
|
||||
|
||||
You use the Angular CLI
|
||||
You use the Angular CLI
|
||||
to create projects, generate application and library code, and perform a variety of ongoing development tasks such as testing, bundling, and deployment.
|
||||
|
||||
Install the Angular CLI globally.
|
||||
Install the Angular CLI globally.
|
||||
|
||||
To install the CLI using `npm`, open a terminal/console window and enter the following command:
|
||||
|
||||
|
|
@ -62,22 +62,22 @@ To install the CLI using `npm`, open a terminal/console window and enter the fol
|
|||
|
||||
## Step 2: Create a workspace and initial application
|
||||
|
||||
You develop apps in the context of an Angular [**workspace**](guide/glossary#workspace).
|
||||
You develop apps in the context of an Angular [**workspace**](guide/glossary#workspace).
|
||||
|
||||
To create a new workspace and initial starter app:
|
||||
To create a new workspace and initial starter app:
|
||||
|
||||
1. Run the CLI command `ng new` and provide the name `my-app`, as shown here:
|
||||
1. Run the CLI command `ng new` and provide the name `my-app`, as shown here:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng new my-app
|
||||
|
||||
</code-example>
|
||||
|
||||
2. The `ng new` command prompts you for information about features to include in the initial app. Accept the defaults by pressing the Enter or Return key.
|
||||
2. The `ng new` command prompts you for information about features to include in the initial app. Accept the defaults by pressing the Enter or Return key.
|
||||
|
||||
The Angular CLI installs the necessary Angular npm packages and other dependencies. This can take a few minutes.
|
||||
The Angular CLI installs the necessary Angular npm packages and other dependencies. This can take a few minutes.
|
||||
|
||||
The CLI creates a new workspace and a simple Welcome app, ready to run.
|
||||
The CLI creates a new workspace and a simple Welcome app, ready to run.
|
||||
|
||||
|
||||
{@a serve}
|
||||
|
|
@ -112,18 +112,17 @@ You will see:
|
|||
## Next steps
|
||||
|
||||
|
||||
* If you are new to Angular, see the [Getting Started](start) tutorial. Getting Started helps you quickly learn the essentials of Angular, in the context of building a basic online store app.
|
||||
* If you are new to Angular, see the [Getting Started](start) tutorial. Getting Started helps you quickly learn the essentials of Angular, in the context of building a basic online store app.
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Getting Started assumes the [StackBlitz](https://stackblitz.com/) online development environment.
|
||||
To learn how to export an app from StackBlitz to your local environment, skip ahead to the [Deployment](start/deployment "Getting Started: Deployment") section.
|
||||
|
||||
Getting Started assumes the [StackBlitz](https://stackblitz.com/) online development environment.
|
||||
To learn how to export an app from StackBlitz to your local environment, skip ahead to the [Deployment](start/deployment "Getting Started: Deployment") section.
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
* To learn more about using the Angular CLI, see the [CLI Overview](cli "CLI Overview"). In addition to creating the initial workspace and app scaffolding, you can use the CLI to generate Angular code such as components and services. The CLI supports the full development cycle, including building, testing, bundling, and deployment.
|
||||
* To learn more about using the Angular CLI, see the [CLI Overview](cli "CLI Overview"). In addition to creating the initial workspace and app scaffolding, you can use the CLI to generate Angular code such as components and services. The CLI supports the full development cycle, including building, testing, bundling, and deployment.
|
||||
|
||||
|
||||
* For more information about the Angular files generated by `ng new`, see [Workspace and Project File Structure](guide/file-structure).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Sharing Modules
|
||||
# Sharing modules
|
||||
|
||||
Creating shared modules allows you to organize and streamline your code. You can put commonly
|
||||
used directives, pipes, and components into one module and then import just that module wherever
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Static Query Migration Guide
|
||||
# Static query migration guide
|
||||
|
||||
**Important note for library authors: This migration is especially crucial for library authors to facilitate their users upgrading to version 9 when it becomes available (approx Oct 2019).**
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Structural Directives
|
||||
# Structural directives
|
||||
|
||||
<style>
|
||||
h4 {font-size: 17px !important; text-transform: none !important;}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Style Guide
|
||||
# Angular coding style guide
|
||||
|
||||
Looking for an opinionated guide to Angular syntax, conventions, and application structure?
|
||||
Step right in!
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Template Syntax
|
||||
# Template syntax
|
||||
|
||||
<style>
|
||||
h4 {font-size: 17px !important; text-transform: none !important;}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# TypeScript Configuration
|
||||
# TypeScript configuration
|
||||
|
||||
TypeScript is a primary language for Angular application development.
|
||||
It is a superset of JavaScript with design-time support for type safety and tooling.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Server-side Rendering (SSR): An intro to Angular Universal
|
||||
# Server-side rendering (SSR) with Angular Universal
|
||||
|
||||
This guide describes **Angular Universal**, a technology that renders Angular applications on the server.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Updating to Angular Version 9
|
||||
# Updating to Angular version 9
|
||||
|
||||
This guide contains everything you need to know about updating to the next Angular version.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Keeping your Angular Projects Up-to-Date
|
||||
# Keeping your Angular projects up-to-date
|
||||
|
||||
Just like Web and the entire web ecosystem, Angular is continuously improving. Angular balances continuous improvement with a strong focus on stability and making updates easy. Keeping your Angular app up-to-date enables you to take advantage of leading-edge new features, as well as optimizations and bug fixes.
|
||||
Just like Web and the entire web ecosystem, Angular is continuously improving. Angular balances continuous improvement with a strong focus on stability and making updates easy. Keeping your Angular app up-to-date enables you to take advantage of leading-edge new features, as well as optimizations and bug fixes.
|
||||
|
||||
This document contains information and resources to help you keep your Angular apps and libraries up-to-date.
|
||||
This document contains information and resources to help you keep your Angular apps and libraries up-to-date.
|
||||
|
||||
For information about our versioning policy and practices—including
|
||||
support and deprecation practices, as well as the release schedule—see [Angular versioning and releases](guide/releases "Angular versioning and releases").
|
||||
For information about our versioning policy and practices—including
|
||||
support and deprecation practices, as well as the release schedule—see [Angular versioning and releases](guide/releases "Angular versioning and releases").
|
||||
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
|
@ -18,12 +18,12 @@ If you are currently using AngularJS, see [Upgrading from AngularJS](guide/upgra
|
|||
{@a announce}
|
||||
## Getting notified of new releases
|
||||
|
||||
To be notified when new releases are available, follow [@angular](https://twitter.com/angular "@angular on Twitter") on Twitter or subscribe to the [Angular blog](https://blog.angular.io "Angular blog").
|
||||
To be notified when new releases are available, follow [@angular](https://twitter.com/angular "@angular on Twitter") on Twitter or subscribe to the [Angular blog](https://blog.angular.io "Angular blog").
|
||||
|
||||
{@a learn}
|
||||
## Learning about new features
|
||||
|
||||
What's new? What's changed? We share the most important things you need to know on the Angular blog in [release announcements]( https://blog.angular.io/tagged/release%20notes "Angular blog - release announcements").
|
||||
What's new? What's changed? We share the most important things you need to know on the Angular blog in [release announcements]( https://blog.angular.io/tagged/release%20notes "Angular blog - release announcements").
|
||||
|
||||
To review a complete list of changes, organized by version, see the [Angular change log](https://github.com/angular/angular/blob/master/CHANGELOG.md "Angular change log").
|
||||
|
||||
|
|
@ -31,15 +31,15 @@ To review a complete list of changes, organized by version, see the [Angular cha
|
|||
{@a checking-version-app}
|
||||
## Checking your version of Angular
|
||||
|
||||
To check your app's version of Angular: From within your project directory, use the `ng version` command.
|
||||
|
||||
To check your app's version of Angular: From within your project directory, use the `ng version` command.
|
||||
|
||||
|
||||
{@a checking-version-angular}
|
||||
## Finding the current version of Angular
|
||||
|
||||
The most recent stable released version of Angular appears in the [Angular documentation](https://angular.io/docs "Angular documentation") at the bottom of the left side navigation. For example, `stable (v5.2.9)`.
|
||||
|
||||
You can also find the most current version of Angular by using the CLI command [`ng update`](cli/update). By default, [`ng update`](cli/update)(without additional arguments) lists the updates that are available to you.
|
||||
You can also find the most current version of Angular by using the CLI command [`ng update`](cli/update). By default, [`ng update`](cli/update)(without additional arguments) lists the updates that are available to you.
|
||||
|
||||
|
||||
{@a updating}
|
||||
|
|
@ -47,11 +47,11 @@ You can also find the most current version of Angular by using the CLI command [
|
|||
|
||||
To make updating easy, we provide complete instructions in the interactive [Angular Update Guide](https://update.angular.io/ "Angular Update Guide").
|
||||
|
||||
The Angular Update Guide provides customized update instructions, based on the current and target versions that you specify. It includes basic and advanced update paths, to match the complexity of your applications. It also includes troubleshooting information and any recommended manual changes to help you get the most out of the new release.
|
||||
The Angular Update Guide provides customized update instructions, based on the current and target versions that you specify. It includes basic and advanced update paths, to match the complexity of your applications. It also includes troubleshooting information and any recommended manual changes to help you get the most out of the new release.
|
||||
|
||||
For simple updates, the CLI command [`ng update`](cli/update) is all you need. Without additional arguments, [`ng update`](cli/update) lists the updates that are available to you and provides recommended steps to update your application to the most current version.
|
||||
For simple updates, the CLI command [`ng update`](cli/update) is all you need. Without additional arguments, [`ng update`](cli/update) lists the updates that are available to you and provides recommended steps to update your application to the most current version.
|
||||
|
||||
[Angular Versioning and Releases](guide/releases#versioning "Angular Release Practices, Versioning") describes the level of change that you can expect based a release's version number. It also describes supported update paths.
|
||||
[Angular Versioning and Releases](guide/releases#versioning "Angular Release Practices, Versioning") describes the level of change that you can expect based a release's version number. It also describes supported update paths.
|
||||
|
||||
|
||||
{@a resources}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Upgrading for Performance
|
||||
# Upgrading for performance
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Setup for Upgrading from AngularJS
|
||||
# Setup for upgrading from AngularJS
|
||||
|
||||
<!--
|
||||
Question: Can we remove this file and instead direct readers to https://github.com/angular/quickstart/blob/master/README.md
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# User Input
|
||||
# User input
|
||||
|
||||
User actions such as clicking a link, pushing a button, and entering
|
||||
text raise DOM events.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Using Published Libraries
|
||||
# Using published libraries
|
||||
|
||||
When building Angular applications you can take advantage of sophisticated first-party libraries, such as [Angular Material](https://material.angular.io/), as well as rich ecosystem of third-party libraries.
|
||||
See the [Angular Resources](https://angular.io/resources) page for links to the most popular ones.
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Using Web Workers with Angular CLI
|
||||
# Using web workers with Angular CLI
|
||||
|
||||
[Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) allow you to run CPU intensive computations in a background thread, freeing the main thread to update the user interface.
|
||||
[Web workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) allow you to run CPU intensive computations in a background thread, freeing the main thread to update the user interface.
|
||||
|
||||
If you find your application becomes unresponsive while processing data, using Web Workers can help.
|
||||
If you find your application becomes unresponsive while processing data, using web workers can help.
|
||||
|
||||
## Adding a Web Worker
|
||||
## Adding a web worker
|
||||
|
||||
You can add a web worker anywhere in your application. If the file that contains your expensive computation is `src/app/app.component.ts`, you can add a Web Worker using `ng generate web-worker app`.
|
||||
You can add a web worker anywhere in your application. If the file that contains your expensive computation is `src/app/app.component.ts`, you can add a web worker using `ng generate web-worker app`.
|
||||
|
||||
Running this command will:
|
||||
|
||||
- configure your project to use Web Workers, if it isn't already.
|
||||
- configure your project to use web workers, if it isn't already.
|
||||
- add `src/app/app.worker.ts` with scaffolded code to receive messages:
|
||||
|
||||
<code-example language="typescript" header="src/app/app.worker.ts">
|
||||
|
|
@ -31,16 +31,16 @@ Running this command will:
|
|||
};
|
||||
worker.postMessage('hello');
|
||||
} else {
|
||||
// Web Workers are not supported in this environment.
|
||||
// Web workers are not supported in this environment.
|
||||
// You should add a fallback so that your program still executes correctly.
|
||||
}
|
||||
</code-example>
|
||||
|
||||
After the initial scaffolding, you will need to refactor your code to use the Web Worker by sending messages to and from.
|
||||
After the initial scaffolding, you will need to refactor your code to use the web worker by sending messages to and from.
|
||||
|
||||
## Caveats
|
||||
|
||||
There are two important things to keep in mind when using Web Workers in Angular projects:
|
||||
There are two important things to keep in mind when using web workers in Angular projects:
|
||||
|
||||
- Some environments or platforms, like `@angular/platform-server` used in [Server-side Rendering](guide/universal), don't support Web Workers. You have to provide a fallback mechanism to perform the computations that the worker would perform to ensure your application will work in these environments.
|
||||
- Running Angular itself in a Web Worker via [**@angular/platform-webworker**](api/platform-webworker) is not yet supported in Angular CLI.
|
||||
- Some environments or platforms, like `@angular/platform-server` used in [Server-side Rendering](guide/universal), don't support web workers. You have to provide a fallback mechanism to perform the computations that the worker would perform to ensure your application will work in these environments.
|
||||
- Running Angular itself in a web worker via [**@angular/platform-webworker**](api/platform-webworker) is not yet supported in Angular CLI.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Angular Workspace Configuration
|
||||
# Angular workspace configuration
|
||||
|
||||
A file named `angular.json` at the root level of an Angular [workspace](guide/glossary#workspace) provides workspace-wide and project-specific configuration defaults for build and development tools provided by the Angular CLI.
|
||||
Path values given in the configuration are relative to the root workspace folder.
|
||||
|
|
|
|||
Loading…
Reference in New Issue