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,7 +8,7 @@ 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
|
||||
|
@ -129,7 +129,7 @@ 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:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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,4 +1,4 @@
|
|||
# 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").
|
||||
|
@ -126,4 +126,3 @@ You will see:
|
|||
|
||||
|
||||
* 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,4 +1,4 @@
|
|||
# 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.
|
||||
|
||||
|
|
|
@ -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