Compare commits
157 Commits
7.0.2
...
mhevery-pa
Author | SHA1 | Date | |
---|---|---|---|
dce1c7cf58 | |||
2c7386c961 | |||
d5cbcef0ea | |||
b0476f308b | |||
9dc52d9d04 | |||
297dc2bc02 | |||
0cc9842bf6 | |||
54ea10288e | |||
1880c9531f | |||
13a803d4f7 | |||
f6c2db818e | |||
67789f10ef | |||
b83f1300bd | |||
6e16a17015 | |||
d744dd70e0 | |||
4e91ead40b | |||
7f39f37003 | |||
bf9ab53f12 | |||
d99f661af7 | |||
5d58a31d86 | |||
07b89902d5 | |||
ce6948fc1b | |||
38d626a3fa | |||
9b8a244a15 | |||
1bbf28ad19 | |||
3b24e0edb6 | |||
b647608c96 | |||
31c462ae3f | |||
da39fd70d2 | |||
ee0b857172 | |||
e0d6782d26 | |||
2f9e957523 | |||
38dbae9ca0 | |||
5a3077f46c | |||
d0cc019c1a | |||
26e8032bd0 | |||
84af7b065d | |||
83dc3c0ee0 | |||
5952775a03 | |||
57531737e5 | |||
3fd50f07fd | |||
4237c34c78 | |||
361eaf1888 | |||
cca89ec36e | |||
e4c7f369f2 | |||
d573a14119 | |||
ff767dd153 | |||
34c6ce6b08 | |||
6737e91974 | |||
1006eab482 | |||
a9f2952882 | |||
100c7eff25 | |||
dc7349915d | |||
213c25fb08 | |||
615a515bba | |||
838a3f204f | |||
15c2467dbd | |||
74ea4e9b5d | |||
4481571999 | |||
2132c8f461 | |||
2b3cac5b31 | |||
8d5e3e6981 | |||
30f1dc002a | |||
5da3b00222 | |||
631998b2df | |||
30d6233e83 | |||
6468711e16 | |||
d698b0eadf | |||
1f3331f5e6 | |||
b6c9678f21 | |||
4c2ce4e8ba | |||
bb0f95b6fb | |||
853faf4c71 | |||
00c7db02d1 | |||
13143b850e | |||
c1724062f1 | |||
7570f7222f | |||
f1e3d5125d | |||
3511f08a81 | |||
982bc7f2aa | |||
3903e5ebe7 | |||
0918adf39d | |||
42c331bbf2 | |||
0bae97a726 | |||
c5949f85ef | |||
24521f549c | |||
4bd9f53e8f | |||
2a78dcbd5a | |||
2ea57cdcc3 | |||
31022cbecf | |||
ce8053103e | |||
0b885ecaf7 | |||
1700bd6f08 | |||
b89bc37170 | |||
39df4dbde7 | |||
716d887e51 | |||
5b4cf38166 | |||
4c0ad5238e | |||
9e8903ada1 | |||
aa55d88408 | |||
07fc4c2464 | |||
b9bd95b3b2 | |||
3f89aeb80a | |||
6c530d3a85 | |||
03bf0d6b41 | |||
d4cee514f6 | |||
331989cea3 | |||
bbf96db2f2 | |||
72c2578d14 | |||
1a666dea61 | |||
7634c1cb31 | |||
95914a0fbf | |||
9c50891d6e | |||
624433c51d | |||
09cc458bfc | |||
efe0c5f371 | |||
d9d226087c | |||
7bad1d356d | |||
0add00a743 | |||
d557f1d9de | |||
665627e254 | |||
a609bf50ed | |||
f8195e5e3d | |||
65b209359a | |||
3a65c9ad4e | |||
77e58c6179 | |||
23d625172a | |||
c3643615fc | |||
638aaecc7d | |||
5a79decba4 | |||
225162aa6c | |||
a43b80a4c9 | |||
beebf7fe14 | |||
0ef1f7ef0d | |||
fc6dad40ac | |||
ecd473bbce | |||
8a3fd58cad | |||
8024857d4c | |||
3fa876c5e7 | |||
516515d9e3 | |||
948f507ba0 | |||
81a8ee1ddb | |||
5e58da14f0 | |||
fa8e633be5 | |||
be337a2e52 | |||
4d164b6ca4 | |||
371ffef4ce | |||
fdfedceeec | |||
9e5d440a0b | |||
0f7d2ca7a8 | |||
81c9720acb | |||
ea2cfbbd2e | |||
2326b9c294 | |||
41de0e0d98 | |||
f6a2dbf4f5 | |||
b115374601 | |||
7d82053117 |
3
.bazelignore
Normal file
3
.bazelignore
Normal file
@ -0,0 +1,3 @@
|
||||
node_modules
|
||||
dist
|
||||
aio/node_modules
|
@ -57,6 +57,6 @@ test --experimental_ui
|
||||
################################
|
||||
# Temporary Settings for Ivy #
|
||||
################################
|
||||
# to determine if the compiler used should be Ivy or ViewEngine one can use `--define=compile=local` on
|
||||
# to determine if the compiler used should be Ivy or ViewEngine one can use `--define=compile=local` on
|
||||
# any bazel target. This is a temporary flag until codebase is permanently switched to Ivy.
|
||||
build --define=compile=legacy
|
||||
build --define=compile=legacy
|
@ -12,12 +12,28 @@
|
||||
## IMPORTANT
|
||||
# If you change the `docker_image` version, also change the `cache_key` suffix and the version of
|
||||
# `com_github_bazelbuild_buildtools` in the `/WORKSPACE` file.
|
||||
var_1: &docker_image angular/ngcontainer:0.6.0
|
||||
var_2: &cache_key v2-angular-{{ .Branch }}-{{ checksum "yarn.lock" }}-0.6.0
|
||||
var_1: &docker_image angular/ngcontainer:0.7.0
|
||||
var_2: &cache_key v2-angular-{{ .Branch }}-{{ checksum "yarn.lock" }}-0.7.0
|
||||
|
||||
# Define common ENV vars
|
||||
var_3: &define_env_vars
|
||||
run: echo "export PROJECT_ROOT=$(pwd)" >> $BASH_ENV
|
||||
run:
|
||||
name: Define environment variables
|
||||
command: |
|
||||
echo "export PROJECT_ROOT=$(pwd)" | tee -a $BASH_ENV
|
||||
echo "export CI_AIO_MIN_PWA_SCORE=95" | tee -a $BASH_ENV
|
||||
# This is the branch being built; e.g. `pull/12345` for PR builds.
|
||||
echo "export CI_BRANCH=$CIRCLE_BRANCH" | tee -a $BASH_ENV
|
||||
echo "export CI_COMMIT=$CIRCLE_SHA1" | tee -a $BASH_ENV
|
||||
# `CI_COMMIT_RANGE` will only be available when `CIRCLE_COMPARE_URL` is also available,
|
||||
# i.e. on push builds (a.k.a. non-PR builds). That is fine, since we only need it in push builds.
|
||||
echo "export CI_COMMIT_RANGE=$(sed -r 's|^.*/([0-9a-f]+\.\.\.[0-9a-f]+)$|\1|i' <<< ${CIRCLE_COMPARE_URL:-})" | tee -a $BASH_ENV
|
||||
echo "export CI_PULL_REQUEST=${CIRCLE_PR_NUMBER:-false}" | tee -a $BASH_ENV
|
||||
echo "export CI_REPO_NAME=$CIRCLE_PROJECT_REPONAME" | tee -a $BASH_ENV
|
||||
echo "export CI_REPO_OWNER=$CIRCLE_PROJECT_USERNAME" | tee -a $BASH_ENV
|
||||
# WARNING: Secrets (do not print).
|
||||
echo "export CI_SECRET_AIO_DEPLOY_FIREBASE_TOKEN=$AIO_DEPLOY_TOKEN" >> $BASH_ENV
|
||||
echo "export CI_SECRET_PAYLOAD_FIREBASE_TOKEN=$ANGULAR_PAYLOAD_TOKEN" >> $BASH_ENV
|
||||
|
||||
# See remote cache documentation in /docs/BAZEL.md
|
||||
var_4: &setup-bazel-remote-cache
|
||||
@ -29,7 +45,7 @@ var_4: &setup-bazel-remote-cache
|
||||
var_5: &setup_bazel_remote_execution
|
||||
run:
|
||||
name: "Setup bazel RBE remote execution"
|
||||
command: openssl aes-256-cbc -d -in .circleci/gcp_token -k "${CIRCLE_PROJECT_REPONAME}" -out /home/circleci/.gcp_credentials && echo "export GOOGLE_APPLICATION_CREDENTIALS=/home/circleci/.gcp_credentials" >> $BASH_ENV && sudo bash -c "cat .circleci/rbe-bazel.rc >> /etc/bazel.bazelrc"
|
||||
command: openssl aes-256-cbc -d -in .circleci/gcp_token -k "$CI_REPO_NAME" -out /home/circleci/.gcp_credentials && echo "export GOOGLE_APPLICATION_CREDENTIALS=/home/circleci/.gcp_credentials" >> $BASH_ENV && sudo bash -c "cat .circleci/rbe-bazel.rc >> /etc/bazel.bazelrc"
|
||||
|
||||
# Settings common to each job
|
||||
anchor_1: &job_defaults
|
||||
@ -41,7 +57,7 @@ anchor_1: &job_defaults
|
||||
# Similar to travis behavior, but not quite the same.
|
||||
# See https://discuss.circleci.com/t/1662
|
||||
anchor_2: &post_checkout
|
||||
post: git pull --ff-only origin "refs/pull/${CIRCLE_PULL_REQUEST//*pull\//}/merge"
|
||||
post: git pull --ff-only origin "refs/pull/${CI_PULL_REQUEST//*pull\//}/merge"
|
||||
|
||||
version: 2
|
||||
jobs:
|
||||
@ -49,6 +65,7 @@ jobs:
|
||||
<<: *job_defaults
|
||||
resource_class: xlarge
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- run: sudo cp .circleci/bazel.rc /etc/bazel.bazelrc
|
||||
@ -78,16 +95,12 @@ jobs:
|
||||
|
||||
- run: bazel info release
|
||||
- run: bazel run @nodejs//:yarn
|
||||
# Use bazel query so that we explicitly ask for all buildable targets to be built as well
|
||||
# This avoids waiting for the slowest build target to finish before running the first test
|
||||
# See https://github.com/bazelbuild/bazel/issues/4257
|
||||
# NOTE: Angular developers should typically just bazel build //packages/... or bazel test //packages/...
|
||||
# Setup remote execution and run RBE-compatible tests.
|
||||
- *setup_bazel_remote_execution
|
||||
- run: bazel query --output=label //... | xargs bazel test --build_tag_filters=-ivy-only --test_tag_filters=-manual,-ivy-only,-local
|
||||
- run: bazel test //... --build_tag_filters=-ivy-only --test_tag_filters=-ivy-only,-local
|
||||
# Now run RBE incompatible tests locally.
|
||||
- run: sudo cp .circleci/bazel.rc /etc/bazel.bazelrc
|
||||
- run: bazel query --output=label //... | xargs bazel test --build_tag_filters=-ivy-only,local --test_tag_filters=-manual,-ivy-only,local
|
||||
- run: bazel test //... --build_tag_filters=-ivy-only,local --test_tag_filters=-ivy-only,local
|
||||
|
||||
# CircleCI will allow us to go back and view/download these artifacts from past builds.
|
||||
# Also we can use a service like https://buildsize.org/ to automatically track binary size of these artifacts.
|
||||
@ -113,6 +126,7 @@ jobs:
|
||||
paths:
|
||||
- "node_modules"
|
||||
- "~/bazel_repository_cache"
|
||||
|
||||
# Temporary job to test what will happen when we flip the Ivy flag to true
|
||||
test_ivy_jit:
|
||||
<<: *job_defaults
|
||||
@ -125,7 +139,7 @@ jobs:
|
||||
|
||||
- run: bazel run @yarn//:yarn
|
||||
- *setup_bazel_remote_execution
|
||||
- run: bazel query --output=label //... | xargs bazel test --define=compile=jit --build_tag_filters=ivy-jit --test_tag_filters=-manual,ivy-jit
|
||||
- run: bazel test //... --define=compile=jit --build_tag_filters=ivy-jit --test_tag_filters=ivy-jit
|
||||
|
||||
test_ivy_aot:
|
||||
<<: *job_defaults
|
||||
@ -138,30 +152,135 @@ jobs:
|
||||
|
||||
- run: bazel run @yarn//:yarn
|
||||
- *setup_bazel_remote_execution
|
||||
- run: bazel query --output=label //... | xargs bazel test --define=compile=local --build_tag_filters=ivy-local --test_tag_filters=-manual,ivy-local
|
||||
- run: bazel test //... --define=compile=aot --build_tag_filters=ivy-aot --test_tag_filters=ivy-aot
|
||||
|
||||
# This job should only be run on PR builds, where `CIRCLE_PR_NUMBER` is defined.
|
||||
test_and_deploy_aio:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
# Build aio
|
||||
- run: yarn --cwd aio build --progress=false
|
||||
# Lint the code
|
||||
- run: yarn --cwd aio lint
|
||||
# Run PWA-score tests
|
||||
# (Run before unit and e2e tests, which destroy the `dist/` directory.)
|
||||
- run:
|
||||
name: Run PWA-score tests
|
||||
command: xvfb-run --auto-servernum yarn --cwd aio test-pwa-score-localhost $CI_AIO_MIN_PWA_SCORE
|
||||
# Check the bundle sizes.
|
||||
# (Run before unit and e2e tests, which destroy the `dist/` directory.)
|
||||
- run: yarn --cwd aio payload-size
|
||||
# Run unit tests
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio test --watch=false
|
||||
# Run e2e tests
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio e2e
|
||||
# Run unit tests for Firebase redirects
|
||||
- run: yarn --cwd aio redirects-test
|
||||
# Deploy angular.io to production (if necessary)
|
||||
- run: echo "export CI_STABLE_BRANCH=$(npm info @angular/core dist-tags.latest | sed -r 's/^\s*([0-9]+\.[0-9]+)\.[0-9]+.*$/\1.x/')" | tee -a $BASH_ENV
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio deploy-production
|
||||
|
||||
test_aio_local:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- attach_workspace:
|
||||
at: dist
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
# Build aio (with local Angular packages)
|
||||
- run: yarn --cwd aio build-local --progress=false
|
||||
# Run PWA-score tests
|
||||
# (Run before unit and e2e tests, which destroy the `dist/` directory.)
|
||||
- run:
|
||||
name: Run PWA-score tests
|
||||
command: xvfb-run --auto-servernum yarn --cwd aio test-pwa-score-localhost $CI_AIO_MIN_PWA_SCORE
|
||||
# Run unit tests
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio test --watch=false
|
||||
# Run e2e tests
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio e2e
|
||||
|
||||
test_aio_tools:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- attach_workspace:
|
||||
at: dist
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
# Install
|
||||
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
|
||||
- run: yarn --cwd aio extract-cli-command-docs
|
||||
# Run tools tests
|
||||
- run: yarn --cwd aio tools-test
|
||||
- run: ./aio/aio-builds-setup/scripts/test.sh
|
||||
|
||||
test_docs_examples_0:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- attach_workspace:
|
||||
at: dist
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
# Install root
|
||||
- run: yarn install --frozen-lockfile --non-interactive
|
||||
# Install aio
|
||||
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
|
||||
# Run examples tests
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio example-e2e --setup --local --shard=0/2
|
||||
|
||||
test_docs_examples_1:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- attach_workspace:
|
||||
at: dist
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
# Install root
|
||||
- run: yarn install --frozen-lockfile --non-interactive
|
||||
# Install aio
|
||||
- run: yarn --cwd aio install --frozen-lockfile --non-interactive
|
||||
# Run examples tests
|
||||
- run: xvfb-run --auto-servernum yarn --cwd aio example-e2e --setup --local --shard=1/2
|
||||
|
||||
# This job should only be run on PR builds, where `CI_PULL_REQUEST` is not `false`.
|
||||
aio_preview:
|
||||
<<: *job_defaults
|
||||
environment:
|
||||
AIO_SNAPSHOT_ARTIFACT_PATH: &aio_preview_artifact_path 'aio/tmp/snapshot.tgz'
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
- run: yarn install --frozen-lockfile --non-interactive
|
||||
- run: ./aio/scripts/build-artifacts.sh $AIO_SNAPSHOT_ARTIFACT_PATH $CIRCLE_PR_NUMBER $CIRCLE_SHA1
|
||||
- run: ./aio/scripts/build-artifacts.sh $AIO_SNAPSHOT_ARTIFACT_PATH $CI_PULL_REQUEST $CI_COMMIT
|
||||
- store_artifacts:
|
||||
path: *aio_preview_artifact_path
|
||||
# The `destination` needs to be kept in synch with the value of
|
||||
# `AIO_ARTIFACT_PATH` in `aio/aio-builds-setup/Dockerfile`
|
||||
destination: aio/dist/aio-snapshot.tgz
|
||||
|
||||
# This job should only be run on PR builds, where `CIRCLE_PR_NUMBER` is defined.
|
||||
# This job should only be run on PR builds, where `CI_PULL_REQUEST` is not `false`.
|
||||
test_aio_preview:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- restore_cache:
|
||||
@ -169,9 +288,7 @@ jobs:
|
||||
- run: yarn install --cwd aio --frozen-lockfile --non-interactive
|
||||
- run:
|
||||
name: Wait for preview and run tests
|
||||
command: |
|
||||
source "./scripts/ci/env.sh" print
|
||||
xvfb-run --auto-servernum node aio/scripts/test-preview.js $CIRCLE_PR_NUMBER $CIRCLE_SHA1 $AIO_MIN_PWA_SCORE
|
||||
command: xvfb-run --auto-servernum node aio/scripts/test-preview.js $CI_PULL_REQUEST $CI_COMMIT $CI_AIO_MIN_PWA_SCORE
|
||||
|
||||
# This job exists only for backwards-compatibility with old scripts and tests
|
||||
# that rely on the pre-Bazel dist/packages-dist layout.
|
||||
@ -199,7 +316,7 @@ jobs:
|
||||
paths:
|
||||
- packages-dist
|
||||
- packages-dist-ivy-jit
|
||||
- packages-dist-ivy-local
|
||||
- packages-dist-ivy-aot
|
||||
|
||||
# We run the integration tests outside of Bazel for now.
|
||||
# They are a separate workflow job so that they can be easily re-run.
|
||||
@ -226,15 +343,16 @@ jobs:
|
||||
publish_snapshot:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
# See below - ideally this job should not trigger for non-upstream builds.
|
||||
# But since it does, we have to check this condition.
|
||||
- run:
|
||||
name: Skip this job for Pull Requests and Fork builds
|
||||
# Note, `|| true` on the end makes this step always exit 0
|
||||
command: '[[
|
||||
-v CIRCLE_PR_NUMBER
|
||||
|| "$CIRCLE_PROJECT_USERNAME" != "angular"
|
||||
|| "$CIRCLE_PROJECT_REPONAME" != "angular"
|
||||
"$CI_PULL_REQUEST" != "false"
|
||||
|| "$CI_REPO_OWNER" != "angular"
|
||||
|| "$CI_REPO_NAME" != "angular"
|
||||
]] && circleci step halt || true'
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
@ -252,15 +370,14 @@ jobs:
|
||||
aio_monitoring:
|
||||
<<: *job_defaults
|
||||
steps:
|
||||
- *define_env_vars
|
||||
- checkout:
|
||||
<<: *post_checkout
|
||||
- restore_cache:
|
||||
key: *cache_key
|
||||
- run:
|
||||
name: Run tests against the deployed apps
|
||||
command: |
|
||||
source "./scripts/ci/env.sh" print
|
||||
xvfb-run --auto-servernum ./aio/scripts/test-production.sh $AIO_MIN_PWA_SCORE
|
||||
command: xvfb-run --auto-servernum ./aio/scripts/test-production.sh $CI_AIO_MIN_PWA_SCORE
|
||||
|
||||
workflows:
|
||||
version: 2
|
||||
@ -271,6 +388,19 @@ workflows:
|
||||
- test_ivy_jit
|
||||
- test_ivy_aot
|
||||
- build-packages-dist
|
||||
- test_and_deploy_aio
|
||||
- test_aio_local:
|
||||
requires:
|
||||
- build-packages-dist
|
||||
- test_aio_tools:
|
||||
requires:
|
||||
- build-packages-dist
|
||||
- test_docs_examples_0:
|
||||
requires:
|
||||
- build-packages-dist
|
||||
- test_docs_examples_1:
|
||||
requires:
|
||||
- build-packages-dist
|
||||
- aio_preview:
|
||||
# Only run on PR builds. (There can be no previews for non-PR builds.)
|
||||
filters:
|
||||
@ -293,6 +423,10 @@ workflows:
|
||||
- test_ivy_jit
|
||||
- test_ivy_aot
|
||||
- integration_test
|
||||
# Only publish if `aio`/`docs` tests using the locally built Angular packages pass
|
||||
- test_aio_local
|
||||
- test_docs_examples_0
|
||||
- test_docs_examples_1
|
||||
# Get the artifacts to publish from the build-packages-dist job
|
||||
# since the publishing script expects the legacy outputs layout.
|
||||
- build-packages-dist
|
||||
|
Binary file not shown.
30
.github/PULL_REQUEST_TEMPLATE.md
vendored
30
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -10,17 +10,17 @@ Please check if your PR fulfills the following requirements:
|
||||
What kind of change does this PR introduce?
|
||||
|
||||
<!-- Please check the one that applies to this PR using "x". -->
|
||||
```
|
||||
[ ] Bugfix
|
||||
[ ] Feature
|
||||
[ ] Code style update (formatting, local variables)
|
||||
[ ] Refactoring (no functional changes, no api changes)
|
||||
[ ] Build related changes
|
||||
[ ] CI related changes
|
||||
[ ] Documentation content changes
|
||||
[ ] angular.io application / infrastructure changes
|
||||
[ ] Other... Please describe:
|
||||
```
|
||||
|
||||
- [ ] Bugfix
|
||||
- [ ] Feature
|
||||
- [ ] Code style update (formatting, local variables)
|
||||
- [ ] Refactoring (no functional changes, no api changes)
|
||||
- [ ] Build related changes
|
||||
- [ ] CI related changes
|
||||
- [ ] Documentation content changes
|
||||
- [ ] angular.io application / infrastructure changes
|
||||
- [ ] Other... Please describe:
|
||||
|
||||
|
||||
## What is the current behavior?
|
||||
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
|
||||
@ -32,10 +32,10 @@ Issue Number: N/A
|
||||
|
||||
|
||||
## Does this PR introduce a breaking change?
|
||||
```
|
||||
[ ] Yes
|
||||
[ ] No
|
||||
```
|
||||
|
||||
- [ ] Yes
|
||||
- [ ] No
|
||||
|
||||
|
||||
<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. -->
|
||||
|
||||
|
21
.github/angular-robot.yml
vendored
21
.github/angular-robot.yml
vendored
@ -39,6 +39,7 @@ merge:
|
||||
- "packages/**"
|
||||
# list of patterns to ignore for the files changed by the PR
|
||||
exclude:
|
||||
- "packages/bazel/*.bzl"
|
||||
- "packages/language-service/**"
|
||||
- "**/.gitignore"
|
||||
- "**/.gitkeep"
|
||||
@ -124,3 +125,23 @@ triage:
|
||||
-
|
||||
- "type: RFC / Discussion / question"
|
||||
- "comp: *"
|
||||
|
||||
# options for the triage PR plugin
|
||||
triagePR:
|
||||
# set to true to disable
|
||||
disabled: false
|
||||
# number of the milestone to apply when the PR has not been triaged yet
|
||||
needsTriageMilestone: 83,
|
||||
# number of the milestone to apply when the PR is triaged
|
||||
defaultMilestone: 82,
|
||||
# arrays of labels that determine if a PR has been triaged by the caretaker
|
||||
l1TriageLabels:
|
||||
-
|
||||
- "comp: *"
|
||||
# arrays of labels that determine if a PR has been fully triaged
|
||||
l2TriageLabels:
|
||||
-
|
||||
- "type: *"
|
||||
- "effort*"
|
||||
- "risk*"
|
||||
- "comp: *"
|
||||
|
1
.gitignore
vendored
1
.gitignore
vendored
@ -14,7 +14,6 @@ pubspec.lock
|
||||
.settings/
|
||||
*.swo
|
||||
modules/.settings
|
||||
.bazelrc
|
||||
.vscode
|
||||
modules/.vscode
|
||||
|
||||
|
@ -87,10 +87,10 @@ groups:
|
||||
files:
|
||||
include:
|
||||
- "WORKSPACE"
|
||||
- ".bazel*"
|
||||
- "*.bazel"
|
||||
- "*.bzl"
|
||||
- "packages/bazel/*"
|
||||
- "tools/bazel.rc"
|
||||
- "/docs/BAZEL.md"
|
||||
users:
|
||||
- alexeagle #primary
|
||||
@ -108,7 +108,6 @@ groups:
|
||||
- "*.lock"
|
||||
- "tools/*"
|
||||
exclude:
|
||||
- "tools/bazel.rc"
|
||||
- "tools/public_api_guard/*"
|
||||
- "aio/*"
|
||||
users:
|
||||
@ -277,6 +276,9 @@ groups:
|
||||
- "aio/content/guide/forms.md"
|
||||
- "aio/content/examples/forms/*"
|
||||
- "aio/content/images/guide/forms/*"
|
||||
- "aio/content/guide/forms-overview.md"
|
||||
- "aio/content/examples/forms-overview/*"
|
||||
- "aio/content/images/guide/forms-overview/*"
|
||||
- "aio/content/guide/form-validation.md"
|
||||
- "aio/content/examples/form-validation/*"
|
||||
- "aio/content/images/guide/form-validation/*"
|
||||
|
16
.travis.yml
16
.travis.yml
@ -30,14 +30,6 @@ env:
|
||||
# GITHUB_TOKEN_ANGULAR=<github token, a personal access token of the angular-builds account, account access in valentine>
|
||||
# This is needed for the e2e Travis matrix task to publish packages to github for continuous packages delivery.
|
||||
- secure: "aCdHveZuY8AT4Jr1JoJB4LxZsnGWRe/KseZh1YXYe5UtufFCtTVHvUcLn0j2aLBF0KpdyS+hWf0i4np9jthKu2xPKriefoPgCMpisYeC0MFkwbmv+XlgkUbgkgVZMGiVyX7DCYXVahxIoOUjVMEDCbNiHTIrfEuyq24U3ok2tHc="
|
||||
# FIREBASE_TOKEN
|
||||
# This is needed for publishing builds to the "aio-staging" and "angular-io" firebase projects.
|
||||
# This token was generated using the aio-deploy@angular.io account using `firebase login:ci` and password from valentine
|
||||
- secure: "L5CyQmpwWtoR4Qi4xlWQh/cL1M6ZeJL4W4QAr4HdKFMgYt9h+Whqkymyh2NxwmCbPvWa7yUd+OiLQUDCY7L2VIg16hTwoe2CgYDyQA0BEwLzxtRrJXl93TfwMlrUx5JSIzAccD6D4sjtz8kSFMomK2Nls33xOXOukwyhVMjd0Cg="
|
||||
# ANGULAR_PAYLOAD_FIREBASE_TOKEN
|
||||
# This is for payload size data to "angular-payload-size" firebase project
|
||||
# This token was generated using the payload@angular.io account using `firebase login:ci` and password from valentine
|
||||
- secure: "SxotP/ymNy6uWAVbfwM9BlwETPEBpkRvU/F7fCtQDDic99WfQHzzUSQqHTk8eKk3GrGAOSL09vT0WfStQYEIGEoS5UHWNgOnelxhw+d5EnaoB8vQ0dKQBTK092hQg4feFprr+B/tCasyMV6mVwpUzZMbIJNn/Rx7H5g1bp+Gkfg="
|
||||
matrix:
|
||||
# Order: a slower build first, so that we don't occupy an idle travis worker waiting for others to complete.
|
||||
- CI_MODE=e2e
|
||||
@ -47,16 +39,10 @@ env:
|
||||
# - CI_MODE=browserstack_required
|
||||
- CI_MODE=saucelabs_optional
|
||||
- CI_MODE=browserstack_optional
|
||||
- CI_MODE=aio_tools_test
|
||||
- CI_MODE=aio
|
||||
- CI_MODE=aio_local
|
||||
- CI_MODE=aio_e2e AIO_SHARD=0
|
||||
- CI_MODE=aio_e2e AIO_SHARD=1
|
||||
|
||||
matrix:
|
||||
fast_finish: true
|
||||
allow_failures:
|
||||
- env: "CI_MODE=aio_local"
|
||||
- env: "CI_MODE=saucelabs_optional"
|
||||
- env: "CI_MODE=browserstack_optional"
|
||||
|
||||
@ -70,8 +56,6 @@ install:
|
||||
script:
|
||||
- ./scripts/ci/build.sh
|
||||
- ./scripts/ci/test.sh
|
||||
# deploy is part of 'script' and not 'after_success' so that we fail the build if the deployment fails
|
||||
- ./scripts/ci/deploy.sh
|
||||
- ./scripts/ci/angular.sh
|
||||
# all the scripts under this line will not quickly abort in case ${TRAVIS_TEST_RESULT} is 1 (job failure)
|
||||
- ./scripts/ci/cleanup.sh
|
||||
|
43
BUILD.bazel
43
BUILD.bazel
@ -15,19 +15,14 @@ alias(
|
||||
actual = "@nodejs//:yarn",
|
||||
)
|
||||
|
||||
alias(
|
||||
name = "node_modules",
|
||||
actual = "@angular_deps//:node_modules",
|
||||
)
|
||||
|
||||
filegroup(
|
||||
name = "web_test_bootstrap_scripts",
|
||||
# do not sort
|
||||
srcs = [
|
||||
"@angular_deps//:node_modules/reflect-metadata/Reflect.js",
|
||||
"@angular_deps//:node_modules/zone.js/dist/zone.js",
|
||||
"@angular_deps//:node_modules/zone.js/dist/zone-testing.js",
|
||||
"@angular_deps//:node_modules/zone.js/dist/task-tracking.js",
|
||||
"@ngdeps//node_modules/reflect-metadata:Reflect.js",
|
||||
"@ngdeps//node_modules/zone.js:dist/zone.js",
|
||||
"@ngdeps//node_modules/zone.js:dist/zone-testing.js",
|
||||
"@ngdeps//node_modules/zone.js:dist/task-tracking.js",
|
||||
"//:test-events.js",
|
||||
],
|
||||
)
|
||||
@ -35,11 +30,29 @@ filegroup(
|
||||
filegroup(
|
||||
name = "angularjs_scripts",
|
||||
srcs = [
|
||||
"@angular_deps//:node_modules/angular-1.5/angular.js",
|
||||
"@angular_deps//:node_modules/angular-1.6/angular.js",
|
||||
"@angular_deps//:node_modules/angular-mocks-1.5/angular-mocks.js",
|
||||
"@angular_deps//:node_modules/angular-mocks-1.6/angular-mocks.js",
|
||||
"@angular_deps//:node_modules/angular-mocks/angular-mocks.js",
|
||||
"@angular_deps//:node_modules/angular/angular.js",
|
||||
"@ngdeps//node_modules/angular:angular.js",
|
||||
"@ngdeps//node_modules/angular-1.5:angular.js",
|
||||
"@ngdeps//node_modules/angular-1.6:angular.js",
|
||||
"@ngdeps//node_modules/angular-mocks:angular-mocks.js",
|
||||
"@ngdeps//node_modules/angular-mocks-1.5:angular-mocks.js",
|
||||
"@ngdeps//node_modules/angular-mocks-1.6:angular-mocks.js",
|
||||
],
|
||||
)
|
||||
|
||||
load("@build_bazel_rules_nodejs//:defs.bzl", "nodejs_binary")
|
||||
|
||||
# A nodejs_binary for @angular/bazel/ngc-wrapped to use by default in
|
||||
# ng_module that depends on @npm//@angular/bazel instead of the
|
||||
# output of the //packages/bazel/src/ngc-wrapped ts_library rule. This
|
||||
# default is for downstream users that depend on the @angular/bazel npm
|
||||
# package. The generated @npm//@angular/bazel/ngc-wrapped target
|
||||
# does not work because it does not have the node `--expose-gc` flag
|
||||
# set which is required to support the call to `global.gc()`.
|
||||
nodejs_binary(
|
||||
name = "@angular/bazel/ngc-wrapped",
|
||||
configuration_env_vars = ["compile"],
|
||||
data = ["@npm//@angular/bazel"],
|
||||
entry_point = "@angular/bazel/src/ngc-wrapped/index.js",
|
||||
install_source_map_support = False,
|
||||
templated_args = ["--node_options=--expose-gc"],
|
||||
)
|
||||
|
237
CHANGELOG.md
237
CHANGELOG.md
@ -1,8 +1,92 @@
|
||||
<a name="7.0.0-rc.1"></a>
|
||||
# [7.0.0-rc.1](https://github.com/angular/angular/compare/7.0.0-rc.0...7.0.0-rc.1) (2018-10-10)
|
||||
<a name="7.1.0-beta.0"></a>
|
||||
# [7.1.0-beta.0](https://github.com/angular/angular/compare/7.0.0-rc.1...7.1.0-beta.0) (2018-10-24)
|
||||
|
||||
|
||||
This version includes Ivy features and internal refactorings. There are no user-facing changes.
|
||||
### Bug Fixes
|
||||
|
||||
* **core:** allow null value for renderer setElement(…) ([#17065](https://github.com/angular/angular/issues/17065)) ([ff15043](https://github.com/angular/angular/commit/ff15043)), closes [#13686](https://github.com/angular/angular/issues/13686)
|
||||
* **router:** fix regression where navigateByUrl promise didn't resolve on CanLoad failure ([#26455](https://github.com/angular/angular/issues/26455)) ([1c9b065](https://github.com/angular/angular/commit/1c9b065)), closes [#26284](https://github.com/angular/angular/issues/26284)
|
||||
* **service-worker:** clean up caches from old SW versions ([#26319](https://github.com/angular/angular/issues/26319)) ([2326b9c](https://github.com/angular/angular/commit/2326b9c))
|
||||
* **upgrade:** properly destroy upgraded component elements and descendants ([#26209](https://github.com/angular/angular/issues/26209)) ([071934e](https://github.com/angular/angular/commit/071934e)), closes [#26208](https://github.com/angular/angular/issues/26208)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **router:** add prioritizedGuardValue operator optimization and allowing UrlTree return from guard ([#26478](https://github.com/angular/angular/issues/26478)) ([fdfedce](https://github.com/angular/angular/commit/fdfedce))
|
||||
|
||||
|
||||
|
||||
<a name="7.0.1"></a>
|
||||
## [7.0.1](https://github.com/angular/angular/compare/7.0.0...7.0.1) (2018-10-24)
|
||||
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0"></a>
|
||||
# [7.0.0](https://github.com/angular/angular/compare/7.0.0-rc.1...7.0.0) (2018-10-18)
|
||||
|
||||
|
||||
### Release Highlights & Update instructions
|
||||
|
||||
To learn about the release highlights and our new CLI-powered update workflow for your projects please check out the [v7 release announcement](https://blog.angular.io/version-7-of-angular-cli-prompts-virtual-scroll-drag-and-drop-and-more-c594e22e7b8c).
|
||||
|
||||
|
||||
### Dependency updates
|
||||
|
||||
* @angular/core now depends on
|
||||
* TypeScript 3.1
|
||||
* RxJS 6.3
|
||||
* @angular/platform-server now depends on Domino 2.1
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **core:** add DoBootstrap interface. ([#24558](https://github.com/angular/angular/issues/24558)) ([732026c](https://github.com/angular/angular/commit/732026c)), closes [#24557](https://github.com/angular/angular/issues/24557)
|
||||
* **compiler:** add "original" placeholder value on extracted XMB ([#25079](https://github.com/angular/angular/issues/25079)) ([e99d860](https://github.com/angular/angular/commit/e99d860))
|
||||
* **compiler-cli:** add support to extend `angularCompilerOptions` ([#22717](https://github.com/angular/angular/issues/22717)) ([d7e5bbf](https://github.com/angular/angular/commit/d7e5bbf)), closes [#22684](https://github.com/angular/angular/issues/22684)
|
||||
* **bazel:** add additional parameters to `ts_api_guardian_test` def ([#25694](https://github.com/angular/angular/issues/25694)) ([2a21ca0](https://github.com/angular/angular/commit/2a21ca0))
|
||||
* **elements:** enable Shadow DOM v1 and slots ([#24861](https://github.com/angular/angular/issues/24861)) ([c9844a2](https://github.com/angular/angular/commit/c9844a2))
|
||||
* **platform-server:** update domino to v2.1.0 ([#25564](https://github.com/angular/angular/issues/25564)) ([3fb0da2](https://github.com/angular/angular/commit/3fb0da2))
|
||||
* **router:** warn if navigation triggered outside Angular zone ([#24959](https://github.com/angular/angular/issues/24959)) ([010e35d](https://github.com/angular/angular/commit/010e35d)), closes [#15770](https://github.com/angular/angular/issues/15770) [#15946](https://github.com/angular/angular/issues/15946) [#24728](https://github.com/angular/angular/issues/24728)
|
||||
* **router:** add UrlSegment[] to CanLoad interface ([#13127](https://github.com/angular/angular/issues/13127)) ([07d8d39](https://github.com/angular/angular/commit/07d8d39)), closes [#12411](https://github.com/angular/angular/issues/12411)
|
||||
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* add mappings for ngfactory & ngsummary files to their module names in aot summary resolver ([#25335](https://github.com/angular/angular/issues/25335)) ([02e201a](https://github.com/angular/angular/commit/02e201a))
|
||||
* **bazel:** Cache fileNameToModuleName lookups ([#25731](https://github.com/angular/angular/issues/25731)) ([f394ba0](https://github.com/angular/angular/commit/f394ba0))
|
||||
* **bazel:** allow compile_strategy to be (privately) imported ([#25080](https://github.com/angular/angular/issues/25080)) ([0d1d589](https://github.com/angular/angular/commit/0d1d589))
|
||||
* **bazel:** correct type concatenated to devmode_js ([#25467](https://github.com/angular/angular/issues/25467)) ([fb2c524](https://github.com/angular/angular/commit/fb2c524))
|
||||
* **bazel:** move bazel managed runtime deps for downstream usage ([#25690](https://github.com/angular/angular/issues/25690)) ([6ed7993](https://github.com/angular/angular/commit/6ed7993))
|
||||
* **bazel:** only lookup amd module-name tags in .d.ts files ([#25710](https://github.com/angular/angular/issues/25710)) ([42072c4](https://github.com/angular/angular/commit/42072c4))
|
||||
* **bazel:** protractor rule should include *.e2e-spec.js ([#25701](https://github.com/angular/angular/issues/25701)) ([3809e0f](https://github.com/angular/angular/commit/3809e0f))
|
||||
* **bazel:** specify the package and lock files using the workspace ([#25694](https://github.com/angular/angular/issues/25694)) ([ddc1335](https://github.com/angular/angular/commit/ddc1335))
|
||||
* **benchpress:** Use performance.mark() instead of console.time() ([#24114](https://github.com/angular/angular/issues/24114)) ([06d0400](https://github.com/angular/angular/commit/06d0400))
|
||||
* **common:** register locale data for all equivalent closure locales ([#25867](https://github.com/angular/angular/issues/25867)) ([d83f9d4](https://github.com/angular/angular/commit/d83f9d4))
|
||||
* **compiler-cli:** correct realPath to realpath. ([#25023](https://github.com/angular/angular/issues/25023)) ([01e6dab](https://github.com/angular/angular/commit/01e6dab))
|
||||
* **compiler-cli:** use the oldProgram option in watch mode ([#21364](https://github.com/angular/angular/issues/21364)) ([c6e5b97](https://github.com/angular/angular/commit/c6e5b97)), closes [#21361](https://github.com/angular/angular/issues/21361)
|
||||
* **compiler:** Fix look up of entryComponents in AOT Summaries ([#24892](https://github.com/angular/angular/issues/24892)) ([00d3666](https://github.com/angular/angular/commit/00d3666))
|
||||
* **compiler:** add hostVars and support pure functions in host bindings ([#25626](https://github.com/angular/angular/issues/25626)) ([b424b31](https://github.com/angular/angular/commit/b424b31))
|
||||
* **compiler:** update compiler to flatten nested template fns ([#24943](https://github.com/angular/angular/issues/24943)) ([fe14f18](https://github.com/angular/angular/commit/fe14f18))
|
||||
* **compiler:** update compiler to generate new slot allocations ([#25607](https://github.com/angular/angular/issues/25607)) ([27e2039](https://github.com/angular/angular/commit/27e2039))
|
||||
* **core:** In Testability.whenStable update callback, pass more complete ([#25010](https://github.com/angular/angular/issues/25010)) ([16c03c0](https://github.com/angular/angular/commit/16c03c0))
|
||||
* **core:** add missing `peerDependency ` to `[@angular](https://github.com/angular)/compiler` ([#26033](https://github.com/angular/angular/issues/26033)) ([549de1e](https://github.com/angular/angular/commit/549de1e)), closes [/github.com/angular/angular/commit/919f42fea1df4b9e38b7d688aef5f2de668e9d3e#diff-58563046c4439699f2e6a89187099a54](https://github.com//github.com/angular/angular/commit/919f42fea1df4b9e38b7d688aef5f2de668e9d3e/issues/diff-58563046c4439699f2e6a89187099a54)
|
||||
* **core:** allow null value for renderer setElement(…) ([#17065](https://github.com/angular/angular/issues/17065)) ([ff15043](https://github.com/angular/angular/commit/ff15043)), closes [#13686](https://github.com/angular/angular/issues/13686)
|
||||
* **core:** do not clear element content when using shadow dom ([#24861](https://github.com/angular/angular/issues/24861)) ([6e828bb](https://github.com/angular/angular/commit/6e828bb))
|
||||
* **core:** size regression with closure compiler ([#25531](https://github.com/angular/angular/issues/25531)) ([1f59f2f](https://github.com/angular/angular/commit/1f59f2f))
|
||||
* **core:** throw error message when @Output not initialized ([#19116](https://github.com/angular/angular/issues/19116)) ([adf510f](https://github.com/angular/angular/commit/adf510f)), closes [#3664](https://github.com/angular/angular/issues/3664)
|
||||
* **elements:** add compiler dependency ([#24861](https://github.com/angular/angular/issues/24861)) ([6143da6](https://github.com/angular/angular/commit/6143da6))
|
||||
* **elements:** add compiler to integration ([#24861](https://github.com/angular/angular/issues/24861)) ([a080ffc](https://github.com/angular/angular/commit/a080ffc))
|
||||
* **elements:** strict null checks ([#24861](https://github.com/angular/angular/issues/24861)) ([a8210d0](https://github.com/angular/angular/commit/a8210d0))
|
||||
* **router:** fix regression where navigateByUrl promise didn't resolve on CanLoad failure ([#26455](https://github.com/angular/angular/issues/26455)) ([1c9b065](https://github.com/angular/angular/commit/1c9b065)), closes [#26284](https://github.com/angular/angular/issues/26284)
|
||||
* **router:** mount correct component if router outlet was not instantiated and if using a route reuse strategy ([#25313](https://github.com/angular/angular/issues/25313)) ([#25314](https://github.com/angular/angular/issues/25314)) ([8dc2b11](https://github.com/angular/angular/commit/8dc2b11))
|
||||
* **router:** take base uri into account in `setUpLocationSync()` ([#20244](https://github.com/angular/angular/issues/20244)) ([ba1e25f](https://github.com/angular/angular/commit/ba1e25f)), closes [#20061](https://github.com/angular/angular/issues/20061)
|
||||
* **service-worker:** clean up caches from old SW versions ([#26319](https://github.com/angular/angular/issues/26319)) ([00b5c7b](https://github.com/angular/angular/commit/00b5c7b))
|
||||
* **service-worker:** do not blow up when caches are unwritable ([#26042](https://github.com/angular/angular/issues/26042)) ([2bd767c](https://github.com/angular/angular/commit/2bd767c))
|
||||
* **upgrade:** properly destroy upgraded component elements and descendants ([#26209](https://github.com/angular/angular/issues/26209)) ([071934e](https://github.com/angular/angular/commit/071934e)), closes [#26208](https://github.com/angular/angular/issues/26208)
|
||||
* **upgrade:** trigger `$destroy` event on upgraded component element ([#25357](https://github.com/angular/angular/issues/25357)) ([2a672a9](https://github.com/angular/angular/commit/2a672a9)), closes [#25334](https://github.com/angular/angular/issues/25334)
|
||||
|
||||
|
||||
|
||||
|
||||
@ -17,95 +101,11 @@ This version includes Ivy features and internal refactorings. There are no user-
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0-rc.0"></a>
|
||||
# [7.0.0-rc.0](https://github.com/angular/angular/compare/7.0.0-beta.7...7.0.0-rc.0) (2018-09-28)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* add support for TypeScript 3.1 ([#26151](https://github.com/angular/angular/issues/26151)) ([9993c72](https://github.com/angular/angular/commit/9993c72))
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0-beta.7"></a>
|
||||
# [7.0.0-beta.7](https://github.com/angular/angular/compare/7.0.0-beta.6...7.0.0-beta.7) (2018-09-26)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **core:** add missing `peerDependency ` to `[@angular](https://github.com/angular)/compiler` ([#26033](https://github.com/angular/angular/issues/26033)) ([549de1e](https://github.com/angular/angular/commit/549de1e)), closes [/github.com/angular/angular/commit/919f42fea1df4b9e38b7d688aef5f2de668e9d3e#diff-58563046c4439699f2e6a89187099a54](https://github.com//github.com/angular/angular/commit/919f42fea1df4b9e38b7d688aef5f2de668e9d3e/issues/diff-58563046c4439699f2e6a89187099a54)
|
||||
* **service-worker:** do not blow up when caches are unwritable ([#26042](https://github.com/angular/angular/issues/26042)) ([2bd767c](https://github.com/angular/angular/commit/2bd767c))
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **compiler-cli:** add support to extend `angularCompilerOptions` ([#22717](https://github.com/angular/angular/issues/22717)) ([d7e5bbf](https://github.com/angular/angular/commit/d7e5bbf)), closes [#22684](https://github.com/angular/angular/issues/22684)
|
||||
* **platform-server:** update domino to v2.1.0 ([#25564](https://github.com/angular/angular/issues/25564)) ([3fb0da2](https://github.com/angular/angular/commit/3fb0da2))
|
||||
|
||||
|
||||
|
||||
<a name="6.1.9"></a>
|
||||
## [6.1.9](https://github.com/angular/angular/compare/6.1.8...6.1.9) (2018-09-26)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **service-worker:** do not blow up when caches are unwritable ([#26042](https://github.com/angular/angular/issues/26042)) ([a169743](https://github.com/angular/angular/commit/a169743))
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0-beta.6"></a>
|
||||
# [7.0.0-beta.6](https://github.com/angular/angular/compare/7.0.0-beta.5...7.0.0-beta.6) (2018-09-19)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **bazel:** specify the package and lock files using the workspace ([#25694](https://github.com/angular/angular/issues/25694)) ([ddc1335](https://github.com/angular/angular/commit/ddc1335))
|
||||
* **common:** register locale data for all equivalent closure locales ([#25867](https://github.com/angular/angular/issues/25867)) ([d83f9d4](https://github.com/angular/angular/commit/d83f9d4))
|
||||
* **compiler:** Fix look up of entryComponents in AOT Summaries ([#24892](https://github.com/angular/angular/issues/24892)) ([00d3666](https://github.com/angular/angular/commit/00d3666))
|
||||
* **ivy:** add [@nocollapse](https://github.com/nocollapse) when writing closure-annotated code ([#25775](https://github.com/angular/angular/issues/25775)) ([a0c4b2d](https://github.com/angular/angular/commit/a0c4b2d))
|
||||
* **ivy:** don't accidently read the inherited definition ([#25736](https://github.com/angular/angular/issues/25736)) ([d5bd86a](https://github.com/angular/angular/commit/d5bd86a)), closes [#24011](https://github.com/angular/angular/issues/24011) [#25026](https://github.com/angular/angular/issues/25026)
|
||||
* **ivy:** ensure Ivy *Ref classes derive from view engine equivalents ([#25775](https://github.com/angular/angular/issues/25775)) ([a9099e8](https://github.com/angular/angular/commit/a9099e8))
|
||||
* **ivy:** events should not mark views dirty by default ([#25969](https://github.com/angular/angular/issues/25969)) ([5653874](https://github.com/angular/angular/commit/5653874))
|
||||
* **ivy:** ngcc should compile entry-points in the correct order ([#25862](https://github.com/angular/angular/issues/25862)) ([9b1bb37](https://github.com/angular/angular/commit/9b1bb37))
|
||||
* **ivy:** use proper sanitizer names ([#25817](https://github.com/angular/angular/issues/25817)) ([21009b0](https://github.com/angular/angular/commit/21009b0)), closes [#25816](https://github.com/angular/angular/issues/25816)
|
||||
* **router:** mount correct component if router outlet was not instantiated and if using a route reuse strategy ([#25313](https://github.com/angular/angular/issues/25313)) ([#25314](https://github.com/angular/angular/issues/25314)) ([8dc2b11](https://github.com/angular/angular/commit/8dc2b11))
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **bazel:** add additional parameters to `ts_api_guardian_test` def ([#25694](https://github.com/angular/angular/issues/25694)) ([2a21ca0](https://github.com/angular/angular/commit/2a21ca0))
|
||||
* **ivy:** allow combined context discovery for components, directives and elements ([#25754](https://github.com/angular/angular/issues/25754)) ([62be8c2](https://github.com/angular/angular/commit/62be8c2))
|
||||
* **ivy:** patch animations into metadata ([#25828](https://github.com/angular/angular/issues/25828)) ([d2dfd48](https://github.com/angular/angular/commit/d2dfd48))
|
||||
* **ivy:** resolve references to vars in .d.ts files ([#25775](https://github.com/angular/angular/issues/25775)) ([96d6b79](https://github.com/angular/angular/commit/96d6b79))
|
||||
* **ivy:** support animation [@triggers](https://github.com/triggers) in templates ([#25849](https://github.com/angular/angular/issues/25849)) ([e363388](https://github.com/angular/angular/commit/e363388))
|
||||
* **ivy:** support bootstrap in ngModuleDef ([#25775](https://github.com/angular/angular/issues/25775)) ([13ccdfd](https://github.com/angular/angular/commit/13ccdfd))
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0-beta.5"></a>
|
||||
# [7.0.0-beta.5](https://github.com/angular/angular/compare/7.0.0-beta.4...7.0.0-beta.5) (2018-09-06)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **bazel:** protractor rule should include *.e2e-spec.js ([#25701](https://github.com/angular/angular/issues/25701)) ([3809e0f](https://github.com/angular/angular/commit/3809e0f))
|
||||
* **benchpress:** Use performance.mark() instead of console.time() ([#24114](https://github.com/angular/angular/issues/24114)) ([06d0400](https://github.com/angular/angular/commit/06d0400))
|
||||
* **compiler:** add hostVars and support pure functions in host bindings ([#25626](https://github.com/angular/angular/issues/25626)) ([b424b31](https://github.com/angular/angular/commit/b424b31))
|
||||
* **core:** do not clear element content when using shadow dom ([#24861](https://github.com/angular/angular/issues/24861)) ([6e828bb](https://github.com/angular/angular/commit/6e828bb))
|
||||
* **core:** size regression with closure compiler ([#25531](https://github.com/angular/angular/issues/25531)) ([1f59f2f](https://github.com/angular/angular/commit/1f59f2f))
|
||||
* **elements:** add compiler dependency ([#24861](https://github.com/angular/angular/issues/24861)) ([6143da6](https://github.com/angular/angular/commit/6143da6))
|
||||
* **elements:** add compiler to integration ([#24861](https://github.com/angular/angular/issues/24861)) ([a080ffc](https://github.com/angular/angular/commit/a080ffc))
|
||||
* **elements:** strict null checks ([#24861](https://github.com/angular/angular/issues/24861)) ([a8210d0](https://github.com/angular/angular/commit/a8210d0))
|
||||
* **upgrade:** trigger `$destroy` event on upgraded component element ([#25357](https://github.com/angular/angular/issues/25357)) ([2a672a9](https://github.com/angular/angular/commit/2a672a9)), closes [#25334](https://github.com/angular/angular/issues/25334)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **elements:** enable Shadow DOM v1 and slots ([#24861](https://github.com/angular/angular/issues/24861)) ([c9844a2](https://github.com/angular/angular/commit/c9844a2))
|
||||
* **router:** warn if navigation triggered outside Angular zone ([#24959](https://github.com/angular/angular/issues/24959)) ([010e35d](https://github.com/angular/angular/commit/010e35d)), closes [#15770](https://github.com/angular/angular/issues/15770) [#15946](https://github.com/angular/angular/issues/15946) [#24728](https://github.com/angular/angular/issues/24728)
|
||||
|
||||
|
||||
|
||||
|
||||
<a name="6.1.7"></a>
|
||||
@ -121,18 +121,6 @@ This version includes Ivy features and internal refactorings. There are no user-
|
||||
* **router:** warn if navigation triggered outside Angular zone ([#24959](https://github.com/angular/angular/issues/24959)) ([23a96dc](https://github.com/angular/angular/commit/23a96dc)), closes [#15770](https://github.com/angular/angular/issues/15770) [#15946](https://github.com/angular/angular/issues/15946) [#24728](https://github.com/angular/angular/issues/24728)
|
||||
|
||||
|
||||
<a name="7.0.0-beta.4"></a>
|
||||
# [7.0.0-beta.4](https://github.com/angular/angular/compare/7.0.0-beta.3...7.0.0-beta.4) (2018-08-29)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **bazel:** Cache fileNameToModuleName lookups ([#25731](https://github.com/angular/angular/issues/25731)) ([f394ba0](https://github.com/angular/angular/commit/f394ba0))
|
||||
* **bazel:** move bazel managed runtime deps for downstream usage ([#25690](https://github.com/angular/angular/issues/25690)) ([6ed7993](https://github.com/angular/angular/commit/6ed7993))
|
||||
* **bazel:** only lookup amd module-name tags in .d.ts files ([#25710](https://github.com/angular/angular/issues/25710)) ([42072c4](https://github.com/angular/angular/commit/42072c4))
|
||||
* **compiler:** update compiler to generate new slot allocations ([#25607](https://github.com/angular/angular/issues/25607)) ([27e2039](https://github.com/angular/angular/commit/27e2039))
|
||||
|
||||
|
||||
|
||||
<a name="6.1.6"></a>
|
||||
## [6.1.6](https://github.com/angular/angular/compare/6.1.5...6.1.6) (2018-08-29)
|
||||
@ -146,14 +134,6 @@ This version includes Ivy features and internal refactorings. There are no user-
|
||||
|
||||
Note: the 6.1.5 release on npm accidentally glitched-out midway, so we cut 6.1.6 instead. sorry! :-)
|
||||
|
||||
<a name="7.0.0-beta.3"></a>
|
||||
# [7.0.0-beta.3](https://github.com/angular/angular/compare/7.0.0-beta.2...7.0.0-beta.3) (2018-08-22)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **router:** add UrlSegment[] to CanLoad interface ([#13127](https://github.com/angular/angular/issues/13127)) ([07d8d39](https://github.com/angular/angular/commit/07d8d39)), closes [#12411](https://github.com/angular/angular/issues/12411)
|
||||
|
||||
|
||||
|
||||
<a name="6.1.4"></a>
|
||||
@ -166,15 +146,6 @@ Note: the 6.1.5 release on npm accidentally glitched-out midway, so we cut 6.1.6
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0-beta.2"></a>
|
||||
# [7.0.0-beta.2](https://github.com/angular/angular/compare/7.0.0-beta.1...7.0.0-beta.2) (2018-08-15)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **bazel:** correct type concatenated to devmode_js ([#25467](https://github.com/angular/angular/issues/25467)) ([fb2c524](https://github.com/angular/angular/commit/fb2c524))
|
||||
|
||||
|
||||
<a name="6.1.3"></a>
|
||||
## [6.1.3](https://github.com/angular/angular/compare/6.1.2...6.1.3) (2018-08-15)
|
||||
|
||||
@ -185,24 +156,6 @@ Note: the 6.1.5 release on npm accidentally glitched-out midway, so we cut 6.1.6
|
||||
|
||||
|
||||
|
||||
<a name="7.0.0-beta.1"></a>
|
||||
# [7.0.0-beta.1](https://github.com/angular/angular/compare/7.0.0-beta.0...7.0.0-beta.1) (2018-08-08)
|
||||
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **compiler-cli:** use the oldProgram option in watch mode ([#21364](https://github.com/angular/angular/issues/21364)) ([c6e5b97](https://github.com/angular/angular/commit/c6e5b97)), closes [#21361](https://github.com/angular/angular/issues/21361)
|
||||
* **core:** In Testability.whenStable update callback, pass more complete ([#25010](https://github.com/angular/angular/issues/25010)) ([16c03c0](https://github.com/angular/angular/commit/16c03c0))
|
||||
* add mappings for ngfactory & ngsummary files to their module names in aot summary resolver ([#25335](https://github.com/angular/angular/issues/25335)) ([02e201a](https://github.com/angular/angular/commit/02e201a))
|
||||
* **router:** take base uri into account in `setUpLocationSync()` ([#20244](https://github.com/angular/angular/issues/20244)) ([ba1e25f](https://github.com/angular/angular/commit/ba1e25f)), closes [#20061](https://github.com/angular/angular/issues/20061)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **core:** add DoBootstrap interface. ([#24558](https://github.com/angular/angular/issues/24558)) ([732026c](https://github.com/angular/angular/commit/732026c)), closes [#24557](https://github.com/angular/angular/issues/24557)
|
||||
|
||||
|
||||
|
||||
<a name="6.1.2"></a>
|
||||
## [6.1.2](https://github.com/angular/angular/compare/6.1.1...6.1.2) (2018-08-08)
|
||||
|
||||
@ -213,22 +166,6 @@ Note: the 6.1.5 release on npm accidentally glitched-out midway, so we cut 6.1.6
|
||||
* add mappings for ngfactory & ngsummary files to their module names in aot summary resolver ([#25335](https://github.com/angular/angular/issues/25335)) ([054fbbe](https://github.com/angular/angular/commit/054fbbe))
|
||||
|
||||
|
||||
<a name="7.0.0-beta.0"></a>
|
||||
# [7.0.0-beta.0](https://github.com/angular/angular/compare/6.1.0...7.0.0-beta.0) (2018-08-02)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* **bazel:** allow compile_strategy to be (privately) imported ([#25080](https://github.com/angular/angular/issues/25080)) ([0d1d589](https://github.com/angular/angular/commit/0d1d589))
|
||||
* **compiler:** update compiler to flatten nested template fns ([#24943](https://github.com/angular/angular/issues/24943)) ([fe14f18](https://github.com/angular/angular/commit/fe14f18))
|
||||
* **compiler-cli:** correct realPath to realpath. ([#25023](https://github.com/angular/angular/issues/25023)) ([01e6dab](https://github.com/angular/angular/commit/01e6dab))
|
||||
* **core:** throw error message when @Output not initialized ([#19116](https://github.com/angular/angular/issues/19116)) ([adf510f](https://github.com/angular/angular/commit/adf510f)), closes [#3664](https://github.com/angular/angular/issues/3664)
|
||||
|
||||
|
||||
### Features
|
||||
|
||||
* **compiler:** add "original" placeholder value on extracted XMB ([#25079](https://github.com/angular/angular/issues/25079)) ([e99d860](https://github.com/angular/angular/commit/e99d860))
|
||||
|
||||
|
||||
|
||||
<a name="6.1.1"></a>
|
||||
## [6.1.1](https://github.com/angular/angular/compare/6.1.0...6.1.1) (2018-08-02)
|
||||
|
@ -13,12 +13,10 @@ Angular is a development platform for building mobile and desktop web applicatio
|
||||
|
||||
[Get started in 5 minutes][quickstart].
|
||||
|
||||
|
||||
## Changelog
|
||||
|
||||
[Learn about the latest improvements][changelog].
|
||||
|
||||
|
||||
## Want to help?
|
||||
|
||||
Want to file a bug, contribute some code, or improve documentation? Excellent! Read up on our
|
||||
|
113
WORKSPACE
113
WORKSPACE
@ -1,91 +1,24 @@
|
||||
workspace(name = "angular")
|
||||
|
||||
#
|
||||
# Download Bazel toolchain dependencies as needed by build actions
|
||||
#
|
||||
http_archive(
|
||||
name = "build_bazel_rules_typescript",
|
||||
sha256 = "1626ee2cc9770af6950bfc77dffa027f9aedf330fe2ea2ee7e504428927bd95d",
|
||||
strip_prefix = "rules_typescript-0.17.0",
|
||||
url = "https://github.com/bazelbuild/rules_typescript/archive/0.17.0.zip",
|
||||
load(
|
||||
"//packages/bazel:package.bzl",
|
||||
"rules_angular_dependencies",
|
||||
"rules_angular_dev_dependencies",
|
||||
)
|
||||
|
||||
load("@build_bazel_rules_typescript//:package.bzl", "rules_typescript_dependencies")
|
||||
|
||||
rules_typescript_dependencies()
|
||||
|
||||
http_archive(
|
||||
name = "bazel_toolchains",
|
||||
sha256 = "c3b08805602cd1d2b67ebe96407c1e8c6ed3d4ce55236ae2efe2f1948f38168d",
|
||||
strip_prefix = "bazel-toolchains-5124557861ebf4c0b67f98180bff1f8551e0b421",
|
||||
urls = [
|
||||
"https://mirror.bazel.build/github.com/bazelbuild/bazel-toolchains/archive/5124557861ebf4c0b67f98180bff1f8551e0b421.tar.gz",
|
||||
"https://github.com/bazelbuild/bazel-toolchains/archive/5124557861ebf4c0b67f98180bff1f8551e0b421.tar.gz",
|
||||
],
|
||||
)
|
||||
|
||||
http_archive(
|
||||
name = "io_bazel_rules_sass",
|
||||
sha256 = "dbe9fb97d5a7833b2a733eebc78c9c1e3880f676ac8af16e58ccf2139cbcad03",
|
||||
strip_prefix = "rules_sass-1.11.0",
|
||||
url = "https://github.com/bazelbuild/rules_sass/archive/1.11.0.zip",
|
||||
)
|
||||
|
||||
# This commit matches the version of buildifier in angular/ngcontainer
|
||||
# If you change this, also check if it matches the version in the angular/ngcontainer
|
||||
# version in /.circleci/config.yml
|
||||
BAZEL_BUILDTOOLS_VERSION = "49a6c199e3fbf5d94534b2771868677d3f9c6de9"
|
||||
|
||||
http_archive(
|
||||
name = "com_github_bazelbuild_buildtools",
|
||||
sha256 = "edf39af5fc257521e4af4c40829fffe8fba6d0ebff9f4dd69a6f8f1223ae047b",
|
||||
strip_prefix = "buildtools-%s" % BAZEL_BUILDTOOLS_VERSION,
|
||||
url = "https://github.com/bazelbuild/buildtools/archive/%s.zip" % BAZEL_BUILDTOOLS_VERSION,
|
||||
)
|
||||
|
||||
# Fetching the Bazel source code allows us to compile the Skylark linter
|
||||
http_archive(
|
||||
name = "io_bazel",
|
||||
sha256 = "ace8cced3b21e64a8fdad68508e9b0644201ec848ad583651719841d567fc66d",
|
||||
strip_prefix = "bazel-0.17.1",
|
||||
url = "https://github.com/bazelbuild/bazel/archive/0.17.1.zip",
|
||||
)
|
||||
|
||||
http_archive(
|
||||
name = "io_bazel_skydoc",
|
||||
sha256 = "7bfb5545f59792a2745f2523b9eef363f9c3e7274791c030885e7069f8116016",
|
||||
strip_prefix = "skydoc-fe2e9f888d28e567fef62ec9d4a93c425526d701",
|
||||
# TODO: switch to upstream when https://github.com/bazelbuild/skydoc/pull/103 is merged
|
||||
url = "https://github.com/alexeagle/skydoc/archive/fe2e9f888d28e567fef62ec9d4a93c425526d701.zip",
|
||||
)
|
||||
|
||||
# We have a source dependency on the Devkit repository, because it's built with
|
||||
# Bazel.
|
||||
# This allows us to edit sources and have the effect appear immediately without
|
||||
# re-packaging or "npm link"ing.
|
||||
# Even better, things like aspects will visit the entire graph including
|
||||
# ts_library rules in the devkit repository.
|
||||
http_archive(
|
||||
name = "angular_cli",
|
||||
sha256 = "8cf320ea58c321e103f39087376feea502f20eaf79c61a4fdb05c7286c8684fd",
|
||||
strip_prefix = "angular-cli-6.1.0-rc.0",
|
||||
url = "https://github.com/angular/angular-cli/archive/v6.1.0-rc.0.zip",
|
||||
)
|
||||
|
||||
http_archive(
|
||||
name = "org_brotli",
|
||||
sha256 = "774b893a0700b0692a76e2e5b7e7610dbbe330ffbe3fe864b4b52ca718061d5a",
|
||||
strip_prefix = "brotli-1.0.5",
|
||||
url = "https://github.com/google/brotli/archive/v1.0.5.zip",
|
||||
)
|
||||
# Angular Bazel users will call this function
|
||||
rules_angular_dependencies()
|
||||
# These are the dependencies only for us
|
||||
rules_angular_dev_dependencies()
|
||||
|
||||
#
|
||||
# Point Bazel to WORKSPACEs that live in subdirectories
|
||||
#
|
||||
|
||||
local_repository(
|
||||
http_archive(
|
||||
name = "rxjs",
|
||||
path = "node_modules/rxjs/src",
|
||||
url = "https://registry.yarnpkg.com/rxjs/-/rxjs-6.3.3.tgz",
|
||||
strip_prefix = "package/src",
|
||||
sha256 = "72b0b4e517f43358f554c125e40e39f67688cd2738a8998b4a266981ed32f403",
|
||||
)
|
||||
|
||||
# Point to the integration test workspace just so that Bazel doesn't descend into it
|
||||
@ -98,10 +31,9 @@ local_repository(
|
||||
#
|
||||
# Load and install our dependencies downloaded above.
|
||||
#
|
||||
load("@build_bazel_rules_nodejs//:defs.bzl", "check_bazel_version", "node_repositories", "yarn_install")
|
||||
|
||||
load("@build_bazel_rules_nodejs//:defs.bzl", "check_bazel_version", "node_repositories")
|
||||
|
||||
check_bazel_version("0.17.0", """
|
||||
check_bazel_version("0.18.0", """
|
||||
If you are on a Mac and using Homebrew, there is a breaking change to the installation in Bazel 0.16
|
||||
See https://blog.bazel.build/2018/08/22/bazel-homebrew.html
|
||||
|
||||
@ -114,6 +46,12 @@ node_repositories(
|
||||
yarn_version = "1.9.2",
|
||||
)
|
||||
|
||||
yarn_install(
|
||||
name = "npm",
|
||||
package_json = "//tools:npm/package.json",
|
||||
yarn_lock = "//tools:npm/yarn.lock",
|
||||
)
|
||||
|
||||
load("@io_bazel_rules_go//go:def.bzl", "go_rules_dependencies", "go_register_toolchains")
|
||||
|
||||
go_rules_dependencies()
|
||||
@ -147,14 +85,3 @@ sass_repositories()
|
||||
load("@io_bazel_skydoc//skylark:skylark.bzl", "skydoc_repositories")
|
||||
|
||||
skydoc_repositories()
|
||||
|
||||
##################################
|
||||
# Prevent Bazel from trying to build rxjs under angular devkit
|
||||
local_repository(
|
||||
name = "rxjs_ignore_nested_1",
|
||||
path = "node_modules/@angular-devkit/core/node_modules/rxjs/src",
|
||||
)
|
||||
local_repository(
|
||||
name = "rxjs_ignore_nested_2",
|
||||
path = "node_modules/@angular-devkit/schematics/node_modules/rxjs/src",
|
||||
)
|
||||
|
@ -3,7 +3,7 @@
|
||||
|
||||
TODO (gkalpak): Add docs. Mention:
|
||||
- Testing on CI.
|
||||
Relevant files: `scripts/ci/test-aio.sh`, `aio/aio-builds-setup/scripts/test.sh`
|
||||
Relevant files: `aio/aio-builds-setup/scripts/test.sh`
|
||||
- Deploying from CI.
|
||||
Relevant files: `.circleci/config.yml`, `scripts/ci/deploy.sh`, `aio/scripts/build-artifacts.sh`,
|
||||
`aio/scripts/deploy-to-firebase.sh`
|
||||
|
@ -1,83 +1,102 @@
|
||||
<h1 class="no-toc">CLI Command Reference</h1>
|
||||
|
||||
The Angular CLI is a command-line tool that you use to initialize, develop, scaffold, and maintain Angular applications.
|
||||
The Angular CLI is a command-line interface tool that you use to initialize, develop, scaffold, and maintain Angular applications. You can use the tool directly in a command shell, or indirectly through an interactive UI such as [Angular Console](https://angularconsole.com).
|
||||
|
||||
## Getting Started
|
||||
## Installing Angular CLI
|
||||
|
||||
### Installing Angular CLI
|
||||
Major versions of Angular CLI follow the supported major version of Angular, but minor versions can be released separately.
|
||||
|
||||
The current version of Angular CLI is 6.x.
|
||||
Install the CLI using the `npm` package manager:
|
||||
<code-example format="." language="bash">
|
||||
npm install -g @angular/cli
|
||||
</code-example>
|
||||
|
||||
* Both the CLI and the projects that you generate with the tool have dependencies that require Node 8.9 or higher, together with NPM 5.5.1 or higher.
|
||||
* Install the CLI using npm:
|
||||
`npm install -g @angular/cli`
|
||||
* The CLI is an open-source tool:
|
||||
https://github.com/angular/angular-cli/tree/master/packages/angular/cli
|
||||
For details about changes between versions, and information about updating from previous releases,
|
||||
see the Releases tab on GitHub: https://github.com/angular/angular-cli/releases
|
||||
|
||||
For details about changes between versions, and information about updating from previous releases, see the Releases tab on GitHub.
|
||||
## Basic workflow
|
||||
|
||||
### Basic workflow
|
||||
Invoke the tool on the command line through the `ng` executable.
|
||||
Online help is available on the command line.
|
||||
Enter the following to list commands or options for a given command (such as [generate](cli/generate)) with a short description.
|
||||
|
||||
Invoke the tool on the command line through the ng executable. Online help is available on the command line:
|
||||
<code-example format="." language="bash">
|
||||
ng help
|
||||
ng generate --help
|
||||
</code-example>
|
||||
|
||||
```
|
||||
> ng help Lists commands with short descriptions
|
||||
> ng <command> --help Lists options for a command.
|
||||
```
|
||||
To create, build, and serve a new, basic Angular project on a development server, go to the parent directory of your new workspace use the following commands:
|
||||
|
||||
To create, build, and serve a new, basic Angular project on a development server, use the following commands:
|
||||
|
||||
```
|
||||
cd <parent of new workspace>
|
||||
ng new my-project
|
||||
cd my-project
|
||||
<code-example format="." language="bash">
|
||||
ng new my-first-project
|
||||
cd my-first-project
|
||||
ng serve
|
||||
```
|
||||
</code-example>
|
||||
|
||||
In your browser, open http://localhost:4200/ to see the new app run.
|
||||
|
||||
### Workspaces and project files
|
||||
## Workspaces and project files
|
||||
|
||||
Angular 6 introduced the workspace directory structure for Angular apps. A workspace defines a project. A project can contain multiple apps, as well as libraries that can be used in any of the apps.
|
||||
The [ng new](cli/new) command creates an *Angular workspace* folder and generates a new app skeleton.
|
||||
A workspace can contain multiple apps and libraries.
|
||||
The initial app created by the [ng new](cli/new) command is at the top level of the workspace.
|
||||
When you generate an additional app or library in a workspace, it goes into a `projects/` subfolder.
|
||||
|
||||
Some commands (such as build) must be executed from within a workspace folder, and others (such as new) must be executed from outside any workspace. This requirement is called out in the description of each command where it applies.The `new` command creates a [workspace](guide/glossary#workspace) to contain [projects](guide/glossary#project). A project can be an app or a library, and a workspace can contain multiple apps and libraries.
|
||||
A newly generated app contains the source files for a root module, with a root component and template.
|
||||
Each app has a `src` folder that contains the logic, data, and assets.
|
||||
|
||||
A newly generated app project contains the source files for a root module, with a root component and template, which you can edit directly, or add to and modify using CLI commands. Use the generate command to add new files for additional components and services, and code for new pipes, directives, and so on.
|
||||
You can edit the generated files directly, or add to and modify them using CLI commands.
|
||||
Use the [ng generate](cli/generate) command to add new files for additional components and services, and code for new pipes, directives, and so on.
|
||||
Commands such as [add](cli/add) and [generate](cli/generate), which create or operate on apps and libraries, must be executed from within a workspace or project folder.
|
||||
|
||||
* Commands such as `add` and `generate`, that create or operate on apps and libraries, must be executed from within a workspace folder.
|
||||
* Apps in a workspace can use libraries in the same workspace.
|
||||
* Each project has a `src` folder that contains the logic, data, and assets.
|
||||
See an example of the [file structure](guide/quickstart#project-file-review) in [Getting Started](guide/quickstart).
|
||||
When you use the [ng serve](cli/serve) command to build an app and serve it locally, the server automatically rebuilds the app and reloads the page when you change any of the source files.
|
||||
|
||||
When you use the `serve` command to build an app, the server automatically rebuilds the app and reloads the page when you change any of the source files.
|
||||
* See more about the [Workspace file structure](guide/file-structure).
|
||||
|
||||
### Configuring the CLI
|
||||
When you use the [ng serve](cli/serve) command to build an app and serve it locally, the server automatically rebuilds the app and reloads the page when you change any of the source files.
|
||||
|
||||
Configuration files let you customize your project. The CLI configuration file, angular.json, is created at the top level of the project folder. This is where you can set CLI defaults for your project, and specify which files to include when the CLI builds the project.
|
||||
A single workspace configuration file, `angular.json`, is created at the top level of the workspace.
|
||||
This is where you can set workspace-wide defaults, and specify configurations to use when the CLI builds a project for different targets.
|
||||
|
||||
The CLI config command lets you set and retrieve configuration values from the command line, or you can edit the angular.json file directly.
|
||||
The [ng config](cli/config) command lets you set and retrieve configuration values from the command line, or you can edit the `angular.json` file directly.
|
||||
|
||||
* See the complete schema for angular.json.
|
||||
* Learn more about configuration options for Angular (link to new guide?)
|
||||
* See the [complete schema](https://github.com/angular/angular-cli/wiki/angular-workspace) for `angular.json`.
|
||||
<!-- * Learn more about *configuration options for Angular(links to new guide or topics TBD)*. -->
|
||||
|
||||
### Command options and arguments
|
||||
|
||||
All commands and some options have aliases, as listed in the descriptions. Option names are prefixed with a double dash (--), but arguments and option aliases are not.
|
||||
|
||||
Typically, the name of a generated artifact can be given as an argument to the command or specified with the --name option. Most commands have additional options.
|
||||
## CLI command-language syntax
|
||||
|
||||
Command syntax is shown as follows:
|
||||
|
||||
```
|
||||
ng commandNameOrAlias <arg> [options]
|
||||
```
|
||||
`ng` *commandNameOrAlias* *requiredArg* [*optionalArg*] `[options]`
|
||||
|
||||
Options take either string or Boolean arguments. Defaults are shown in bold for Boolean or enumerated values, and are given with the description. For example:
|
||||
* Most commands, and some options, have aliases. Aliases are shown in the syntax statement for each command.
|
||||
|
||||
```
|
||||
--optionNameOrAlias=<filename>
|
||||
--optionNameOrAlias=true|false
|
||||
--optionNameOrAlias=allowedValue1|allowedValue2|allowedValue3
|
||||
```
|
||||
* Option names are prefixed with a double dash (--).
|
||||
Option aliases are prefixed with a single dash (-).
|
||||
Arguments are not prefixed.
|
||||
For example: `ng build my-app -c production`
|
||||
|
||||
* Typically, the name of a generated artifact can be given as an argument to the command or specified with the --name option.
|
||||
|
||||
* Argument and option names can be given in either
|
||||
[camelCase or dash-case](guide/glossary#case-types).
|
||||
`--myOptionName` is equivalent to `--my-option-name`.
|
||||
|
||||
### Boolean and enumerated options
|
||||
|
||||
Boolean options have two forms: `--thisOption` sets the flag, `--noThisOption` clears it.
|
||||
If neither option is supplied, the flag remains in its default state, as listed in the reference documentation.
|
||||
|
||||
Allowed values are given with each enumerated option description, with the default value in **bold**.
|
||||
|
||||
### Relative paths
|
||||
|
||||
Options that specify files can be given as absolute paths, or as paths relative to the current working directory, which is generally either the workspace or project root.
|
||||
|
||||
### Schematics
|
||||
|
||||
The [ng generate](cli/generate) and [ng add](cli/add) commands take as an argument the artifact or library to be generated or added to the current project.
|
||||
In addition to any general options, each artifact or library defines its own options in a *schematic*.
|
||||
Schematic options are supplied to the command in the same format as immediate command options.
|
||||
|
||||
Boolean options can also be expressed with a prefix `no-` to indicate a value of false. For example, `--no-prod` is equivalent to `--prod=false`.
|
@ -1,6 +1,6 @@
|
||||
'use strict'; // necessary for es6 output in node
|
||||
|
||||
import { browser } from 'protractor';
|
||||
import { browser, ExpectedConditions as EC } from 'protractor';
|
||||
import { logging } from 'selenium-webdriver';
|
||||
import * as openClose from './open-close.po';
|
||||
import * as statusSlider from './status-slider.po';
|
||||
@ -25,6 +25,8 @@ describe('Animation Tests', () => {
|
||||
});
|
||||
|
||||
describe('Open/Close Component', () => {
|
||||
const closedHeight = '100px';
|
||||
const openHeight = '200px';
|
||||
|
||||
beforeAll(async () => {
|
||||
await openCloseHref.click();
|
||||
@ -32,37 +34,37 @@ describe('Animation Tests', () => {
|
||||
});
|
||||
|
||||
it('should be open', async () => {
|
||||
let text = await openClose.getComponentText();
|
||||
const toggleButton = openClose.getToggleButton();
|
||||
const container = openClose.getComponentContainer();
|
||||
let text = await container.getText();
|
||||
|
||||
if (text.includes('Closed')) {
|
||||
await toggleButton.click();
|
||||
sleepFor();
|
||||
await browser.wait(async () => await container.getCssValue('height') === openHeight, 2000);
|
||||
}
|
||||
|
||||
text = await openClose.getComponentText();
|
||||
text = await container.getText();
|
||||
const containerHeight = await container.getCssValue('height');
|
||||
|
||||
expect(text).toContain('The box is now Open!');
|
||||
expect(containerHeight).toBe('200px');
|
||||
expect(containerHeight).toBe(openHeight);
|
||||
});
|
||||
|
||||
it('should be closed', async () => {
|
||||
let text = await openClose.getComponentText();
|
||||
const toggleButton = openClose.getToggleButton();
|
||||
const container = openClose.getComponentContainer();
|
||||
let text = await container.getText();
|
||||
|
||||
if (text.includes('Open')) {
|
||||
await toggleButton.click();
|
||||
sleepFor();
|
||||
await browser.wait(async () => await container.getCssValue('height') === closedHeight, 2000);
|
||||
}
|
||||
|
||||
text = await openClose.getComponentText();
|
||||
text = await container.getText();
|
||||
const containerHeight = await container.getCssValue('height');
|
||||
|
||||
expect(text).toContain('The box is now Closed!');
|
||||
expect(containerHeight).toBe('100px');
|
||||
expect(containerHeight).toBe(closedHeight);
|
||||
});
|
||||
|
||||
it('should log animation events', async () => {
|
||||
@ -72,8 +74,7 @@ describe('Animation Tests', () => {
|
||||
await toggleButton.click();
|
||||
|
||||
const logs = await browser.manage().logs().get(logging.Type.BROWSER);
|
||||
|
||||
const animationMessages = logs.filter(({ message }) => message.indexOf('Animation') !== -1 ? true : false);
|
||||
const animationMessages = logs.filter(({ message }) => message.includes('Animation'));
|
||||
|
||||
expect(animationMessages.length).toBeGreaterThan(0);
|
||||
});
|
||||
@ -89,16 +90,16 @@ describe('Animation Tests', () => {
|
||||
});
|
||||
|
||||
it('should be inactive with an orange background', async () => {
|
||||
let text = await statusSlider.getComponentText();
|
||||
const toggleButton = statusSlider.getToggleButton();
|
||||
const container = statusSlider.getComponentContainer();
|
||||
let text = await container.getText();
|
||||
|
||||
if (text === 'Active') {
|
||||
await toggleButton.click();
|
||||
sleepFor(2000);
|
||||
await browser.wait(async () => await container.getCssValue('backgroundColor') === inactiveColor, 2000);
|
||||
}
|
||||
|
||||
text = await statusSlider.getComponentText();
|
||||
text = await container.getText();
|
||||
const bgColor = await container.getCssValue('backgroundColor');
|
||||
|
||||
expect(text).toBe('Inactive');
|
||||
@ -106,16 +107,16 @@ describe('Animation Tests', () => {
|
||||
});
|
||||
|
||||
it('should be active with a blue background', async () => {
|
||||
let text = await statusSlider.getComponentText();
|
||||
const toggleButton = statusSlider.getToggleButton();
|
||||
const container = statusSlider.getComponentContainer();
|
||||
let text = await container.getText();
|
||||
|
||||
if (text === 'Inactive') {
|
||||
await toggleButton.click();
|
||||
sleepFor(2000);
|
||||
await browser.wait(async () => await container.getCssValue('backgroundColor') === activeColor, 2000);
|
||||
}
|
||||
|
||||
text = await statusSlider.getComponentText();
|
||||
text = await container.getText();
|
||||
const bgColor = await container.getCssValue('backgroundColor');
|
||||
|
||||
expect(text).toBe('Active');
|
||||
@ -163,10 +164,7 @@ describe('Animation Tests', () => {
|
||||
const hero = heroesList.get(0);
|
||||
|
||||
await hero.click();
|
||||
await sleepFor(100);
|
||||
const newTotal = await heroesList.count();
|
||||
|
||||
expect(newTotal).toBeLessThan(total);
|
||||
await browser.wait(async () => await heroesList.count() < total, 2000);
|
||||
});
|
||||
});
|
||||
|
||||
@ -190,10 +188,7 @@ describe('Animation Tests', () => {
|
||||
const hero = heroesList.get(0);
|
||||
|
||||
await hero.click();
|
||||
await sleepFor(250);
|
||||
const newTotal = await heroesList.count();
|
||||
|
||||
expect(newTotal).toBeLessThan(total);
|
||||
await browser.wait(async () => await heroesList.count() < total, 2000);
|
||||
});
|
||||
});
|
||||
|
||||
@ -213,14 +208,14 @@ describe('Animation Tests', () => {
|
||||
it('should filter down the list when a search is performed', async () => {
|
||||
const heroesList = filterStagger.getHeroesList();
|
||||
const total = await heroesList.count();
|
||||
|
||||
const formInput = filterStagger.getFormInput();
|
||||
|
||||
await formInput.sendKeys('Mag');
|
||||
await sleepFor(500);
|
||||
const newTotal = await heroesList.count();
|
||||
|
||||
await browser.wait(async () => await heroesList.count() === 2, 2000);
|
||||
|
||||
const newTotal = await heroesList.count();
|
||||
expect(newTotal).toBeLessThan(total);
|
||||
expect(newTotal).toBe(2);
|
||||
});
|
||||
});
|
||||
|
||||
@ -248,10 +243,7 @@ describe('Animation Tests', () => {
|
||||
const hero = heroesList.get(0);
|
||||
|
||||
await hero.click();
|
||||
await sleepFor(300);
|
||||
const newTotal = await heroesList.count();
|
||||
|
||||
expect(newTotal).toBeLessThan(total);
|
||||
await browser.wait(async () => await heroesList.count() < total, 2000);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
@ -23,11 +23,3 @@ export function getComponentContainer() {
|
||||
const findContainer = () => by.css('div');
|
||||
return locate(getComponent(), findContainer());
|
||||
}
|
||||
|
||||
export async function getComponentText() {
|
||||
const findContainerText = () => by.css('div');
|
||||
const contents = locate(getComponent(), findContainerText());
|
||||
const componentText = await contents.getText();
|
||||
|
||||
return componentText;
|
||||
}
|
||||
|
@ -18,11 +18,3 @@ export function getComponentContainer() {
|
||||
const findContainer = () => by.css('div');
|
||||
return locate(getComponent(), findContainer());
|
||||
}
|
||||
|
||||
export async function getComponentText() {
|
||||
const findContainerText = () => by.css('div');
|
||||
const contents = locate(getComponent(), findContainerText());
|
||||
const componentText = await contents.getText();
|
||||
|
||||
return componentText;
|
||||
}
|
||||
|
@ -1,12 +1,23 @@
|
||||
'use strict'; // necessary for es6 output in node
|
||||
|
||||
import { browser, by, element } from 'protractor';
|
||||
import { browser, by, element, ElementFinder, ExpectedConditions as EC } from 'protractor';
|
||||
|
||||
/* tslint:disable:quotemark */
|
||||
describe('Elements', () => {
|
||||
const messageInput = element(by.css('input'));
|
||||
const popupButtons = element.all(by.css('button'));
|
||||
|
||||
// Helpers
|
||||
const click = (elem: ElementFinder) => {
|
||||
// Waiting for the element to be clickable, makes the tests less flaky.
|
||||
browser.wait(EC.elementToBeClickable(elem), 5000);
|
||||
elem.click();
|
||||
};
|
||||
const waitForText = (elem: ElementFinder) => {
|
||||
// Waiting for the element to have some text, makes the tests less flaky.
|
||||
browser.wait(async () => /\S/.test(await elem.getText()), 5000);
|
||||
}
|
||||
|
||||
beforeEach(() => browser.get(''));
|
||||
|
||||
describe('popup component', () => {
|
||||
@ -17,7 +28,7 @@ describe('Elements', () => {
|
||||
it('should be displayed on button click', () => {
|
||||
expect(popupComponent.isPresent()).toBe(false);
|
||||
|
||||
popupComponentButton.click();
|
||||
click(popupComponentButton);
|
||||
expect(popupComponent.isPresent()).toBe(true);
|
||||
});
|
||||
|
||||
@ -25,7 +36,9 @@ describe('Elements', () => {
|
||||
messageInput.clear();
|
||||
messageInput.sendKeys('Angular rocks!');
|
||||
|
||||
popupComponentButton.click();
|
||||
click(popupComponentButton);
|
||||
waitForText(popupComponent);
|
||||
|
||||
expect(popupComponent.getText()).toContain('Popup: Angular rocks!');
|
||||
});
|
||||
|
||||
@ -33,7 +46,7 @@ describe('Elements', () => {
|
||||
popupComponentButton.click();
|
||||
expect(popupComponent.isPresent()).toBe(true);
|
||||
|
||||
closeButton.click();
|
||||
click(closeButton);
|
||||
expect(popupComponent.isPresent()).toBe(false);
|
||||
});
|
||||
});
|
||||
@ -46,7 +59,7 @@ describe('Elements', () => {
|
||||
it('should be displayed on button click', () => {
|
||||
expect(popupElement.isPresent()).toBe(false);
|
||||
|
||||
popupElementButton.click();
|
||||
click(popupElementButton);
|
||||
expect(popupElement.isPresent()).toBe(true);
|
||||
});
|
||||
|
||||
@ -54,7 +67,9 @@ describe('Elements', () => {
|
||||
messageInput.clear();
|
||||
messageInput.sendKeys('Angular rocks!');
|
||||
|
||||
popupElementButton.click();
|
||||
click(popupElementButton);
|
||||
waitForText(popupElement);
|
||||
|
||||
expect(popupElement.getText()).toContain('Popup: Angular rocks!');
|
||||
});
|
||||
|
||||
@ -62,7 +77,7 @@ describe('Elements', () => {
|
||||
popupElementButton.click();
|
||||
expect(popupElement.isPresent()).toBe(true);
|
||||
|
||||
closeButton.click();
|
||||
click(closeButton);
|
||||
expect(popupElement.isPresent()).toBe(false);
|
||||
});
|
||||
});
|
||||
|
@ -1,6 +1,6 @@
|
||||
'use strict'; // necessary for es6 output in node
|
||||
|
||||
import { browser, element, by, ElementFinder } from 'protractor';
|
||||
import { browser, element, by, ElementArrayFinder, ElementFinder } from 'protractor';
|
||||
|
||||
// Angular E2E Testing Guide:
|
||||
// https://docs.angularjs.org/guide/e2e-testing
|
||||
@ -20,6 +20,12 @@ describe('PhoneCat Application', function() {
|
||||
|
||||
describe('View: Phone list', function() {
|
||||
|
||||
// Helpers
|
||||
const waitForCount = (elems: ElementArrayFinder, count: number) => {
|
||||
// Wait for the list to stabilize, which may take a while (e.g. due to animations).
|
||||
browser.wait(() => elems.count().then(c => c === count), 5000);
|
||||
};
|
||||
|
||||
beforeEach(function() {
|
||||
browser.get('index.html#!/phones');
|
||||
});
|
||||
@ -28,13 +34,16 @@ describe('PhoneCat Application', function() {
|
||||
let phoneList = element.all(by.repeater('phone in $ctrl.phones'));
|
||||
let query = element(by.model('$ctrl.query'));
|
||||
|
||||
waitForCount(phoneList, 20);
|
||||
expect(phoneList.count()).toBe(20);
|
||||
|
||||
query.sendKeys('nexus');
|
||||
waitForCount(phoneList, 1);
|
||||
expect(phoneList.count()).toBe(1);
|
||||
|
||||
query.clear();
|
||||
query.sendKeys('motorola');
|
||||
waitForCount(phoneList, 8);
|
||||
expect(phoneList.count()).toBe(8);
|
||||
});
|
||||
|
||||
@ -51,6 +60,7 @@ describe('PhoneCat Application', function() {
|
||||
}
|
||||
|
||||
queryField.sendKeys('tablet'); // Let's narrow the dataset to make the assertions shorter
|
||||
waitForCount(phoneNameColumn, 2);
|
||||
|
||||
expect(getNames()).toEqual([
|
||||
'Motorola XOOM\u2122 with Wi-Fi',
|
||||
@ -66,10 +76,16 @@ describe('PhoneCat Application', function() {
|
||||
});
|
||||
|
||||
it('should render phone specific links', function() {
|
||||
let phoneList = element.all(by.repeater('phone in $ctrl.phones'));
|
||||
let query = element(by.model('$ctrl.query'));
|
||||
query.sendKeys('nexus');
|
||||
|
||||
element.all(by.css('.phones li a')).first().click();
|
||||
query.sendKeys('nexus');
|
||||
waitForCount(phoneList, 1);
|
||||
|
||||
let nexusPhone = phoneList.first();
|
||||
let detailLink = nexusPhone.all(by.css('a')).first()
|
||||
|
||||
detailLink.click();
|
||||
expect(browser.getLocationAbsUrl()).toBe('/phones/nexus-s');
|
||||
});
|
||||
|
||||
|
@ -202,10 +202,10 @@ The following are some of the key AngularJS built-in directives and their equiva
|
||||
|
||||
### Bootstrapping
|
||||
|
||||
<code-example hideCopy path="ajs-quick-reference/src/main.ts" title="main.ts" linenums="false"></code-example>
|
||||
<code-example hideCopy path="ajs-quick-reference/src/main.ts" header="main.ts" linenums="false"></code-example>
|
||||
<br>
|
||||
|
||||
<code-example hideCopy path="ajs-quick-reference/src/app/app.module.1.ts" title="app.module.ts" linenums="false"></code-example>
|
||||
<code-example hideCopy path="ajs-quick-reference/src/app/app.module.1.ts" header="app.module.ts" linenums="false"></code-example>
|
||||
|
||||
|
||||
Angular doesn't have a bootstrap directive.
|
||||
|
@ -37,7 +37,7 @@ To get started with adding Angular animations to your project, import the animat
|
||||
|
||||
Import `BrowserAnimationsModule`, which introduces the animation capabilities into your Angular root application module.
|
||||
|
||||
<code-example path="animations/src/app/app.module.1.ts" title="src/app/app.module.ts" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/app.module.1.ts" header="src/app/app.module.ts" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -49,7 +49,7 @@ Import `BrowserAnimationsModule`, which introduces the animation capabilities in
|
||||
|
||||
If you plan to use specific animation functions in component files, import those functions from `@angular/animations`.
|
||||
|
||||
<code-example path="animations/src/app/app.component.ts" title="src/app/app.component.ts" region="imports" language="typescript">
|
||||
<code-example path="animations/src/app/app.component.ts" header="src/app/app.component.ts" region="imports" language="typescript">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -61,7 +61,7 @@ If you plan to use specific animation functions in component files, import those
|
||||
|
||||
In the component file, add a metadata property called `animations:` within the `@Component()` decorator. You put the trigger that defines an animation within the `animations` metadata property.
|
||||
|
||||
<code-example path="animations/src/app/app.component.ts" title="src/app/app.component.ts" region="decorator" language="typescript">
|
||||
<code-example path="animations/src/app/app.component.ts" header="src/app/app.component.ts" region="decorator" language="typescript">
|
||||
</code-example>
|
||||
|
||||
## Animating a simple transition
|
||||
@ -82,12 +82,12 @@ Use the `style()` function to define a set of styles to associate with a given s
|
||||
|
||||
Let's see how Angular's `state()` function works with the `style()` function to set CSS style attributes. In this code snippet, multiple style attributes are set at the same time for the state. In the `open` state, the button has a height of 200 pixels, an opacity of 1, and a background color of yellow.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" region="state1" language="typescript">
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" region="state1" language="typescript">
|
||||
</code-example>
|
||||
|
||||
In the `closed` state, shown below, the button has a height of 100 pixels, an opacity of 0.5, and a background color of green.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" region="state2" language="typescript">
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" region="state2" language="typescript">
|
||||
</code-example>
|
||||
|
||||
### Transitions and timing
|
||||
@ -134,7 +134,7 @@ The third argument, `easing`, controls how the animation [accelerates and decele
|
||||
|
||||
This example provides a state transition from `open` to `closed` with a one second transition between states.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" language="typescript"
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" language="typescript"
|
||||
region="transition1">
|
||||
</code-example>
|
||||
|
||||
@ -142,7 +142,7 @@ In the code snippet above, the `=>` operator indicates unidirectional transition
|
||||
|
||||
This example adds a state transition from the `closed` state to the `open` state with a 0.5 second transition animation arc.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" language="typescript"
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" language="typescript"
|
||||
region="transition2">
|
||||
</code-example>
|
||||
|
||||
@ -180,7 +180,7 @@ In this example, we'll name the trigger `openClose`, and attach it to the `butto
|
||||
|
||||
Animations are defined in the metadata of the component that controls the HTML element to be animated. Put the code that defines your animations under the `animations:` property within the `@Component()` decorator.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" language="typescript"
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" language="typescript"
|
||||
region="component" linenums="false">
|
||||
</code-example>
|
||||
|
||||
@ -194,7 +194,7 @@ The animation is executed or triggered when the expression value changes to a ne
|
||||
|
||||
The following code snippet binds the trigger to the value of the `isOpen` property.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.1.html" title="src/app/open-close.component.html"
|
||||
<code-example path="animations/src/app/open-close.component.1.html" header="src/app/open-close.component.html"
|
||||
region="compare">
|
||||
</code-example>
|
||||
|
||||
@ -216,15 +216,15 @@ Here are the code files discussed in the transition example.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="src/app/open-close.component.ts" path="animations/src/app/open-close.component.ts" language="typescript"
|
||||
<code-pane header="src/app/open-close.component.ts" path="animations/src/app/open-close.component.ts" language="typescript"
|
||||
region="component">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/open-close.component.html" path="animations/src/app/open-close.component.1.html"
|
||||
<code-pane header="src/app/open-close.component.html" path="animations/src/app/open-close.component.1.html"
|
||||
region="trigger">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/open-close.component.css" path="animations/src/app/open-close.component.css">
|
||||
<code-pane header="src/app/open-close.component.css" path="animations/src/app/open-close.component.css">
|
||||
</code-pane>
|
||||
|
||||
</code-tabs>
|
||||
|
@ -8,7 +8,7 @@ This guide explains how to specify metadata and apply available compiler options
|
||||
|
||||
<div class="alert is-helpful"
|
||||
|
||||
<a href="https://www.youtube.com/watch?v=kW9cJsvcsGo">Watch compiler author Tobias Bosch explain the Angular Compiler</a> at AngularConnect 2016.
|
||||
<a href="https://www.youtube.com/watch?v=kW9cJsvcsGo">Watch compiler author Tobias Bosch explain the Angular compiler</a> at AngularConnect 2016.
|
||||
|
||||
</div>
|
||||
|
||||
@ -21,7 +21,7 @@ Angular offers two ways to compile your application:
|
||||
1. **_Just-in-Time_ (JIT)**, which compiles your app in the browser at runtime.
|
||||
1. **_Ahead-of-Time_ (AOT)**, which compiles your app at build time.
|
||||
|
||||
JIT compilation is the default when you run the _build-only_ or the _build-and-serve-locally_ CLI commands:
|
||||
JIT compilation is the default when you run the [`ng build`](cli/build) (build only) or [`ng serve`](cli/serve) (build and serve locally) CLI commands:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng build
|
||||
@ -30,7 +30,7 @@ JIT compilation is the default when you run the _build-only_ or the _build-and-s
|
||||
|
||||
{@a compile}
|
||||
|
||||
For AOT compilation, append the `--aot` flags to the _build-only_ or the _build-and-serve-locally_ CLI commands:
|
||||
For AOT compilation, include the `--aot` option with the `ng build` or `ng serve` command:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng build --aot
|
||||
@ -41,7 +41,7 @@ For AOT compilation, append the `--aot` flags to the _build-only_ or the _build-
|
||||
|
||||
The `ng build` command with the `--prod` meta-flag (`ng build --prod`) compiles with AOT by default.
|
||||
|
||||
See the [CLI documentation](https://github.com/angular/angular-cli/wiki) for details, especially the [`build` topic](https://github.com/angular/angular-cli/wiki/build).
|
||||
See the [CLI command reference](cli) and [Building and serving Angular apps](guide/build) for more information.
|
||||
|
||||
</div>
|
||||
|
||||
|
@ -15,7 +15,7 @@ Its `selectHero()` method sets a `selectedHero` property when the user clicks to
|
||||
The component acquires the heroes from a service, which is a TypeScript [parameter property](http://www.typescriptlang.org/docs/handbook/classes.html#parameter-properties) on the constructor.
|
||||
The service is provided to the component through the dependency injection system.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" title="src/app/hero-list.component.ts (class)" region="class"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" header="src/app/hero-list.component.ts (class)" region="class"></code-example>
|
||||
|
||||
Angular creates, updates, and destroys components as the user moves through the application. Your app can take action at each moment in this lifecycle through optional [lifecycle hooks](guide/lifecycle-hooks), like `ngOnInit()`.
|
||||
|
||||
@ -31,7 +31,7 @@ In addition to containing or pointing to the template, the `@Component` metadata
|
||||
|
||||
Here's an example of basic metadata for `HeroListComponent`.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" title="src/app/hero-list.component.ts (metadata)" region="metadata"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" header="src/app/hero-list.component.ts (metadata)" region="metadata"></code-example>
|
||||
|
||||
This example shows some of the most useful `@Component` configuration options:
|
||||
|
||||
@ -63,7 +63,7 @@ A template looks like regular HTML, except that it also contains Angular [templa
|
||||
|
||||
For example, here is a template for the Tutorial's `HeroListComponent`.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.html" title="src/app/hero-list.component.html"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.html" header="src/app/hero-list.component.html"></code-example>
|
||||
|
||||
This template uses typical HTML elements like `<h2>` and `<p>`, and also includes Angular template-syntax elements, `*ngFor`, `{{hero.name}}`, `(click)`, `[hero]`, and `<app-hero-detail>`. The template-syntax elements tell Angular how to render the HTML to the screen, using program logic and data.
|
||||
|
||||
@ -87,7 +87,7 @@ The following diagram shows the four forms of data binding markup. Each form has
|
||||
|
||||
This example from the `HeroListComponent` template uses three of these forms.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.1.html" linenums="false" title="src/app/hero-list.component.html (binding)" region="binding"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.1.html" linenums="false" header="src/app/hero-list.component.html (binding)" region="binding"></code-example>
|
||||
|
||||
* The `{{hero.name}}` [*interpolation*](guide/displaying-data#interpolation)
|
||||
displays the component's `hero.name` property value within the `<li>` element.
|
||||
@ -101,7 +101,7 @@ Two-way data binding (used mainly in [template-driven forms](guide/forms))
|
||||
combines property and event binding in a single notation.
|
||||
Here's an example from the `HeroDetailComponent` template that uses two-way data binding with the `ngModel` directive.
|
||||
|
||||
<code-example path="architecture/src/app/hero-detail.component.html" linenums="false" title="src/app/hero-detail.component.html (ngModel)" region="ngModel"></code-example>
|
||||
<code-example path="architecture/src/app/hero-detail.component.html" linenums="false" header="src/app/hero-detail.component.html (ngModel)" region="ngModel"></code-example>
|
||||
|
||||
In two-way binding, a data property value flows to the input box from the component as with property binding.
|
||||
The user's changes also flow back to the component, resetting the property to the latest value,
|
||||
@ -164,7 +164,7 @@ Just as for components, the metadata for a directive associates the decorated cl
|
||||
*Structural directives* alter layout by adding, removing, and replacing elements in the DOM.
|
||||
The example template uses two built-in structural directives to add application logic to how the view is rendered.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.1.html" linenums="false" title="src/app/hero-list.component.html (structural)" region="structural"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.1.html" linenums="false" header="src/app/hero-list.component.html (structural)" region="structural"></code-example>
|
||||
|
||||
* [`*ngFor`](guide/displaying-data#ngFor) is an iterative; it tells Angular to stamp out one `<li>` per hero in the `heroes` list.
|
||||
* [`*ngIf`](guide/displaying-data#ngIf) is a conditional; it includes the `HeroDetail` component only if a selected hero exists.
|
||||
@ -176,7 +176,7 @@ In templates they look like regular HTML attributes, hence the name.
|
||||
|
||||
The `ngModel` directive, which implements two-way data binding, is an example of an attribute directive. `ngModel` modifies the behavior of an existing element (typically `<input>`) by setting its display value property and responding to change events.
|
||||
|
||||
<code-example path="architecture/src/app/hero-detail.component.html" linenums="false" title="src/app/hero-detail.component.html (ngModel)" region="ngModel"></code-example>
|
||||
<code-example path="architecture/src/app/hero-detail.component.html" linenums="false" header="src/app/hero-detail.component.html (ngModel)" region="ngModel"></code-example>
|
||||
|
||||
Angular has more pre-defined directives that either alter the layout structure
|
||||
(for example, [ngSwitch](guide/template-syntax#ngSwitch))
|
||||
|
@ -23,7 +23,7 @@ An NgModule is defined by a class decorated with `@NgModule()`. The `@NgModule()
|
||||
|
||||
Here's a simple root NgModule definition.
|
||||
|
||||
<code-example path="architecture/src/app/mini-app.ts" region="module" title="src/app/app.module.ts" linenums="false"></code-example>
|
||||
<code-example path="architecture/src/app/mini-app.ts" region="module" header="src/app/app.module.ts" linenums="false"></code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
|
@ -4,13 +4,13 @@ After you understand the basic Angular building blocks, you can begin to learn m
|
||||
about the features and tools that are available to help you develop and deliver Angular applications.
|
||||
Here are some key features.
|
||||
|
||||
## Responsive programming tools
|
||||
## Responsive programming
|
||||
|
||||
* [Lifecycle hooks](guide/lifecycle-hooks): Tap into key moments in the lifetime of a component, from its creation to its destruction, by implementing the lifecycle hook interfaces.
|
||||
|
||||
* [Observables and event processing](guide/observables): How to use observables with components and services to publish and subscribe to messages of any type, such as user-interaction events and asynchronous operation results.
|
||||
|
||||
## Client-server interaction tools
|
||||
## Client-server interaction
|
||||
|
||||
* [HTTP](guide/http): Communicate with a server to get data, save data, and invoke server-side actions with an HTTP client.
|
||||
|
||||
@ -28,23 +28,28 @@ without deep knowledge of animation techniques or CSS.
|
||||
|
||||
## Support for the development cycle
|
||||
|
||||
* [Compilation](guide/aot-compiler): Angular provides just-in-time (JIT) compilation for the development environment, and ahead-of-time (AOT) compilation for the production environment.
|
||||
|
||||
* [Testing platform](guide/testing): Run unit tests on your application parts as they interact with the Angular framework.
|
||||
|
||||
* [Internationalization](guide/i18n): Make your app available in multiple languages with Angular's internationalization (i18n) tools.
|
||||
|
||||
* [Compilation](guide/aot-compiler): Angular provides just-in-time (JIT) compilation for the development environment, and ahead-of-time (AOT) compilation for the production environment.
|
||||
|
||||
* [Security guidelines](guide/security): Learn about Angular's built-in protections against common web-app vulnerabilities and attacks such as cross-site scripting attacks.
|
||||
|
||||
## Setup and deployment tools
|
||||
## Setup, build, and deployment configuration
|
||||
|
||||
* [Setup for local development](guide/setup): Set up a new project for development with QuickStart.
|
||||
* [CLI Command Reference](cli): The Angular CLI is a command-line tool that you use to create projects, generate application and library code, and perform a variety of ongoing development tasks such as testing, bundling, and deployment.
|
||||
|
||||
* [Installation](guide/npm-packages): The [Angular CLI](https://cli.angular.io/), Angular applications, and Angular itself depend on features and functionality provided by libraries that are available as [npm](https://docs.npmjs.com/) packages.
|
||||
* [Workspace and File Structure](guide/file-structure): Understand the structure of Angular workspace and project folders.
|
||||
|
||||
* [npm Packages](guide/npm-packages): The Angular Framework, Angular CLI, and components used by Angular applications are packaged as [npm](https://docs.npmjs.com/) packages and distributed via the npm registry. The Angular CLI creates a default `package.json` file, which specifies a starter set of packages that work well together and jointly support many common application scenarios.
|
||||
|
||||
* [TypeScript configuration](guide/typescript-configuration): TypeScript is the primary language for Angular application development.
|
||||
|
||||
* [Browser support](guide/browser-support): Make your apps compatible across a wide range of browsers.
|
||||
|
||||
* [Building and Serving](guide/build): Learn to define different build and proxy server configurations for your project, such as development, staging, and production.
|
||||
|
||||
* [Deployment](guide/deployment): Learn techniques for deploying your Angular application to a remote server.
|
||||
|
||||
|
||||
|
@ -28,11 +28,11 @@ available to components through *dependency injection*.
|
||||
|
||||
Here's an example of a service class that logs to the browser console.
|
||||
|
||||
<code-example path="architecture/src/app/logger.service.ts" linenums="false" title="src/app/logger.service.ts (class)" region="class"></code-example>
|
||||
<code-example path="architecture/src/app/logger.service.ts" linenums="false" header="src/app/logger.service.ts (class)" region="class"></code-example>
|
||||
|
||||
Services can depend on other services. For example, here's a `HeroService` that depends on the `Logger` service, and also uses `BackendService` to get heroes. That service in turn might depend on the `HttpClient` service to fetch heroes asynchronously from a server.
|
||||
|
||||
<code-example path="architecture/src/app/hero.service.ts" linenums="false" title="src/app/hero.service.ts (class)" region="class"></code-example>
|
||||
<code-example path="architecture/src/app/hero.service.ts" linenums="false" header="src/app/hero.service.ts (class)" region="class"></code-example>
|
||||
|
||||
## Dependency injection (DI)
|
||||
|
||||
@ -62,7 +62,7 @@ A dependency doesn't have to be a service—it could be a function, for exam
|
||||
|
||||
When Angular creates a new instance of a component class, it determines which services or other dependencies that component needs by looking at the constructor parameter types. For example, the constructor of `HeroListComponent` needs `HeroService`.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" title="src/app/hero-list.component.ts (constructor)" region="ctor"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" header="src/app/hero-list.component.ts (constructor)" region="ctor"></code-example>
|
||||
|
||||
When Angular discovers that a component depends on a service, it first checks if the injector has any existing instances of that service. If a requested service instance doesn't yet exist, the injector makes one using the registered provider, and adds it to the injector before returning the service to Angular.
|
||||
|
||||
@ -82,7 +82,7 @@ or you can register providers with specific modules or components.
|
||||
You register providers in the metadata of the service (in the `@Injectable()` decorator),
|
||||
or in the `@NgModule()` or `@Component()` metadata
|
||||
|
||||
* By default, the Angular CLI command `ng generate service` registers a provider with the root injector for your service by including provider metadata in the `@Injectable()` decorator. The tutorial uses this method to register the provider of HeroService class definition.
|
||||
* By default, the Angular CLI command [`ng generate service`](cli/generate) registers a provider with the root injector for your service by including provider metadata in the `@Injectable()` decorator. The tutorial uses this method to register the provider of HeroService class definition.
|
||||
|
||||
```
|
||||
@Injectable({
|
||||
@ -111,6 +111,6 @@ or in the `@NgModule()` or `@Component()` metadata
|
||||
service with each new instance of that component.
|
||||
At the component level, register a service provider in the `providers` property of the `@Component()` metadata.
|
||||
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" title="src/app/hero-list.component.ts (component providers)" region="providers"></code-example>
|
||||
<code-example path="architecture/src/app/hero-list.component.ts" linenums="false" header="src/app/hero-list.component.ts (component providers)" region="providers"></code-example>
|
||||
|
||||
For more detailed information, see the [Dependency Injection](guide/dependency-injection) section.
|
||||
|
@ -37,13 +37,13 @@ This page demonstrates building a simple _appHighlight_ attribute
|
||||
directive to set an element's background color
|
||||
when the user hovers over that element. You can apply it like this:
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" linenums="false" title="src/app/app.component.html (applied)" region="applied"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" linenums="false" header="src/app/app.component.html (applied)" region="applied"></code-example>
|
||||
|
||||
{@a write-directive}
|
||||
|
||||
### Write the directive code
|
||||
|
||||
Create the directive class file in a terminal window with this CLI command.
|
||||
Create the directive class file in a terminal window with the CLI command [`ng generate directive`](cli/generate).
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng generate directive highlight
|
||||
@ -59,7 +59,7 @@ _Directives_ must be declared in [Angular Modules](guide/ngmodules) in the same
|
||||
|
||||
The generated `src/app/highlight.directive.ts` is as follows:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.0.ts" title="src/app/highlight.directive.ts"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.0.ts" header="src/app/highlight.directive.ts"></code-example>
|
||||
|
||||
The imported `Directive` symbol provides Angular the `@Directive` decorator.
|
||||
|
||||
@ -92,7 +92,7 @@ Exporting `HighlightDirective` makes the directive accessible.
|
||||
|
||||
Now edit the generated `src/app/highlight.directive.ts` to look as follows:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.1.ts" title="src/app/highlight.directive.ts"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.1.ts" header="src/app/highlight.directive.ts"></code-example>
|
||||
|
||||
The `import` statement specifies an additional `ElementRef` symbol from the Angular `core` library:
|
||||
|
||||
@ -111,7 +111,7 @@ This first implementation sets the background color of the host element to yello
|
||||
|
||||
To use the new `HighlightDirective`, add a paragraph (`<p>`) element to the template of the root `AppComponent` and apply the directive as an attribute.
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" title="src/app/app.component.html" region="applied"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" header="src/app/app.component.html" region="applied"></code-example>
|
||||
|
||||
Now run the application to see the `HighlightDirective` in action.
|
||||
|
||||
@ -136,12 +136,12 @@ and respond by setting or clearing the highlight color.
|
||||
|
||||
Begin by adding `HostListener` to the list of imported symbols.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" title="src/app/highlight.directive.ts (imports)" region="imports"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" header="src/app/highlight.directive.ts (imports)" region="imports"></code-example>
|
||||
|
||||
Then add two eventhandlers that respond when the mouse enters or leaves,
|
||||
each adorned by the `HostListener` decorator.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" title="src/app/highlight.directive.ts (mouse-methods)" region="mouse-methods"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" header="src/app/highlight.directive.ts (mouse-methods)" region="mouse-methods"></code-example>
|
||||
|
||||
The `@HostListener` decorator lets you subscribe to events of the DOM
|
||||
element that hosts an attribute directive, the `<p>` in this case.
|
||||
@ -162,11 +162,11 @@ The handlers delegate to a helper method that sets the color on the host DOM ele
|
||||
The helper method, `highlight`, was extracted from the constructor.
|
||||
The revised constructor simply declares the injected `el: ElementRef`.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" title="src/app/highlight.directive.ts (constructor)" region="ctor"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" header="src/app/highlight.directive.ts (constructor)" region="ctor"></code-example>
|
||||
|
||||
Here's the updated directive in full:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" title="src/app/highlight.directive.ts"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" header="src/app/highlight.directive.ts"></code-example>
|
||||
|
||||
Run the app and confirm that the background color appears when
|
||||
the mouse hovers over the `p` and disappears as it moves out.
|
||||
@ -183,11 +183,11 @@ Currently the highlight color is hard-coded _within_ the directive. That's infle
|
||||
In this section, you give the developer the power to set the highlight color while applying the directive.
|
||||
|
||||
Begin by adding `Input` to the list of symbols imported from `@angular/core`.
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.3.ts" linenums="false" title="src/app/highlight.directive.ts (imports)" region="imports"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.3.ts" linenums="false" header="src/app/highlight.directive.ts (imports)" region="imports"></code-example>
|
||||
|
||||
Add a `highlightColor` property to the directive class like this:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" title="src/app/highlight.directive.ts (highlightColor)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" header="src/app/highlight.directive.ts (highlightColor)" region="color"></code-example>
|
||||
|
||||
{@a input}
|
||||
|
||||
@ -200,19 +200,19 @@ Without that input metadata, Angular rejects the binding; see [below](guide/attr
|
||||
|
||||
Try it by adding the following directive binding variations to the `AppComponent` template:
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" linenums="false" title="src/app/app.component.html (excerpt)" region="color-1"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" linenums="false" header="src/app/app.component.html (excerpt)" region="color-1"></code-example>
|
||||
|
||||
Add a `color` property to the `AppComponent`.
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.1.ts" linenums="false" title="src/app/app.component.ts (class)" region="class"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.1.ts" linenums="false" header="src/app/app.component.ts (class)" region="class"></code-example>
|
||||
|
||||
Let it control the highlight color with a property binding.
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" linenums="false" title="src/app/app.component.html (excerpt)" region="color-2"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.1.html" linenums="false" header="src/app/app.component.html (excerpt)" region="color-2"></code-example>
|
||||
|
||||
That's good, but it would be nice to _simultaneously_ apply the directive and set the color _in the same attribute_ like this.
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (color)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (color)" region="color"></code-example>
|
||||
|
||||
The `[appHighlight]` attribute binding both applies the highlighting directive to the `<p>` element
|
||||
and sets the directive's highlight color with a property binding.
|
||||
@ -221,7 +221,7 @@ That's a crisp, compact syntax.
|
||||
|
||||
You'll have to rename the directive's `highlightColor` property to `appHighlight` because that's now the color property binding name.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" title="src/app/highlight.directive.ts (renamed to match directive selector)" region="color-2"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" header="src/app/highlight.directive.ts (renamed to match directive selector)" region="color-2"></code-example>
|
||||
|
||||
This is disagreeable. The word, `appHighlight`, is a terrible property name and it doesn't convey the property's intent.
|
||||
|
||||
@ -233,23 +233,23 @@ Fortunately you can name the directive property whatever you want _and_ **_alias
|
||||
|
||||
Restore the original property name and specify the selector as the alias in the argument to `@Input`.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" title="src/app/highlight.directive.ts (color property with alias)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" header="src/app/highlight.directive.ts (color property with alias)" region="color"></code-example>
|
||||
|
||||
_Inside_ the directive the property is known as `highlightColor`.
|
||||
_Outside_ the directive, where you bind to it, it's known as `appHighlight`.
|
||||
|
||||
You get the best of both worlds: the property name you want and the binding syntax you want:
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (color)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (color)" region="color"></code-example>
|
||||
|
||||
Now that you're binding via the alias to the `highlightColor`, modify the `onMouseEnter()` method to use that property.
|
||||
If someone neglects to bind to `appHighlightColor`, highlight the host element in red:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.3.ts" linenums="false" title="src/app/highlight.directive.ts (mouse enter)" region="mouse-enter"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.3.ts" linenums="false" header="src/app/highlight.directive.ts (mouse enter)" region="mouse-enter"></code-example>
|
||||
|
||||
Here's the latest version of the directive class.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.3.ts" linenums="false" title="src/app/highlight.directive.ts (excerpt)"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.3.ts" linenums="false" header="src/app/highlight.directive.ts (excerpt)"></code-example>
|
||||
|
||||
## Write a harness to try it
|
||||
|
||||
@ -259,11 +259,11 @@ lets you pick the highlight color with a radio button and bind your color choice
|
||||
|
||||
Update <code>app.component.html</code> as follows:
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (v2)" region="v2"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (v2)" region="v2"></code-example>
|
||||
|
||||
Revise the `AppComponent.color` so that it has no initial value.
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.ts" linenums="false" title="src/app/app.component.ts (class)" region="class"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.ts" linenums="false" header="src/app/app.component.ts (class)" region="class"></code-example>
|
||||
|
||||
Here are the harness and directive in action.
|
||||
|
||||
@ -283,12 +283,12 @@ Let the template developer set the default color.
|
||||
|
||||
Add a second **input** property to `HighlightDirective` called `defaultColor`:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" title="src/app/highlight.directive.ts (defaultColor)" region="defaultColor"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" header="src/app/highlight.directive.ts (defaultColor)" region="defaultColor"></code-example>
|
||||
|
||||
Revise the directive's `onMouseEnter` so that it first tries to highlight with the `highlightColor`,
|
||||
then with the `defaultColor`, and falls back to "red" if both properties are undefined.
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" title="src/app/highlight.directive.ts (mouse-enter)" region="mouse-enter"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" header="src/app/highlight.directive.ts (mouse-enter)" region="mouse-enter"></code-example>
|
||||
|
||||
How do you bind to a second property when you're already binding to the `appHighlight` attribute name?
|
||||
|
||||
@ -296,7 +296,7 @@ As with components, you can add as many directive property bindings as you need
|
||||
The developer should be able to write the following template HTML to both bind to the `AppComponent.color`
|
||||
and fall back to "violet" as the default color.
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (defaultColor)" region="defaultColor"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (defaultColor)" region="defaultColor"></code-example>
|
||||
|
||||
Angular knows that the `defaultColor` binding belongs to the `HighlightDirective`
|
||||
because you made it _public_ with the `@Input` decorator.
|
||||
@ -319,12 +319,12 @@ This page covered how to:
|
||||
The final source code follows:
|
||||
|
||||
<code-tabs>
|
||||
<code-pane title="app/app.component.ts" path="attribute-directives/src/app/app.component.ts"></code-pane>
|
||||
<code-pane title="app/app.component.html" path="attribute-directives/src/app/app.component.html"></code-pane>
|
||||
<code-pane title="app/highlight.directive.ts" path="attribute-directives/src/app/highlight.directive.ts"></code-pane>
|
||||
<code-pane title="app/app.module.ts" path="attribute-directives/src/app/app.module.ts"></code-pane>
|
||||
<code-pane title="main.ts" path="attribute-directives/src/main.ts"></code-pane>
|
||||
<code-pane title="index.html" path="attribute-directives/src/index.html"></code-pane>
|
||||
<code-pane header="app/app.component.ts" path="attribute-directives/src/app/app.component.ts"></code-pane>
|
||||
<code-pane header="app/app.component.html" path="attribute-directives/src/app/app.component.html"></code-pane>
|
||||
<code-pane header="app/highlight.directive.ts" path="attribute-directives/src/app/highlight.directive.ts"></code-pane>
|
||||
<code-pane header="app/app.module.ts" path="attribute-directives/src/app/app.module.ts"></code-pane>
|
||||
<code-pane header="main.ts" path="attribute-directives/src/main.ts"></code-pane>
|
||||
<code-pane header="index.html" path="attribute-directives/src/index.html"></code-pane>
|
||||
</code-tabs>
|
||||
|
||||
|
||||
@ -338,11 +338,11 @@ You can also experience and download the <live-example title="Attribute Directiv
|
||||
In this demo, the `highlightColor` property is an ***input*** property of
|
||||
the `HighlightDirective`. You've seen it applied without an alias:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" title="src/app/highlight.directive.ts (color)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.2.ts" linenums="false" header="src/app/highlight.directive.ts (color)" region="color"></code-example>
|
||||
|
||||
You've seen it with an alias:
|
||||
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" title="src/app/highlight.directive.ts (color)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/highlight.directive.ts" linenums="false" header="src/app/highlight.directive.ts (color)" region="color"></code-example>
|
||||
|
||||
Either way, the `@Input` decorator tells Angular that this property is
|
||||
_public_ and available for binding by a parent component.
|
||||
@ -374,7 +374,7 @@ You can tell if `@Input` is needed by the position of the property name in a bin
|
||||
|
||||
Now apply that reasoning to the following example:
|
||||
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (color)" region="color"></code-example>
|
||||
<code-example path="attribute-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (color)" region="color"></code-example>
|
||||
|
||||
* The `color` property in the expression on the right belongs to the template's component.
|
||||
The template and its component trust each other.
|
||||
|
@ -12,7 +12,7 @@ Every application has at least one Angular module, the _root_ module
|
||||
that you bootstrap to launch the application.
|
||||
By convention, it is usually called `AppModule`.
|
||||
|
||||
If you use the CLI to generate an app, the default `AppModule` is as follows:
|
||||
If you use the [Angular CLI](cli) to generate an app, the default `AppModule` is as follows:
|
||||
|
||||
```typescript
|
||||
/* JavaScript imports */
|
||||
@ -52,7 +52,7 @@ The `@NgModule` decorator identifies `AppModule` as an `NgModule` class.
|
||||
* **_bootstrap_**—the _root_ component that Angular creates and inserts
|
||||
into the `index.html` host web page.
|
||||
|
||||
The default CLI application only has one component, `AppComponent`, so it
|
||||
The default application created by the Angular CLI only has one component, `AppComponent`, so it
|
||||
is in both the `declarations` and the `bootstrap` arrays.
|
||||
|
||||
{@a declarations}
|
||||
@ -106,18 +106,18 @@ To use a directive, component, or pipe in a module, you must do a few things:
|
||||
Those three steps look like the following. In the file where you create your directive, export it.
|
||||
The following example, named `ItemDirective` is the default directive structure that the CLI generates in its own file, `item.directive.ts`:
|
||||
|
||||
<code-example path="bootstrapping/src/app/item.directive.ts" region="directive" title="src/app/item.directive.ts" linenums="false">
|
||||
<code-example path="bootstrapping/src/app/item.directive.ts" region="directive" header="src/app/item.directive.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The key point here is that you have to export it so you can import it elsewhere. Next, import it
|
||||
into the NgModule, in this example `app.module.ts`, with a JavaScript import statement:
|
||||
|
||||
<code-example path="bootstrapping/src/app/app.module.ts" region="directive-import" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="bootstrapping/src/app/app.module.ts" region="directive-import" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
And in the same file, add it to the `@NgModule` `declarations` array:
|
||||
|
||||
<code-example path="bootstrapping/src/app/app.module.ts" region="declarations" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="bootstrapping/src/app/app.module.ts" region="declarations" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
|
@ -122,7 +122,7 @@ Note that polyfills cannot magically transform an old, slow browser into a moder
|
||||
|
||||
## Enabling polyfills
|
||||
|
||||
[Angular CLI](https://github.com/angular/angular-cli/wiki) users enable polyfills through the `src/polyfills.ts` file that
|
||||
[Angular CLI](cli) users enable polyfills through the `src/polyfills.ts` file that
|
||||
the CLI created with your project.
|
||||
|
||||
This file incorporates the mandatory and many of the optional polyfills as JavaScript `import` statements.
|
||||
@ -140,7 +140,7 @@ For example, [if you need the web animations polyfill](http://caniuse.com/#feat=
|
||||
|
||||
Then open the `polyfills.ts` file and un-comment the corresponding `import` statement as in the following example:
|
||||
|
||||
<code-example title="src/polyfills.ts">
|
||||
<code-example header="src/polyfills.ts">
|
||||
/**
|
||||
* Required to support Web Animations `@angular/platform-browser/animations`.
|
||||
* Needed for: All but Chrome, Firefox and Opera. http://caniuse.com/#feat=web-animation
|
||||
@ -553,7 +553,7 @@ computed with the <a href="http://closure-compiler.appspot.com/home">closure com
|
||||
|
||||
If you are not using the CLI, you should add your polyfill scripts directly to the host web page (`index.html`), perhaps like this.
|
||||
|
||||
<code-example title="src/index.html">
|
||||
<code-example header="src/index.html">
|
||||
<!-- pre-zone polyfills -->
|
||||
<script src="node_modules/core-js/client/shim.min.js"></script>
|
||||
<script src="node_modules/web-animations-js/web-animations.min.js"></script>
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Building and serving Angular apps
|
||||
|
||||
*intro - here are some topics of interest in the app development cycle*
|
||||
This page discusses build-specific configuration options for Angular projects.
|
||||
|
||||
{@a app-environments}
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
You can define different named build configurations for your project, such as *stage* and *production*, with different defaults.
|
||||
|
||||
Each named build configuration can have defaults for any of the options that apply to the various build targets, such as `build`, `serve`, and `test`. The CLI `build`, `serve`, and `test` commands can then replace files with appropriate versions for your intended target environment.
|
||||
Each named build configuration can have defaults for any of the options that apply to the various build targets, such as `build`, `serve`, and `test`. The [Angular CLI](cli) `build`, `serve`, and `test` commands can then replace files with appropriate versions for your intended target environment.
|
||||
|
||||
The following figure shows how a project has multiple build targets, which can be executed using the named configurations that you define.
|
||||
|
||||
@ -260,50 +260,6 @@ Each budget entry is a JSON object with the following properties:
|
||||
|
||||
</table>
|
||||
|
||||
{@a assets}
|
||||
|
||||
## Adding project assets
|
||||
|
||||
You can configure your project with a set of assets, such as images, to copy directly into the build for a particular build target.
|
||||
|
||||
Each build target section of the CLI configuration file, `angular.json`, has an `assets` section that lists files or folders you want to copy into the build for that target.
|
||||
By default, the `src/assets/` folder and `src/favicon.ico` are copied into a build.
|
||||
|
||||
```
|
||||
"assets": [
|
||||
"src/assets",
|
||||
"src/favicon.ico"
|
||||
]
|
||||
```
|
||||
|
||||
You can edit the assets configuration to extend it for assets outside your project.
|
||||
For example, the following invokes the [node-glob pattern matcher](https://github.com/isaacs/node-glob) using input from a given base folder.
|
||||
It sends output to a folder that is relative to `outDir`, a configuration value that defaults to `dist/`*project-name*).
|
||||
The result in this cased is the same as for the default assets configuration.
|
||||
|
||||
```
|
||||
"assets": [
|
||||
{ "glob": "**/*", "input": "src/assets/", "output": "/assets/" },
|
||||
{ "glob": "favicon.ico", "input": "/src", "output": "/" },
|
||||
]
|
||||
```
|
||||
|
||||
You can use this extended configuration to copy assets from outside your project.
|
||||
For instance, you can copy assets from a node package with the following value:
|
||||
|
||||
```
|
||||
"assets": [
|
||||
{ "glob": "**/*", "input": "./node_modules/some-package/images", "output": "/some-package/" },
|
||||
]
|
||||
```
|
||||
|
||||
This makes the contents of `node_modules/some-package/images/` available in the output folder `dist/some-package/`.
|
||||
|
||||
<div class="alert is-critical">
|
||||
|
||||
For reasons of security, the CLI never writes files outside of the project output path.
|
||||
|
||||
</div>
|
||||
|
||||
{@a browser-compat}
|
||||
|
||||
@ -312,7 +268,7 @@ This makes the contents of `node_modules/some-package/images/` available in the
|
||||
The CLI uses [Autoprefixer](https://github.com/postcss/autoprefixer) to ensure compatibility with different browser and browser versions.
|
||||
You may find it necessary to target specific browsers or exclude certain browser versions from your build.
|
||||
|
||||
Internally, Autoprefixer relies on a library called [Browserslist(https://github.com/ai/browserslist)] to figure out which browsers to support with prefixing.
|
||||
Internally, Autoprefixer relies on a library called [Browserslist](https://github.com/browserslist/browserslist) to figure out which browsers to support with prefixing.
|
||||
Browserlist looks for configuration options in a `browserlist` property of the package configuration file, or in a configuration file named `.browserslistrc`.
|
||||
Autoprefixer looks for the Browserlist configuration when it prefixes your CSS.
|
||||
|
||||
@ -331,9 +287,9 @@ Autoprefixer looks for the Browserlist configuration when it prefixes your CSS.
|
||||
last 2 versions
|
||||
```
|
||||
|
||||
See the [browserslist repo](https://github.com/ai/browserslist) for more examples of how to target specific browsers and versions.
|
||||
See the [browserslist repo](https://github.com/browserslist/browserslist) for more examples of how to target specific browsers and versions.
|
||||
|
||||
<div class="alert is-helpful">>
|
||||
<div class="alert is-helpful">
|
||||
Backward compatibility
|
||||
|
||||
If you want to produce a progressive web app and are using [Lighthouse](https://developers.google.com/web/tools/lighthouse/) to grade the project, add the following browserslist entry to your `package.json` file, in order to eliminate the [old flexbox](https://developers.google.com/web/tools/lighthouse/audits/old-flexbox) prefixes:
|
||||
@ -353,7 +309,7 @@ If you want to produce a progressive web app and are using [Lighthouse](https://
|
||||
## Proxying to a backend server
|
||||
|
||||
You can use the [proxying support](https://webpack.js.org/configuration/dev-server/#devserver-proxy) in the `webpack` dev server to divert certain URLs to a backend server, by passing a file to the `--proxy-config` build option.
|
||||
For example, to divert all calls for http://localhost:4200/api to a server running on http://localhost:3000/api, take the following steps.
|
||||
For example, to divert all calls for `http://localhost:4200/api` to a server running on `http://localhost:3000/api`, take the following steps.
|
||||
|
||||
1. Create a file `proxy.conf.json` in the projects `src/` folder, next to `package.json`.
|
||||
|
||||
|
@ -38,7 +38,7 @@ The following example demonstrates how to use `query()` and `stagger()` function
|
||||
|
||||
* Animate each element on screen for 0.5 seconds using a custom-defined easing curve, simultaneously fading it in and un-transforming it.
|
||||
|
||||
<code-example path="animations/src/app/hero-list-page.component.ts" title="src/app/hero-list-page.component.ts" region="page-animations" language="typescript" linenums="false"></code-example>
|
||||
<code-example path="animations/src/app/hero-list-page.component.ts" header="src/app/hero-list-page.component.ts" region="page-animations" language="typescript" linenums="false"></code-example>
|
||||
|
||||
## Parallel animation using group() function
|
||||
|
||||
@ -51,7 +51,7 @@ You've seen how to add a delay between each successive animation. But you may al
|
||||
|
||||
In the following example, using groups on both `:enter` and `:leave` allow for two different timing configurations. They're applied to the same element in parallel, but run independently.
|
||||
|
||||
<code-example path="animations/src/app/hero-list-groups.component.ts" region="animationdef" title="src/app/hero-list-groups.component.ts (excerpt)" language="typescript" linenums="false"></code-example>
|
||||
<code-example path="animations/src/app/hero-list-groups.component.ts" region="animationdef" header="src/app/hero-list-groups.component.ts (excerpt)" language="typescript" linenums="false"></code-example>
|
||||
|
||||
## Sequential vs. parallel animations
|
||||
|
||||
@ -70,11 +70,11 @@ The filter works in real time as you type. Elements leave the page as you type e
|
||||
|
||||
The HTML template contains a trigger called `filterAnimation`.
|
||||
|
||||
<code-example path="animations/src/app/hero-list-page.component.html" title="src/app/hero-list-page.component.html" region="filter-animations"></code-example>
|
||||
<code-example path="animations/src/app/hero-list-page.component.html" header="src/app/hero-list-page.component.html" region="filter-animations"></code-example>
|
||||
|
||||
The component file contains three transitions.
|
||||
|
||||
<code-example path="animations/src/app/hero-list-page.component.ts" title="src/app/hero-list-page.component.ts" region="filter-animations" language="typescript" linenums="false"></code-example>
|
||||
<code-example path="animations/src/app/hero-list-page.component.ts" header="src/app/hero-list-page.component.ts" region="filter-animations" language="typescript" linenums="false"></code-example>
|
||||
|
||||
The animation does the following:
|
||||
|
||||
|
@ -28,7 +28,7 @@ in which two or more components share information.
|
||||
typically adorned with [@Input decorations](guide/template-syntax#inputs-outputs).
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/hero-child.component.ts" title="component-interaction/src/app/hero-child.component.ts">
|
||||
<code-example path="component-interaction/src/app/hero-child.component.ts" header="component-interaction/src/app/hero-child.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -41,7 +41,7 @@ binding its `master` string property to the child's `master` alias,
|
||||
and each iteration's `hero` instance to the child's `hero` property.
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/hero-parent.component.ts" title="component-interaction/src/app/hero-parent.component.ts">
|
||||
<code-example path="component-interaction/src/app/hero-parent.component.ts" header="component-interaction/src/app/hero-parent.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -61,7 +61,7 @@ The running application displays three heroes:
|
||||
E2E test that all children were instantiated and displayed as expected:
|
||||
|
||||
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="parent-to-child" title="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="parent-to-child" header="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -79,7 +79,7 @@ The setter of the `name` input property in the child `NameChildComponent`
|
||||
trims the whitespace from a name and replaces an empty value with default text.
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/name-child.component.ts" title="component-interaction/src/app/name-child.component.ts">
|
||||
<code-example path="component-interaction/src/app/name-child.component.ts" header="component-interaction/src/app/name-child.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -88,7 +88,7 @@ trims the whitespace from a name and replaces an empty value with default text.
|
||||
Here's the `NameParentComponent` demonstrating name variations including a name with all spaces:
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/name-parent.component.ts" title="component-interaction/src/app/name-parent.component.ts">
|
||||
<code-example path="component-interaction/src/app/name-parent.component.ts" header="component-interaction/src/app/name-parent.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -105,7 +105,7 @@ Here's the `NameParentComponent` demonstrating name variations including a name
|
||||
E2E tests of input property setter with empty and non-empty names:
|
||||
|
||||
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="parent-to-child-setter" title="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="parent-to-child-setter" header="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -134,7 +134,7 @@ Learn about `ngOnChanges()` in the [LifeCycle Hooks](guide/lifecycle-hooks) chap
|
||||
This `VersionChildComponent` detects changes to the `major` and `minor` input properties and composes a log message reporting these changes:
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/version-child.component.ts" title="component-interaction/src/app/version-child.component.ts">
|
||||
<code-example path="component-interaction/src/app/version-child.component.ts" header="component-interaction/src/app/version-child.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -143,7 +143,7 @@ This `VersionChildComponent` detects changes to the `major` and `minor` input pr
|
||||
The `VersionParentComponent` supplies the `minor` and `major` values and binds buttons to methods that change them.
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/version-parent.component.ts" title="component-interaction/src/app/version-parent.component.ts">
|
||||
<code-example path="component-interaction/src/app/version-parent.component.ts" header="component-interaction/src/app/version-parent.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -164,7 +164,7 @@ Test that ***both*** input properties are set initially and that button clicks t
|
||||
the expected `ngOnChanges` calls and values:
|
||||
|
||||
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="parent-to-child-onchanges" title="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="parent-to-child-onchanges" header="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -184,7 +184,7 @@ The child's `EventEmitter` property is an ***output property***,
|
||||
as seen in this `VoterComponent`:
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/voter.component.ts" title="component-interaction/src/app/voter.component.ts">
|
||||
<code-example path="component-interaction/src/app/voter.component.ts" header="component-interaction/src/app/voter.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -196,7 +196,7 @@ The parent `VoteTakerComponent` binds an event handler called `onVoted()` that r
|
||||
payload `$event` and updates a counter.
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/votetaker.component.ts" title="component-interaction/src/app/votetaker.component.ts">
|
||||
<code-example path="component-interaction/src/app/votetaker.component.ts" header="component-interaction/src/app/votetaker.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -217,7 +217,7 @@ and the method processes it:
|
||||
Test that clicking the *Agree* and *Disagree* buttons update the appropriate counters:
|
||||
|
||||
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="child-to-parent" title="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="child-to-parent" header="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -240,7 +240,7 @@ The following is a child `CountdownTimerComponent` that repeatedly counts down t
|
||||
It has `start` and `stop` methods that control the clock and it displays a
|
||||
countdown status message in its own template.
|
||||
|
||||
<code-example path="component-interaction/src/app/countdown-timer.component.ts" title="component-interaction/src/app/countdown-timer.component.ts">
|
||||
<code-example path="component-interaction/src/app/countdown-timer.component.ts" header="component-interaction/src/app/countdown-timer.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -249,7 +249,7 @@ countdown status message in its own template.
|
||||
The `CountdownLocalVarParentComponent` that hosts the timer component is as follows:
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/countdown-parent.component.ts" region="lv" title="component-interaction/src/app/countdown-parent.component.ts">
|
||||
<code-example path="component-interaction/src/app/countdown-parent.component.ts" region="lv" header="component-interaction/src/app/countdown-parent.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -284,7 +284,7 @@ match the seconds displayed in the child's status message.
|
||||
Test also that clicking the *Stop* button pauses the countdown timer:
|
||||
|
||||
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="countdown-timer-tests" title="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="countdown-timer-tests" header="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -324,7 +324,7 @@ is solely for the purpose of demonstration.
|
||||
|
||||
Here is the parent, `CountdownViewChildParentComponent`:
|
||||
|
||||
<code-example path="component-interaction/src/app/countdown-parent.component.ts" region="vc" title="component-interaction/src/app/countdown-parent.component.ts">
|
||||
<code-example path="component-interaction/src/app/countdown-parent.component.ts" region="vc" header="component-interaction/src/app/countdown-parent.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -374,7 +374,7 @@ Components outside this component subtree have no access to the service or their
|
||||
This `MissionService` connects the `MissionControlComponent` to multiple `AstronautComponent` children.
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/mission.service.ts" title="component-interaction/src/app/mission.service.ts">
|
||||
<code-example path="component-interaction/src/app/mission.service.ts" header="component-interaction/src/app/mission.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -384,7 +384,7 @@ The `MissionControlComponent` both provides the instance of the service that it
|
||||
(through the `providers` metadata array) and injects that instance into itself through its constructor:
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/missioncontrol.component.ts" title="component-interaction/src/app/missioncontrol.component.ts">
|
||||
<code-example path="component-interaction/src/app/missioncontrol.component.ts" header="component-interaction/src/app/missioncontrol.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -394,7 +394,7 @@ The `AstronautComponent` also injects the service in its constructor.
|
||||
Each `AstronautComponent` is a child of the `MissionControlComponent` and therefore receives its parent's service instance:
|
||||
|
||||
|
||||
<code-example path="component-interaction/src/app/astronaut.component.ts" title="component-interaction/src/app/astronaut.component.ts">
|
||||
<code-example path="component-interaction/src/app/astronaut.component.ts" header="component-interaction/src/app/astronaut.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -433,7 +433,7 @@ Tests click buttons of both the parent `MissionControlComponent` and the `Astron
|
||||
and verify that the history meets expectations:
|
||||
|
||||
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="bidirectional-service" title="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
<code-example path="component-interaction/e2e/src/app.e2e-spec.ts" region="bidirectional-service" header="component-interaction/e2e/src/app.e2e-spec.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -21,7 +21,7 @@ One way to do this is to set the `styles` property in the component metadata.
|
||||
The `styles` property takes an array of strings that contain CSS code.
|
||||
Usually you give it one string, as in the following example:
|
||||
|
||||
<code-example path="component-styles/src/app/hero-app.component.ts" title="src/app/hero-app.component.ts" linenums="false">
|
||||
<code-example path="component-styles/src/app/hero-app.component.ts" header="src/app/hero-app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
## Style scope
|
||||
@ -71,7 +71,7 @@ Use the `:host` pseudo-class selector to target styles in the element that *host
|
||||
targeting elements *inside* the component's template).
|
||||
|
||||
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="host" title="src/app/hero-details.component.css" linenums="false">
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="host" header="src/app/hero-details.component.css" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `:host` selector is the only way to target the host element. You can't reach
|
||||
@ -83,7 +83,7 @@ including another selector inside parentheses after `:host`.
|
||||
|
||||
The next example targets the host element again, but only when it also has the `active` CSS class.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="hostfunction" title="src/app/hero-details.component.css" linenums="false">
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="hostfunction" header="src/app/hero-details.component.css" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### :host-context
|
||||
@ -99,7 +99,7 @@ up to the document root. The `:host-context()` selector is useful when combined
|
||||
The following example applies a `background-color` style to all `<h2>` elements *inside* the component, only
|
||||
if some ancestor element has the CSS class `theme-light`.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="hostcontext" title="src/app/hero-details.component.css" linenums="false">
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="hostcontext" header="src/app/hero-details.component.css" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### (deprecated) `/deep/`, `>>>`, and `::ng-deep`
|
||||
@ -114,7 +114,7 @@ children and content children of the component.
|
||||
The following example targets all `<h3>` elements, from the host element down
|
||||
through this component to all of its child elements in the DOM.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="deep" title="src/app/hero-details.component.css" linenums="false">
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="deep" header="src/app/hero-details.component.css" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -154,7 +154,7 @@ You can add a `styles` array property to the `@Component` decorator.
|
||||
|
||||
Each string in the array defines some CSS for this component.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-app.component.ts" title="src/app/hero-app.component.ts (CSS inline)">
|
||||
<code-example path="component-styles/src/app/hero-app.component.ts" header="src/app/hero-app.component.ts (CSS inline)">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-critical">
|
||||
@ -164,7 +164,7 @@ They are _not inherited_ by any components nested within the template nor by any
|
||||
|
||||
</div>
|
||||
|
||||
The CLI defines an empty `styles` array when you create the component with the `--inline-style` flag.
|
||||
The Angular CLI command [`ng generate component`](cli/generate) defines an empty `styles` array when you create the component with the `--inline-style` flag.
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng generate component hero-app --inline-style
|
||||
@ -176,8 +176,8 @@ You can load styles from external CSS files by adding a `styleUrls` property
|
||||
to a component's `@Component` decorator:
|
||||
|
||||
<code-tabs>
|
||||
<code-pane title="src/app/hero-app.component.ts (CSS in file)" path="component-styles/src/app/hero-app.component.1.ts"></code-pane>
|
||||
<code-pane title="src/app/hero-app.component.css" path="component-styles/src/app/hero-app.component.css"></code-pane>
|
||||
<code-pane header="src/app/hero-app.component.ts (CSS in file)" path="component-styles/src/app/hero-app.component.1.ts"></code-pane>
|
||||
<code-pane header="src/app/hero-app.component.css" path="component-styles/src/app/hero-app.component.css"></code-pane>
|
||||
</code-tabs>
|
||||
|
||||
<div class="alert is-critical">
|
||||
@ -193,7 +193,7 @@ They are _not inherited_ by any components nested within the template nor by any
|
||||
|
||||
</div>
|
||||
|
||||
The CLI creates an empty styles file for you by default and references that file in the component's generated `styleUrls`.
|
||||
When you use the Angular CLI command [`ng generate component`](cli/generate) without the `--inline-style` flag, it creates an empty styles file for you and references that file in the component's generated `styleUrls`.
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng generate component hero-app
|
||||
@ -204,19 +204,20 @@ ng generate component hero-app
|
||||
You can embed CSS styles directly into the HTML template by putting them
|
||||
inside `<style>` tags.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-controls.component.ts" region="inlinestyles" title="src/app/hero-controls.component.ts">
|
||||
<code-example path="component-styles/src/app/hero-controls.component.ts" region="inlinestyles" header="src/app/hero-controls.component.ts">
|
||||
</code-example>
|
||||
|
||||
### Template link tags
|
||||
|
||||
You can also write `<link>` tags into the component's HTML template.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-team.component.ts" region="stylelink" title="src/app/hero-team.component.ts">
|
||||
<code-example path="component-styles/src/app/hero-team.component.ts" region="stylelink" header="src/app/hero-team.component.ts">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-critical">
|
||||
|
||||
When building with the CLI, be sure to include the linked style file among the assets to be copied to the server as described in the [CLI documentation](https://github.com/angular/angular-cli/wiki/stories-asset-configuration).
|
||||
When building with the CLI, be sure to include the linked style file among the assets to be copied to the server as described in the [CLI wiki](https://github.com/angular/angular-cli/wiki/stories-asset-configuration).
|
||||
<!-- 2018-10-16: The link above is still the best source for this information. -->
|
||||
|
||||
Once included, the CLI will include the stylesheet, whether the link tag's href URL is relative to the application root or the component file.
|
||||
|
||||
@ -230,7 +231,7 @@ on the [MDN](https://developer.mozilla.org) site.
|
||||
|
||||
In this case, the URL is relative to the CSS file into which you're importing.
|
||||
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="import" title="src/app/hero-details.component.css (excerpt)">
|
||||
<code-example path="component-styles/src/app/hero-details.component.css" region="import" header="src/app/hero-details.component.css (excerpt)">
|
||||
</code-example>
|
||||
|
||||
### External and global style files
|
||||
@ -239,7 +240,9 @@ When building with the CLI, you must configure the `angular.json` to include _al
|
||||
|
||||
Register **global** style files in the `styles` section which, by default, is pre-configured with the global `styles.css` file.
|
||||
|
||||
See the [CLI documentation](https://github.com/angular/angular-cli/wiki/stories-global-styles) to learn more.
|
||||
See the [CLI wiki](https://github.com/angular/angular-cli/wiki/stories-global-styles) to learn more.
|
||||
<!-- 2018-10-16: The link above is still the best source for this information. -->
|
||||
|
||||
|
||||
### Non-CSS style files
|
||||
|
||||
@ -259,8 +262,10 @@ The CLI build process runs the pertinent CSS preprocessor.
|
||||
|
||||
When generating a component file with `ng generate component`, the CLI emits an empty CSS styles file (`.css`) by default.
|
||||
You can configure the CLI to default to your preferred CSS preprocessor
|
||||
as explained in the [CLI documentation](https://github.com/angular/angular-cli/wiki/stories-css-preprocessors
|
||||
as explained in the [CLI wiki](https://github.com/angular/angular-cli/wiki/stories-css-preprocessors
|
||||
"CSS Preprocessor integration").
|
||||
<!-- 2018-10-16: The link above is still the best source for this information. -->
|
||||
|
||||
|
||||
<div class="alert is-important">
|
||||
|
||||
@ -298,7 +303,7 @@ Choose from the following modes:
|
||||
|
||||
To set the components encapsulation mode, use the `encapsulation` property in the component metadata:
|
||||
|
||||
<code-example path="component-styles/src/app/quest-summary.component.ts" region="encapsulation.native" title="src/app/quest-summary.component.ts" linenums="false">
|
||||
<code-example path="component-styles/src/app/quest-summary.component.ts" region="encapsulation.native" header="src/app/quest-summary.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
`ShadowDom` view encapsulation only works on browsers that have native support
|
||||
|
@ -21,7 +21,7 @@ constructor, and lets the framework provide them.
|
||||
|
||||
The following example shows that `AppComponent` declares its dependence on `LoggerService` and `UserContext`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/app.component.ts" region="ctor" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/app.component.ts" region="ctor" header="src/app/app.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -30,7 +30,7 @@ The following example shows that `AppComponent` declares its dependence on `Logg
|
||||
`UserService`, another service that gathers information about a particular user.
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/user-context.service.ts" region="injectables" title="user-context.service.ts (injection)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/user-context.service.ts" region="injectables" header="user-context.service.ts (injection)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -68,7 +68,7 @@ by providing that service *at the sub-root component for that branch*.
|
||||
This example shows how to make a different instance of `HeroService` available to `HeroesBaseComponent`
|
||||
by adding it to the `providers` array of the `@Component()` decorator of the sub-component.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/sorted-heroes.component.ts" region="injection" title="src/app/sorted-heroes.component.ts (HeroesBaseComponent excerpt)">
|
||||
<code-example path="dependency-injection-in-action/src/app/sorted-heroes.component.ts" region="injection" header="src/app/sorted-heroes.component.ts (HeroesBaseComponent excerpt)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -103,7 +103,7 @@ This is called *sandboxing* because each service and component instance has its
|
||||
|
||||
In this example, `HeroBiosComponent` presents three instances of `HeroBioComponent`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="simple" title="ap/hero-bios.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="simple" header="ap/hero-bios.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -111,7 +111,7 @@ In this example, `HeroBiosComponent` presents three instances of `HeroBioCompone
|
||||
Each `HeroBioComponent` can edit a single hero's biography.
|
||||
`HeroBioComponent` relies on `HeroCacheService` to fetch, cache, and perform other persistence operations on that hero.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-cache.service.ts" region="service" title="src/app/hero-cache.service.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-cache.service.ts" region="service" header="src/app/hero-cache.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -122,7 +122,7 @@ as they'd be competing with each other to determine which hero to cache.
|
||||
Instead, each `HeroBioComponent` gets its *own* `HeroCacheService` instance
|
||||
by listing `HeroCacheService` in its metadata `providers` array.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bio.component.ts" region="component" title="src/app/hero-bio.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bio.component.ts" region="component" header="src/app/hero-bio.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -179,13 +179,13 @@ that parent component becomes the host. The following example covers this second
|
||||
These decorators can be used individually or together, as shown in the example.
|
||||
This `HeroBiosAndContactsComponent` is a revision of `HeroBiosComponent` which you looked at [above](guide/dependency-injection-in-action#hero-bios-component).
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="hero-bios-and-contacts" title="src/app/hero-bios.component.ts (HeroBiosAndContactsComponent)">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="hero-bios-and-contacts" header="src/app/hero-bios.component.ts (HeroBiosAndContactsComponent)">
|
||||
|
||||
</code-example>
|
||||
|
||||
Focus on the template:
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="template" title="dependency-injection-in-action/src/app/hero-bios.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="template" header="dependency-injection-in-action/src/app/hero-bios.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -193,7 +193,7 @@ Now there's a new `<hero-contact>` element between the `<hero-bio>` tags.
|
||||
Angular *projects*, or *transcludes*, the corresponding `HeroContactComponent` into the `HeroBioComponent` view,
|
||||
placing it in the `<ng-content>` slot of the `HeroBioComponent` template.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bio.component.ts" region="template" title="src/app/hero-bio.component.ts (template)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bio.component.ts" region="template" header="src/app/hero-bio.component.ts (template)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -206,13 +206,13 @@ The result is shown below, with the hero's telephone number from `HeroContactCom
|
||||
|
||||
Here's `HeroContactComponent`, which demonstrates the qualifying decorators.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-contact.component.ts" region="component" title="src/app/hero-contact.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-contact.component.ts" region="component" header="src/app/hero-contact.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
Focus on the constructor parameters.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-contact.component.ts" region="ctor-params" title="src/app/hero-contact.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-contact.component.ts" region="ctor-params" header="src/app/hero-contact.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -256,7 +256,7 @@ the app throws an exception when it cannot find the required logger at the host
|
||||
|
||||
Using a custom provider allows you to provide a concrete implementation for implicit dependencies, such as built-in browser APIs. The following example uses an `InjectionToken` to provide the [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) browser API as a dependency in the `BrowserStorageService`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/storage.service.ts" title="src/app/storage.service.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/storage.service.ts" header="src/app/storage.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -266,7 +266,7 @@ The `factory` function returns the `localStorage` property that is attached to t
|
||||
|
||||
Providers can also be scoped by injector through constructor parameter decorators. The following example overrides the `BROWSER_STORAGE` token in the `Component` class `providers` with the `sessionStorage` browser API. The same `BrowserStorageService` is injected twice in the constructor, decorated with `@Self` and `@SkipSelf` to define which injector handles the provider dependency.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/storage.component.ts" title="src/app/storage.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/storage.component.ts" header="src/app/storage.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -283,7 +283,7 @@ As a result, you might need to access a component's DOM element.
|
||||
To illustrate, here's a simplified version of `HighlightDirective` from
|
||||
the [Attribute Directives](guide/attribute-directives) page.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/highlight.directive.ts" title="src/app/highlight.directive.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/highlight.directive.ts" header="src/app/highlight.directive.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -297,7 +297,7 @@ whose `nativeElement` property exposes the DOM element for the directive to mani
|
||||
The sample code applies the directive's `myHighlight` attribute to two `<div>` tags,
|
||||
first without a value (yielding the default color) and then with an assigned color value.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/app.component.html" region="highlight" title="src/app/app.component.html (highlight)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/app.component.html" region="highlight" header="src/app/app.component.html (highlight)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -323,7 +323,7 @@ Angular passes this token to the injector and assigns the result to the paramete
|
||||
The following is a typical example.
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="ctor" title="src/app/hero-bios.component.ts (component constructor injection)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-bios.component.ts" region="ctor" header="src/app/hero-bios.component.ts (component constructor injection)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -366,7 +366,7 @@ It's visually simple: a few properties and the logs produced by a logger.
|
||||
The code behind it customizes how and where the DI framework provides dependencies.
|
||||
The use cases illustrate different ways to use the [*provide* object literal](guide/dependency-injection-providers#provide) to associate a definition object with a DI token.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="hero-of-the-month" title="hero-of-the-month.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="hero-of-the-month" header="hero-of-the-month.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -384,7 +384,7 @@ You can also use a value provider in a unit test to provide mock data in place o
|
||||
|
||||
The `HeroOfTheMonthComponent` example has two value providers.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-value" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-value" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -405,7 +405,7 @@ The title string literal is immediately available.
|
||||
The `someHero` variable in this example was set earlier in the file as shown below.
|
||||
You can't use a variable whose value will be defined later.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="some-hero" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="some-hero" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -425,7 +425,7 @@ extend the default class, or emulate the behavior of the real class in a test ca
|
||||
|
||||
The following code shows two examples in `HeroOfTheMonthComponent`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-class" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-class" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -446,7 +446,7 @@ Components outside the tree continue to receive the original `LoggerService` ins
|
||||
|
||||
`DateLoggerService` inherits from `LoggerService`; it appends the current date/time to each message:
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/date-logger.service.ts" region="date-logger-service" title="src/app/date-logger.service.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/date-logger.service.ts" region="date-logger-service" header="src/app/date-logger.service.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -458,7 +458,7 @@ The `useExisting` provider key lets you map one token to another.
|
||||
In effect, the first token is an *alias* for the service associated with the second token,
|
||||
creating two ways to access the same service object.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-existing" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-existing" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -470,13 +470,13 @@ You might want to shrink that API surface to just the members you actually need.
|
||||
In this example, the `MinimalLogger` [class-interface](#class-interface) reduces the API to two members:
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/minimal-logger.service.ts" title="src/app/minimal-logger.service.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/minimal-logger.service.ts" header="src/app/minimal-logger.service.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
The following example puts `MinimalLogger` to use in a simplified version of `HeroOfTheMonthComponent`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.1.ts" title="src/app/hero-of-the-month.component.ts (minimal version)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.1.ts" header="src/app/hero-of-the-month.component.ts (minimal version)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -507,7 +507,7 @@ This is illustrated in the following image, which displays the logging date.
|
||||
The `useFactory` provider key lets you create a dependency object by calling a factory function,
|
||||
as in the following example.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-factory" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-factory" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -530,7 +530,7 @@ The `runnersUpFactory()` returns the *provider factory function*, which can use
|
||||
the passed-in state value and the injected services `Hero` and `HeroService`.
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/runners-up.ts" region="factory-synopsis" title="runners-up.ts (excerpt)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/runners-up.ts" region="factory-synopsis" header="runners-up.ts (excerpt)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -570,13 +570,13 @@ That's the subject of the next section.
|
||||
The previous *Hero of the Month* example used the `MinimalLogger` class
|
||||
as the token for a provider of `LoggerService`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-existing" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="use-existing" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
`MinimalLogger` is an abstract class.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/minimal-logger.service.ts" title="dependency-injection-in-action/src/app/minimal-logger.service.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/minimal-logger.service.ts" header="dependency-injection-in-action/src/app/minimal-logger.service.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -604,7 +604,7 @@ Using a class as an interface gives you the characteristics of an interface in a
|
||||
To minimize memory cost, however, the class should have *no implementation*.
|
||||
The `MinimalLogger` transpiles to this unoptimized, pre-minified JavaScript for a constructor function.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/minimal-logger.service.ts" region="minimal-logger-transpiled" title="dependency-injection-in-action/src/app/minimal-logger.service.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/minimal-logger.service.ts" region="minimal-logger-transpiled" header="dependency-injection-in-action/src/app/minimal-logger.service.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -633,13 +633,13 @@ another token that happens to have the same name.
|
||||
You encountered them twice in the *Hero of the Month* example,
|
||||
in the *title* value provider and in the *runnersUp* factory provider.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="provide-injection-token" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="provide-injection-token" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
You created the `TITLE` token like this:
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="injection-token" title="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" region="injection-token" header="dependency-injection-in-action/src/app/hero-of-the-month.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -667,7 +667,7 @@ The `HeroesBaseComponent` can stand on its own.
|
||||
It demands its own instance of `HeroService` to get heroes
|
||||
and displays them in the order they arrive from the database.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/sorted-heroes.component.ts" region="heroes-base" title="src/app/sorted-heroes.component.ts (HeroesBaseComponent)">
|
||||
<code-example path="dependency-injection-in-action/src/app/sorted-heroes.component.ts" region="heroes-base" header="src/app/sorted-heroes.component.ts (HeroesBaseComponent)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -693,7 +693,7 @@ You must provide the `HeroService` again for *this* component,
|
||||
then pass it down to the base class inside the constructor.
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/sorted-heroes.component.ts" region="sorted-heroes" title="src/app/sorted-heroes.component.ts (SortedHeroesComponent)">
|
||||
<code-example path="dependency-injection-in-action/src/app/sorted-heroes.component.ts" region="sorted-heroes" header="src/app/sorted-heroes.component.ts (SortedHeroesComponent)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -731,7 +731,7 @@ appear *above* the class definition.
|
||||
|
||||
Break the circularity with `forwardRef`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-providers" title="parent-finder.component.ts (AlexComponent providers)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-providers" header="parent-finder.component.ts (AlexComponent providers)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -40,7 +40,7 @@ In the following example, the parent `AlexComponent` has several children includ
|
||||
{@a alex}
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-1" title="parent-finder.component.ts (AlexComponent v.1)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-1" header="parent-finder.component.ts (AlexComponent v.1)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -49,7 +49,7 @@ In the following example, the parent `AlexComponent` has several children includ
|
||||
*Cathy* reports whether or not she has access to *Alex*
|
||||
after injecting an `AlexComponent` into her constructor:
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="cathy" title="parent-finder.component.ts (CathyComponent)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="cathy" header="parent-finder.component.ts (CathyComponent)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -98,7 +98,7 @@ inject its parent via the parent's base class*.
|
||||
The sample's `CraigComponent` explores this question. [Looking back](#alex),
|
||||
you see that the `Alex` component *extends* (*inherits*) from a class named `Base`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-class-signature" title="parent-finder.component.ts (Alex class signature)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-class-signature" header="parent-finder.component.ts (Alex class signature)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -106,7 +106,7 @@ you see that the `Alex` component *extends* (*inherits*) from a class named `Bas
|
||||
|
||||
The `CraigComponent` tries to inject `Base` into its `alex` constructor parameter and reports if it succeeded.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="craig" title="parent-finder.component.ts (CraigComponent)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="craig" header="parent-finder.component.ts (CraigComponent)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -138,7 +138,7 @@ and add that provider to the `providers` array of the `@Component()` metadata fo
|
||||
{@a alex-providers}
|
||||
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-providers" title="parent-finder.component.ts (AlexComponent providers)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-providers" header="parent-finder.component.ts (AlexComponent providers)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -149,7 +149,7 @@ The [*forwardRef*](guide/dependency-injection-in-action#forwardref) breaks the c
|
||||
*Carol*, the third of *Alex*'s child components, injects the parent into its `parent` parameter,
|
||||
the same way you've done it before.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="carol-class" title="parent-finder.component.ts (CarolComponent class)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="carol-class" header="parent-finder.component.ts (CarolComponent class)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -177,7 +177,7 @@ That means he must both *inject* the `Parent` class interface to get *Alice* and
|
||||
|
||||
Here's *Barry*.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="barry" title="parent-finder.component.ts (BarryComponent)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="barry" header="parent-finder.component.ts (BarryComponent)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -190,11 +190,11 @@ For now, focus on *Barry*'s constructor.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="Barry's constructor" path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="barry-ctor">
|
||||
<code-pane header="Barry's constructor" path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="barry-ctor">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="Carol's constructor" path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="carol-ctor">
|
||||
<code-pane header="Carol's constructor" path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="carol-ctor">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -229,7 +229,7 @@ You [learned earlier](guide/dependency-injection-in-action#class-interface) that
|
||||
|
||||
The example defines a `Parent` class interface.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="parent" title="parent-finder.component.ts (Parent class-interface)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="parent" header="parent-finder.component.ts (Parent class-interface)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -241,7 +241,7 @@ Such a narrow interface helps decouple the child component class from its parent
|
||||
|
||||
A component that could serve as a parent *should* implement the class interface as the `AliceComponent` does.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alice-class-signature" title="parent-finder.component.ts (AliceComponent class signature)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alice-class-signature" header="parent-finder.component.ts (AliceComponent class signature)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -251,7 +251,7 @@ Doing so adds clarity to the code. But it's not technically necessary.
|
||||
Although `AlexComponent` has a `name` property, as required by its `Base` class,
|
||||
its class signature doesn't mention `Parent`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-class-signature" title="parent-finder.component.ts (AlexComponent class signature)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-class-signature" header="parent-finder.component.ts (AlexComponent class signature)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -277,19 +277,19 @@ It doesn't in this example *only* to demonstrate that the code will compile and
|
||||
Writing variations of the same parent *alias provider* gets old quickly,
|
||||
especially this awful mouthful with a [*forwardRef*](guide/dependency-injection-in-action#forwardref).
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-providers" title="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alex-providers" header="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
You can extract that logic into a helper function like the following.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="provide-the-parent" title="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="provide-the-parent" header="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
Now you can add a simpler, more meaningful parent provider to your components.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alice-providers" title="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="alice-providers" header="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -299,14 +299,14 @@ The application might have a variety of parent types, each with its own class in
|
||||
|
||||
Here's a revised version that defaults to `parent` but also accepts an optional second parameter for a different parent class interface.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="provide-parent" title="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="provide-parent" header="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
||||
And here's how you could use it with a different parent type.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="beth-providers" title="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/parent-finder.component.ts" region="beth-providers" header="dependency-injection-in-action/src/app/parent-finder.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -130,7 +130,7 @@ like the title of the application or the address of a web API endpoint.
|
||||
These configuration objects aren't always instances of a class.
|
||||
They can be object literals, as shown in the following example.
|
||||
|
||||
<code-example path="dependency-injection/src/app/app.config.ts" region="config" title="src/app/app.config.ts (excerpt)" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/app.config.ts" region="config" header="src/app/app.config.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a interface-not-valid-token}
|
||||
@ -147,7 +147,7 @@ In TypeScript, an interface is a design-time artifact, and doesn't have a runtim
|
||||
<code-example path="dependency-injection/src/app/providers.component.ts" region="provider-9-ctor-interface" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
This might seem strange if you're used to dependency injection in strongly typed languages where an interface is the preferred dependency lookup key.
|
||||
However, JavaScript, doesn't have interfaces, so when TypeScript is transpiled to JavaScript, the interface disappears.
|
||||
@ -157,13 +157,13 @@ There is no interface type information left for Angular to find at runtime.
|
||||
|
||||
One alternative is to provide and inject the configuration object in an NgModule like `AppModule`.
|
||||
|
||||
<code-example path="dependency-injection/src/app/app.module.ts" region="providers" title="src/app/app.module.ts (providers)"></code-example>
|
||||
<code-example path="dependency-injection/src/app/app.module.ts" region="providers" header="src/app/app.module.ts (providers)"></code-example>
|
||||
|
||||
Another solution to choosing a provider token for non-class dependencies is
|
||||
to define and use an `InjectionToken` object.
|
||||
The following example shows how to define such a token.
|
||||
|
||||
<code-example path="dependency-injection/src/app/app.config.ts" region="token" title="src/app/app.config.ts" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/app.config.ts" region="token" header="src/app/app.config.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The type parameter, while optional, conveys the dependency's type to developers and tooling.
|
||||
@ -177,10 +177,10 @@ Register the dependency provider using the `InjectionToken` object:
|
||||
Now you can inject the configuration object into any constructor that needs it, with
|
||||
the help of an `@Inject()` parameter decorator.
|
||||
|
||||
<code-example path="dependency-injection/src/app/app.component.2.ts" region="ctor" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/app.component.2.ts" region="ctor" header="src/app/app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Although the `AppConfig` interface plays no role in dependency injection,
|
||||
it supports typing of the configuration object within the class.
|
||||
@ -215,21 +215,21 @@ who is authorized and who isn't.
|
||||
|
||||
To resolve this, we give the `HeroService` constructor a boolean flag to control display of secret heroes.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.ts" region="internals" title="src/app/heroes/hero.service.ts (excerpt)" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.ts" region="internals" header="src/app/heroes/hero.service.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You can inject `Logger`, but you can't inject the `isAuthorized` flag. Instead, you can use a factory provider to create a new logger instance for `HeroService`.
|
||||
|
||||
A factory provider needs a factory function.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.provider.ts" region="factory" title="src/app/heroes/hero.service.provider.ts (excerpt)" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.provider.ts" region="factory" header="src/app/heroes/hero.service.provider.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Although `HeroService` has no access to `UserService`, the factory function does.
|
||||
You inject both `Logger` and `UserService` into the factory provider
|
||||
and let the injector pass them along to the factory function.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.provider.ts" region="provider" title="src/app/heroes/hero.service.provider.ts (excerpt)" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.provider.ts" region="provider" header="src/app/heroes/hero.service.provider.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
* The `useFactory` field tells Angular that the provider is a factory function whose implementation is `heroServiceFactory`.
|
||||
@ -248,10 +248,10 @@ The following shows the new and the old implementations side-by-side.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="src/app/heroes/heroes.component (v3)" path="dependency-injection/src/app/heroes/heroes.component.ts">
|
||||
<code-pane header="src/app/heroes/heroes.component (v3)" path="dependency-injection/src/app/heroes/heroes.component.ts">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/heroes/heroes.component (v2)" path="dependency-injection/src/app/heroes/heroes.component.1.ts">
|
||||
<code-pane header="src/app/heroes/heroes.component (v2)" path="dependency-injection/src/app/heroes/heroes.component.1.ts">
|
||||
</code-pane>
|
||||
|
||||
</code-tabs>
|
||||
@ -293,7 +293,7 @@ When you provide multiple sets of routes using [RouterModule.forRoot](api/router
|
||||
and [RouterModule.forChild](api/router/RouterModule#forchild) in a single module,
|
||||
the [ROUTES](api/router/ROUTES) token combines all the different provided sets of routes into a single value.
|
||||
|
||||
<div class="alert-is-helpful>
|
||||
<div class="alert is-helpful>
|
||||
|
||||
Search for [Constants in API documentation](api?type=const) to find more built-in tokens.
|
||||
|
||||
@ -309,7 +309,7 @@ When providers are tree-shakable, the Angular compiler removes the associated
|
||||
services from the final output when it determines that they are not used in your application.
|
||||
This significantly reduces the size of your bundles.
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Ideally, if an application isn't injecting a service, it shouldn't be included in the final output.
|
||||
However, Angular has to be able to identify at build time whether the service will be required or not.
|
||||
@ -322,13 +322,13 @@ Thus, services provided at the NgModule or component level are not tree-shakable
|
||||
|
||||
The following example of non-tree-shakable providers in Angular configures a service provider for the injector of an NgModule.
|
||||
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service-and-module.ts" title="src/app/tree-shaking/service-and-modules.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service-and-module.ts" header="src/app/tree-shaking/service-and-modules.ts" linenums="false"> </code-example>
|
||||
|
||||
This module can then be imported into your application module
|
||||
to make the service available for injection in your app,
|
||||
as shown in the following example.
|
||||
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/app.module.ts" title="src/app/tree-shaking/app.modules.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/app.module.ts" header="src/app/tree-shaking/app.modules.ts" linenums="false"> </code-example>
|
||||
|
||||
When `ngc` runs, it compiles `AppModule` into a module factory, which contains definitions for all the providers declared in all the modules it includes. At runtime, this factory becomes an injector that instantiates these services.
|
||||
|
||||
@ -340,13 +340,13 @@ You can make a provider tree-shakable by specifying it in the `@Injectable()` de
|
||||
|
||||
The following example shows the tree-shakable equivalent to the `ServiceModule` example above.
|
||||
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service.ts" title="src/app/tree-shaking/service.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service.ts" header="src/app/tree-shaking/service.ts" linenums="false"> </code-example>
|
||||
|
||||
The service can be instantiated by configuring a factory function, as in the following example.
|
||||
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service.0.ts" title="src/app/tree-shaking/service.0.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service.0.ts" header="src/app/tree-shaking/service.0.ts" linenums="false"> </code-example>
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
To override a tree-shakable provider, configure the injector of a specific NgModule or component with another provider, using the `providers: []` array syntax of the `@NgModule()` or `@Component()` decorator.
|
||||
|
||||
|
@ -9,7 +9,7 @@ DI is a coding pattern in which a class asks for dependencies from external sour
|
||||
|
||||
In Angular, the DI framework provides declared dependencies to a class when that class is instantiated. This guide explains how DI works in Angular, and how you use it to make your apps flexible, efficient, and robust, as well as testable and maintainable.
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
You can run the <live-example></live-example> of the sample app that accompanies this guide.
|
||||
|
||||
@ -19,16 +19,16 @@ Start by reviewing this simplified version of the _heroes_ feature
|
||||
from the [The Tour of Heroes](tutorial/). This simple version doesn't use DI; we'll walk through converting it to do so.
|
||||
|
||||
<code-tabs>
|
||||
<code-pane title="src/app/heroes/heroes.component.ts" path="dependency-injection/src/app/heroes/heroes.component.1.ts" region="v1">
|
||||
<code-pane header="src/app/heroes/heroes.component.ts" path="dependency-injection/src/app/heroes/heroes.component.1.ts" region="v1">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/heroes/hero-list.component.ts" path="dependency-injection/src/app/heroes/hero-list.component.1.ts">
|
||||
<code-pane header="src/app/heroes/hero-list.component.ts" path="dependency-injection/src/app/heroes/hero-list.component.1.ts">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/heroes/hero.ts" path="dependency-injection/src/app/heroes/hero.ts">
|
||||
<code-pane header="src/app/heroes/hero.ts" path="dependency-injection/src/app/heroes/hero.ts">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/heroes/mock-heroes.ts" path="dependency-injection/src/app/heroes/mock-heroes.ts">
|
||||
<code-pane header="src/app/heroes/mock-heroes.ts" path="dependency-injection/src/app/heroes/mock-heroes.ts">
|
||||
</code-pane>
|
||||
|
||||
</code-tabs>
|
||||
@ -39,7 +39,7 @@ Its only purpose is to display `HeroListComponent`, which displays a list of her
|
||||
This version of the `HeroListComponent` gets heroes from the `HEROES` array, an in-memory collection
|
||||
defined in a separate `mock-heroes` file.
|
||||
|
||||
<code-example title="src/app/heroes/hero-list.component.ts (class)" path="dependency-injection/src/app/heroes/hero-list.component.1.ts" region="class">
|
||||
<code-example header="src/app/heroes/hero-list.component.ts (class)" path="dependency-injection/src/app/heroes/hero-list.component.1.ts" region="class">
|
||||
</code-example>
|
||||
|
||||
This approach works for prototyping, but is not robust or maintainable.
|
||||
@ -52,7 +52,7 @@ replace every use of the `HEROES` mock data.
|
||||
|
||||
The DI framework lets you supply data to a component from an injectable _service_ class, defined in its own file. To demonstrate, we'll create an injectable service class that provides a list of heroes, and register that class as a provider of that service.
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Having multiple classes in the same file can be confusing. We generally recommend that you define components and services in separate files.
|
||||
|
||||
@ -68,7 +68,7 @@ See an example in the [DI Cookbook](guide/dependency-injection-in-action#forward
|
||||
|
||||
### Create an injectable service class
|
||||
|
||||
The [**Angular CLI**](https://cli.angular.io/) can generate a new `HeroService` class in the `src/app/heroes` folder with this command.
|
||||
The [Angular CLI](cli) can generate a new `HeroService` class in the `src/app/heroes` folder with this command.
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng generate service heroes/hero
|
||||
@ -76,12 +76,12 @@ ng generate service heroes/hero
|
||||
|
||||
The command creates the following `HeroService` skeleton.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.0.ts" title="src/app/heroes/hero.service.ts (CLI-generated)">
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.0.ts" header="src/app/heroes/hero.service.ts (CLI-generated)">
|
||||
</code-example>
|
||||
|
||||
The `@Injectable()` is an essential ingredient in every Angular service definition. The rest of the class has been written to expose a `getHeroes` method that returns the same mock data as before. (A real app would probably get its data asynchronously from a remote server, but we'll ignore that to focus on the mechanics of injecting the service.)
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.3.ts" title="src/app/heroes/hero.service.ts">
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.3.ts" header="src/app/heroes/hero.service.ts">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -147,7 +147,7 @@ In order for `HeroListComponent` to get heroes from `HeroService`, it needs to a
|
||||
|
||||
You can tell Angular to inject a dependency in a component's constructor by specifying a **constructor parameter with the dependency type**. Here's the `HeroListComponent` constructor, asking for the `HeroService` to be injected.
|
||||
|
||||
<code-example title="src/app/heroes/hero-list.component (constructor signature)" path="dependency-injection/src/app/heroes/hero-list.component.ts"
|
||||
<code-example header="src/app/heroes/hero-list.component (constructor signature)" path="dependency-injection/src/app/heroes/hero-list.component.ts"
|
||||
region="ctor-signature">
|
||||
</code-example>
|
||||
|
||||
@ -155,10 +155,10 @@ Of course, `HeroListComponent` should do something with the injected `HeroServic
|
||||
Here's the revised component, making use of the injected service, side-by-side with the previous version for comparison.
|
||||
|
||||
<code-tabs>
|
||||
<code-pane title="hero-list.component (with DI)" path="dependency-injection/src/app/heroes/hero-list.component.2.ts">
|
||||
<code-pane header="hero-list.component (with DI)" path="dependency-injection/src/app/heroes/hero-list.component.2.ts">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="hero-list.component (without DI)" path="dependency-injection/src/app/heroes/hero-list.component.1.ts">
|
||||
<code-pane header="hero-list.component (without DI)" path="dependency-injection/src/app/heroes/hero-list.component.1.ts">
|
||||
</code-pane>
|
||||
</code-tabs>
|
||||
|
||||
@ -197,7 +197,7 @@ Listing dependencies as constructor parameters may be all you need to test appli
|
||||
For example, you can create a new `HeroListComponent` with a mock service that you can manipulate
|
||||
under test.
|
||||
|
||||
<code-example path="dependency-injection/src/app/test.component.ts" region="spec" title="src/app/test.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/test.component.ts" region="spec" header="src/app/test.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -217,13 +217,13 @@ Here is the revised `HeroService` that injects `Logger`, side by side with the p
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="src/app/heroes/hero.service (v2)" path="dependency-injection/src/app/heroes/hero.service.2.ts">
|
||||
<code-pane header="src/app/heroes/hero.service (v2)" path="dependency-injection/src/app/heroes/hero.service.2.ts">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/heroes/hero.service (v1)" path="dependency-injection/src/app/heroes/hero.service.1.ts">
|
||||
<code-pane header="src/app/heroes/hero.service (v1)" path="dependency-injection/src/app/heroes/hero.service.1.ts">
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/logger.service"
|
||||
<code-pane header="src/app/logger.service"
|
||||
path="dependency-injection/src/app/logger.service.ts">
|
||||
</code-pane>
|
||||
|
||||
@ -238,7 +238,7 @@ If Angular can't find that parameter information, it throws an error.
|
||||
Angular can only find the parameter information _if the class has a decorator of some kind_.
|
||||
The `@Injectable()` decorator is the standard decorator for service classes.
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
The decorator requirement is imposed by TypeScript. TypeScript normally discards parameter type information when it [transpiles](guide/glossary#transpile) the code to JavaScript. TypeScript preserves this information if the class has a decorator and the `emitDecoratorMetadata` compiler option is set `true` in TypeScript's `tsconfig.json` configuration file. The CLI configures `tsconfig.json` with `emitDecoratorMetadata: true`.
|
||||
|
||||
@ -260,14 +260,14 @@ In simple examples, the dependency value is an *instance*, and
|
||||
the class *type* serves as its own lookup key.
|
||||
Here you get a `HeroService` directly from the injector by supplying the `HeroService` type as the token:
|
||||
|
||||
<code-example path="dependency-injection/src/app/injector.component.ts" region="get-hero-service" title="src/app/injector.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/injector.component.ts" region="get-hero-service" header="src/app/injector.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The behavior is similar when you write a constructor that requires an injected class-based dependency.
|
||||
When you define a constructor parameter with the `HeroService` class type,
|
||||
Angular knows to inject the service associated with that `HeroService` class token:
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero-list.component.ts" region="ctor-signature" title="src/app/heroes/hero-list.component.ts">
|
||||
<code-example path="dependency-injection/src/app/heroes/hero-list.component.ts" region="ctor-signature" header="src/app/heroes/hero-list.component.ts">
|
||||
</code-example>
|
||||
|
||||
Many dependency values are provided by classes, but not all. The expanded *provide* object lets you associate different kinds of providers with a DI token.
|
||||
@ -295,7 +295,7 @@ When using `@Optional()`, your code must be prepared for a null value. If you
|
||||
don't register a logger provider anywhere, the injector sets the
|
||||
value of `logger` to null.
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
`@Inject()` and `@Optional()` are _parameter decorators_. They alter the way the DI framework provides a dependency, by annotating the dependency parameter on the constructor of the class that requires the dependency.
|
||||
|
||||
|
@ -34,7 +34,7 @@ Another simple way to deploy your Angular app is to use [GitHub Pages](https://h
|
||||
1. You need to [create a GitHub account](https://github.com/join) if you don't have one, and then [create a repository](https://help.github.com/articles/create-a-repo/) for your project.
|
||||
Make a note of the user name and project name in GitHub.
|
||||
|
||||
1. Build your project using Github project name, with the following CLI command:
|
||||
1. Build your project using Github project name, with the Angular CLI command [`ng build`](cli/build) and the options shown here:
|
||||
<code-example language="none" class="code-shell">
|
||||
ng build --prod --output-path docs --base-href <project_name>
|
||||
</code-example>
|
||||
@ -47,7 +47,7 @@ Make a note of the user name and project name in GitHub.
|
||||
|
||||
You can see your deployed page at `https://<user_name>.github.io/<project_name>/`.
|
||||
|
||||
<div class="alert-is-helpful>
|
||||
<div class="alert is-helpful>
|
||||
|
||||
Check out [angular-cli-ghpages](https://github.com/angular-buch/angular-cli-ghpages), a full featured package that does all this for you and has extra functionality.
|
||||
|
||||
@ -99,7 +99,7 @@ The list is by no means exhaustive, but should provide you with a good starting
|
||||
|
||||
#### Development servers
|
||||
|
||||
During development, the `ng serve` command lets you run your app in a local browser.
|
||||
During development, the [`ng serve`](cli/serve) CLI command lets you run your app in a local browser.
|
||||
The CLI recompiles the application each time you save a file,
|
||||
and reloads the browser with the newly compiled application.
|
||||
|
||||
@ -253,8 +253,7 @@ The `--prod` _meta-flag_ engages the following optimization features.
|
||||
|
||||
The remaining [copy deployment steps](#copy-files) are the same as before.
|
||||
|
||||
See [Building and serving Angular apps](guide/build)
|
||||
for more about CLI build options and what they do.
|
||||
See [`ng build`](cli/build) for more about CLI build options and what they do.
|
||||
|
||||
{@a enable-prod-mode}
|
||||
|
||||
@ -284,7 +283,7 @@ Configure the Angular Router to defer loading of all other modules (and their as
|
||||
or by [_lazy loading_](guide/router#asynchronous-routing "Lazy loading")
|
||||
them on demand.
|
||||
|
||||
<div class="alert-is-helpful>
|
||||
<div class="alert is-helpful>
|
||||
|
||||
#### Don't eagerly import something from a lazy-loaded module
|
||||
|
||||
@ -410,4 +409,4 @@ ng build --watch
|
||||
```
|
||||
Like the `ng serve` command, this regenerates output files when source files change.
|
||||
|
||||
For complete details of the CLI commands and configuration options, see the [CLI command reference](cli).
|
||||
For complete details of the CLI commands, see the [CLI command reference](cli).
|
||||
|
@ -42,7 +42,7 @@ changing the template and the body of the component.
|
||||
When you're done, it should look like this:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.1.ts" title="src/app/app.component.ts">
|
||||
<code-example path="displaying-data/src/app/app.component.1.ts" header="src/app/app.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -54,7 +54,7 @@ The template displays the two component properties using double curly brace
|
||||
interpolation:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.1.ts" linenums="false" title="src/app/app.component.ts (template)" region="template">
|
||||
<code-example path="displaying-data/src/app/app.component.1.ts" linenums="false" header="src/app/app.component.ts (template)" region="template">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -98,7 +98,7 @@ The CSS `selector` in the `@Component` decorator specifies an element named `<ap
|
||||
That element is a placeholder in the body of your `index.html` file:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/index.html" linenums="false" title="src/index.html (body)" region="body">
|
||||
<code-example path="displaying-data/src/index.html" linenums="false" header="src/index.html (body)" region="body">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -135,7 +135,7 @@ In either style, the template data bindings have the same access to the componen
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
By default, the Angular CLI generates components with a template file. You can override that with:
|
||||
By default, the Angular CLI command [`ng generate component`](cli/generate) generates components with a template file. You can override that with:
|
||||
|
||||
<code-example hideCopy language="sh" class="code-shell">
|
||||
ng generate component hero -it
|
||||
@ -164,7 +164,7 @@ This app uses more terse "variable assignment" style simply for brevity.
|
||||
To display a list of heroes, begin by adding an array of hero names to the component and redefine `myHero` to be the first name in the array.
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.2.ts" linenums="false" title="src/app/app.component.ts (class)" region="class">
|
||||
<code-example path="displaying-data/src/app/app.component.2.ts" linenums="false" header="src/app/app.component.ts (class)" region="class">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -174,7 +174,7 @@ Now use the Angular `ngFor` directive in the template to display
|
||||
each item in the `heroes` list.
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.2.ts" linenums="false" title="src/app/app.component.ts (template)" region="template">
|
||||
<code-example path="displaying-data/src/app/app.component.2.ts" linenums="false" header="src/app/app.component.ts (template)" region="template">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -185,7 +185,7 @@ in the `<li>` element is the Angular "repeater" directive.
|
||||
It marks that `<li>` element (and its children) as the "repeater template":
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.2.ts" linenums="false" title="src/app/app.component.ts (li)" region="li">
|
||||
<code-example path="displaying-data/src/app/app.component.2.ts" linenums="false" header="src/app/app.component.ts (li)" region="li">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -252,7 +252,7 @@ of hero names into an array of `Hero` objects. For that you'll need a `Hero` cla
|
||||
With the following code:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/hero.ts" linenums="false" title="src/app/hero.ts">
|
||||
<code-example path="displaying-data/src/app/hero.ts" linenums="false" header="src/app/hero.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -266,7 +266,7 @@ The declaration of the constructor parameters takes advantage of a TypeScript sh
|
||||
Consider the first parameter:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/hero.ts" linenums="false" title="src/app/hero.ts (id)" region="id">
|
||||
<code-example path="displaying-data/src/app/hero.ts" linenums="false" header="src/app/hero.ts (id)" region="id">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -286,7 +286,7 @@ After importing the `Hero` class, the `AppComponent.heroes` property can return
|
||||
of `Hero` objects:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.3.ts" linenums="false" title="src/app/app.component.ts (heroes)" region="heroes">
|
||||
<code-example path="displaying-data/src/app/app.component.3.ts" linenums="false" header="src/app/app.component.ts (heroes)" region="heroes">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -297,7 +297,7 @@ At the moment it displays the hero's `id` and `name`.
|
||||
Fix that to display only the hero's `name` property.
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.3.ts" linenums="false" title="src/app/app.component.ts (template)" region="template">
|
||||
<code-example path="displaying-data/src/app/app.component.3.ts" linenums="false" header="src/app/app.component.ts (template)" region="template">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -317,7 +317,7 @@ The Angular `ngIf` directive inserts or removes an element based on a _truthy/fa
|
||||
To see it in action, add the following paragraph at the bottom of the template:
|
||||
|
||||
|
||||
<code-example path="displaying-data/src/app/app.component.ts" linenums="false" title="src/app/app.component.ts (message)" region="message">
|
||||
<code-example path="displaying-data/src/app/app.component.ts" linenums="false" header="src/app/app.component.ts (message)" region="message">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -357,7 +357,7 @@ big chunks of HTML with many data bindings.
|
||||
|
||||
|
||||
Try it out. Because the array has four items, the message should appear.
|
||||
Go back into <code>app.component.ts"</code> and delete or comment out one of the elements from the hero array.
|
||||
Go back into <code>app.component.ts</code> and delete or comment out one of the elements from the hero array.
|
||||
The browser should refresh automatically and the message should disappear.
|
||||
|
||||
|
||||
@ -375,19 +375,19 @@ Here's the final code:
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="src/app/app.component.ts" path="displaying-data/src/app/app.component.ts" region="final">
|
||||
<code-pane header="src/app/app.component.ts" path="displaying-data/src/app/app.component.ts" region="final">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/hero.ts" path="displaying-data/src/app/hero.ts">
|
||||
<code-pane header="src/app/hero.ts" path="displaying-data/src/app/hero.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/app.module.ts" path="displaying-data/src/app/app.module.ts">
|
||||
<code-pane header="src/app/app.module.ts" path="displaying-data/src/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="main.ts" path="displaying-data/src/main.ts">
|
||||
<code-pane header="main.ts" path="displaying-data/src/main.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
|
@ -310,22 +310,22 @@ _This_ "Authors Doc Style Guide" has its own sample application, located in the
|
||||
|
||||
The following _code-example_ displays the sample's `app.module.ts`.
|
||||
|
||||
<code-example path="docs-style-guide/src/app/app.module.ts" title="src/app/app.module.ts"></code-example>
|
||||
<code-example path="docs-style-guide/src/app/app.module.ts" header="src/app/app.module.ts"></code-example>
|
||||
|
||||
Here's the brief markup that produced that lengthy snippet:
|
||||
|
||||
```html
|
||||
<code-example
|
||||
path="docs-style-guide/src/app/app.module.ts"
|
||||
title="src/app/app.module.ts">
|
||||
header="src/app/app.module.ts">
|
||||
</code-example>
|
||||
```
|
||||
|
||||
You identified the snippet's source file by setting the `path` attribute to sample folder's location _within_ `content/examples`.
|
||||
In this example, that path is `docs-style-guide/src/app/app.module.ts`.
|
||||
|
||||
You added a header to tell the reader where to find the file by setting the `title` attribute.
|
||||
Following convention, you set the `title` attribute to the file's location within the sample's root folder.
|
||||
You added a header to tell the reader where to find the file by setting the `header` attribute.
|
||||
Following convention, you set the `header` attribute to the file's location within the sample's root folder.
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
@ -343,7 +343,7 @@ If you want to include an ignored code file in your project and display it in a
|
||||
|
||||
The preferred way to un-ignore a file is to update the `content/examples/.gitignore` like this:
|
||||
|
||||
<code-example title="content/examples/.gitignore">
|
||||
<code-example header="content/examples/.gitignore">
|
||||
# my-guide
|
||||
!my-guide/src/something.js
|
||||
!my-guide/more-javascript*.js
|
||||
@ -357,7 +357,7 @@ You control the _code-example_ output by setting one or more of its attributes:
|
||||
|
||||
* `path`- the path to the file in the `content/examples` folder.
|
||||
|
||||
* `title`- the header of the code listing.
|
||||
* `header`- the header of the code listing.
|
||||
|
||||
* `region`- displays the source file fragment with that region name; regions are identified by _docregion_ markup in the source file, as explained [below](#region "Displaying a code fragment").
|
||||
|
||||
@ -395,7 +395,7 @@ A couple of observations:
|
||||
|
||||
1. The `region` value, `"class"`, is the name of the `#docregion` in the source file. Confirm that by looking at `content/examples/docs-style-guide/src/app/app.module.ts`
|
||||
|
||||
1. Omitting the `title` is fine when the source of the fragment is obvious. We just said that this is a fragment of the `app.module.ts` file which was displayed immediately above, in full, with a header.
|
||||
1. Omitting the `header` is fine when the source of the fragment is obvious. We just said that this is a fragment of the `app.module.ts` file which was displayed immediately above, in full, with a header.
|
||||
There's no need to repeat the header.
|
||||
|
||||
1. The line numbers disappeared. By default, the doc viewer omits line numbers when there are fewer than 10 lines of code; it adds line numbers after that. You can turn line numbers on or off explicitly by setting the `linenums` attribute.
|
||||
@ -415,11 +415,11 @@ Here's the markup for an "avoid" example in the
|
||||
<code-example
|
||||
path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.ts"
|
||||
region="example"
|
||||
title="app/heroes/hero-button/hero-button.component.ts">
|
||||
header="app/heroes/hero-button/hero-button.component.ts">
|
||||
</code-example>
|
||||
```
|
||||
|
||||
<code-example path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" title="app/heroes/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" header="app/heroes/hero-button/hero-button.component.ts">
|
||||
</code-example>
|
||||
|
||||
{@a code-tabs}
|
||||
@ -434,29 +434,29 @@ Code tabs display code much like _code examples_ do. The added advantage is tha
|
||||
#### Code-pane attributes
|
||||
|
||||
* `path` - a file in the content/examples folder
|
||||
* `title` - seen in the header of a tab
|
||||
* `header` - seen in the header of a tab
|
||||
* `linenums` - overrides the `linenums` property at the `code-tabs` level for this particular pane. The value can be `true`, `false` or a number indicating the starting line number. If not specified, line numbers are enabled only when the number of lines of code are greater than 10.
|
||||
|
||||
The next example displays multiple code tabs, each with its own title.
|
||||
The next example displays multiple code tabs, each with its own header.
|
||||
It demonstrates control over display of line numbers at both the `<code-tabs>` and `<code-pane>` levels.
|
||||
|
||||
<code-tabs linenums="false">
|
||||
<code-pane
|
||||
title="app.component.html"
|
||||
header="app.component.html"
|
||||
path="docs-style-guide/src/app/app.component.html">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="app.component.ts"
|
||||
header="app.component.ts"
|
||||
path="docs-style-guide/src/app/app.component.ts"
|
||||
linenums="true">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="app.component.css (heroes)"
|
||||
header="app.component.css (heroes)"
|
||||
path="docs-style-guide/src/app/app.component.css"
|
||||
region="heroes">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="package.json (scripts)"
|
||||
header="package.json (scripts)"
|
||||
path="docs-style-guide/package.1.json">
|
||||
</code-pane>
|
||||
</code-tabs>
|
||||
@ -469,21 +469,21 @@ The `linenums` attribute in the second pane restores line numbering for _itself
|
||||
```html
|
||||
<code-tabs linenums="false">
|
||||
<code-pane
|
||||
title="app.component.html"
|
||||
header="app.component.html"
|
||||
path="docs-style-guide/src/app/app.component.html">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="app.component.ts"
|
||||
header="app.component.ts"
|
||||
path="docs-style-guide/src/app/app.component.ts"
|
||||
linenums="true">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="app.component.css (heroes)"
|
||||
header="app.component.css (heroes)"
|
||||
path="docs-style-guide/src/app/app.component.css"
|
||||
region="heroes">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="package.json (scripts)"
|
||||
header="package.json (scripts)"
|
||||
path="docs-style-guide/package.1.json">
|
||||
</code-pane>
|
||||
</code-tabs>
|
||||
@ -548,7 +548,7 @@ The `src/main.ts` is a simple example of a file with a single _#docregion_ at th
|
||||
|
||||
<code-example
|
||||
path="docs-style-guide/src/main.ts"
|
||||
title="src/main.ts"></code-example>
|
||||
header="src/main.ts"></code-example>
|
||||
|
||||
</div>
|
||||
|
||||
@ -622,12 +622,12 @@ Here's are the two corresponding code snippets displayed side-by-side.
|
||||
|
||||
<code-tabs>
|
||||
<code-pane
|
||||
title="app.component.ts (class)"
|
||||
header="app.component.ts (class)"
|
||||
path="docs-style-guide/src/app/app.component.ts"
|
||||
region="class">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="app.component.ts (class-skeleton)"
|
||||
header="app.component.ts (class-skeleton)"
|
||||
path="docs-style-guide/src/app/app.component.ts"
|
||||
region="class-skeleton">
|
||||
</code-pane>
|
||||
@ -660,12 +660,12 @@ Here's an example that excerpts certain scripts from `package.json` into a parti
|
||||
|
||||
<code-example
|
||||
path="docs-style-guide/package.1.json"
|
||||
title="package.json (selected scripts)"></code-example>
|
||||
header="package.json (selected scripts)"></code-example>
|
||||
|
||||
```html
|
||||
<code-example
|
||||
path="docs-style-guide/package.1.json"
|
||||
title="package.json (selected scripts)"></code-example>
|
||||
header="package.json (selected scripts)"></code-example>
|
||||
```
|
||||
|
||||
#### Partial file naming
|
||||
@ -689,7 +689,7 @@ Remember to exclude these files from stackblitz by listing them in the `stackbli
|
||||
|
||||
<code-example
|
||||
path="docs-style-guide/stackblitz.json"
|
||||
title="stackblitz.json"></code-example>
|
||||
header="stackblitz.json"></code-example>
|
||||
|
||||
{@a live-examples}
|
||||
## Live examples
|
||||
|
@ -35,7 +35,7 @@ The ad banner uses a helper directive called `AdDirective` to
|
||||
mark valid insertion points in the template.
|
||||
|
||||
|
||||
<code-example path="dynamic-component-loader/src/app/ad.directive.ts" title="src/app/ad.directive.ts" linenums="false">
|
||||
<code-example path="dynamic-component-loader/src/app/ad.directive.ts" header="src/app/ad.directive.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -62,7 +62,7 @@ To apply the `AdDirective`, recall the selector from `ad.directive.ts`,
|
||||
where to dynamically load components.
|
||||
|
||||
|
||||
<code-example path="dynamic-component-loader/src/app/ad-banner.component.ts" region="ad-host" title="src/app/ad-banner.component.ts (template)" linenums="false">
|
||||
<code-example path="dynamic-component-loader/src/app/ad-banner.component.ts" region="ad-host" header="src/app/ad-banner.component.ts (template)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -91,7 +91,7 @@ With its `getAds()` method, `AdBannerComponent` cycles through the array of `AdI
|
||||
and loads a new component every 3 seconds by calling `loadComponent()`.
|
||||
|
||||
|
||||
<code-example path="dynamic-component-loader/src/app/ad-banner.component.ts" region="class" title="src/app/ad-banner.component.ts (excerpt)" linenums="false">
|
||||
<code-example path="dynamic-component-loader/src/app/ad-banner.component.ts" region="class" header="src/app/ad-banner.component.ts (excerpt)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -150,7 +150,7 @@ dynamically loaded components since they load at runtime.
|
||||
To ensure that the compiler still generates a factory,
|
||||
add dynamically loaded components to the `NgModule`'s `entryComponents` array:
|
||||
|
||||
<code-example path="dynamic-component-loader/src/app/app.module.ts" region="entry-components" title="src/app/app.module.ts (entry components)" linenums="false">
|
||||
<code-example path="dynamic-component-loader/src/app/app.module.ts" region="entry-components" header="src/app/app.module.ts (entry components)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -169,15 +169,15 @@ Here are two sample components and the `AdComponent` interface for reference:
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="hero-job-ad.component.ts" path="dynamic-component-loader/src/app/hero-job-ad.component.ts">
|
||||
<code-pane header="hero-job-ad.component.ts" path="dynamic-component-loader/src/app/hero-job-ad.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="hero-profile.component.ts" path="dynamic-component-loader/src/app/hero-profile.component.ts">
|
||||
<code-pane header="hero-profile.component.ts" path="dynamic-component-loader/src/app/hero-profile.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="ad.component.ts" path="dynamic-component-loader/src/app/ad.component.ts">
|
||||
<code-pane header="ad.component.ts" path="dynamic-component-loader/src/app/ad.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
|
@ -40,11 +40,11 @@ Bootstrap the `AppModule` in `main.ts`.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app.module.ts" path="dynamic-form/src/app/app.module.ts">
|
||||
<code-pane header="app.module.ts" path="dynamic-form/src/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="main.ts" path="dynamic-form/src/main.ts">
|
||||
<code-pane header="main.ts" path="dynamic-form/src/main.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -62,7 +62,7 @@ The _question_ is the most fundamental object in the model.
|
||||
The following `QuestionBase` is a fundamental question class.
|
||||
|
||||
|
||||
<code-example path="dynamic-form/src/app/question-base.ts" title="src/app/question-base.ts">
|
||||
<code-example path="dynamic-form/src/app/question-base.ts" header="src/app/question-base.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -77,7 +77,7 @@ appropriate controls dynamically.
|
||||
via the `type` property.
|
||||
|
||||
|
||||
<code-example path="dynamic-form/src/app/question-textbox.ts" title="src/app/question-textbox.ts" linenums="false">
|
||||
<code-example path="dynamic-form/src/app/question-textbox.ts" header="src/app/question-textbox.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -86,7 +86,7 @@ via the `type` property.
|
||||
`DropdownQuestion` presents a list of choices in a select box.
|
||||
|
||||
|
||||
<code-example path="dynamic-form/src/app/question-dropdown.ts" title="src/app/question-dropdown.ts" linenums="false">
|
||||
<code-example path="dynamic-form/src/app/question-dropdown.ts" header="src/app/question-dropdown.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -97,7 +97,7 @@ In a nutshell, the form group consumes the metadata from the question model and
|
||||
allows you to specify default values and validation rules.
|
||||
|
||||
|
||||
<code-example path="dynamic-form/src/app/question-control.service.ts" title="src/app/question-control.service.ts" linenums="false">
|
||||
<code-example path="dynamic-form/src/app/question-control.service.ts" header="src/app/question-control.service.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -112,11 +112,11 @@ to create components to represent the dynamic form.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="dynamic-form.component.html" path="dynamic-form/src/app/dynamic-form.component.html">
|
||||
<code-pane header="dynamic-form.component.html" path="dynamic-form/src/app/dynamic-form.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="dynamic-form.component.ts" path="dynamic-form/src/app/dynamic-form.component.ts">
|
||||
<code-pane header="dynamic-form.component.ts" path="dynamic-form/src/app/dynamic-form.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -132,11 +132,11 @@ question based on values in the data-bound question object.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="dynamic-form-question.component.html" path="dynamic-form/src/app/dynamic-form-question.component.html">
|
||||
<code-pane header="dynamic-form-question.component.html" path="dynamic-form/src/app/dynamic-form-question.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="dynamic-form-question.component.ts" path="dynamic-form/src/app/dynamic-form-question.component.ts">
|
||||
<code-pane header="dynamic-form-question.component.ts" path="dynamic-form/src/app/dynamic-form-question.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -169,7 +169,7 @@ directly since you imported `ReactiveFormsModule` from `AppModule`.
|
||||
and removing objects from the `questions` array.
|
||||
|
||||
|
||||
<code-example path="dynamic-form/src/app/question.service.ts" title="src/app/question.service.ts">
|
||||
<code-example path="dynamic-form/src/app/question.service.ts" header="src/app/question.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -178,7 +178,7 @@ directly since you imported `ReactiveFormsModule` from `AppModule`.
|
||||
Finally, display an instance of the form in the `AppComponent` shell.
|
||||
|
||||
|
||||
<code-example path="dynamic-form/src/app/app.component.ts" title="app.component.ts">
|
||||
<code-example path="dynamic-form/src/app/app.component.ts" header="app.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -119,7 +119,7 @@ The recently-developed [custom elements](https://developer.mozilla.org/en-US/doc
|
||||
|
||||
In browsers that support Custom Elements natively, the specification requires developers use ES2015 classes to define Custom Elements - developers can opt-in to this by setting the `target: "es2015"` property in their project's `tsconfig.json`. As Custom Element and ES2015 support may not be available in all browsers, developers can instead choose to use a polyfill to support older browsers and ES5 code.
|
||||
|
||||
Use the [Angular CLI](https://cli.angular.io/) to automatically set up your project with the correct polyfill: `ng add @angular/elements --name=*your_project_name*`.
|
||||
Use the [Angular CLI](cli) to automatically set up your project with the correct polyfill: `ng add @angular/elements --name=*your_project_name*`.
|
||||
- For more information about polyfills, see [polyfill documentation](https://www.webcomponents.org/polyfills).
|
||||
|
||||
- For more information about Angular browser support, see [Browser Support](guide/browser-support).
|
||||
@ -142,19 +142,19 @@ For comparison, the demo shows both methods. One button adds the popup using the
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="popup.component.ts" path="elements/src/app/popup.component.ts">
|
||||
<code-pane header="popup.component.ts" path="elements/src/app/popup.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="popup.service.ts" path="elements/src/app/popup.service.ts">
|
||||
<code-pane header="popup.service.ts" path="elements/src/app/popup.service.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.module.ts" path="elements/src/app/app.module.ts">
|
||||
<code-pane header="app.module.ts" path="elements/src/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.component.ts" path="elements/src/app/app.component.ts">
|
||||
<code-pane header="app.component.ts" path="elements/src/app/app.component.ts">
|
||||
|
||||
</code-pane>
|
||||
</code-tabs>
|
||||
|
@ -33,7 +33,7 @@ pipes that it shares.
|
||||
|
||||
## How to make a feature module
|
||||
|
||||
Assuming you already have a CLI generated app, create a feature
|
||||
Assuming you already have an app that you created with the [Angular CLI](cli), create a feature
|
||||
module using the CLI by entering the following command in the
|
||||
root project directory. Replace `CustomerDashboard` with the
|
||||
name of your module. You can omit the "Module" suffix from the name because the CLI appends it:
|
||||
@ -72,7 +72,7 @@ ng generate component customer-dashboard/CustomerDashboard
|
||||
This generates a folder for the new component within the customer-dashboard folder and updates the feature module with the `CustomerDashboardComponent` info:
|
||||
|
||||
|
||||
<code-example path="feature-modules/src/app/customer-dashboard/customer-dashboard.module.ts" region="customer-dashboard-component" title="src/app/customer-dashboard/customer-dashboard.module.ts" linenums="false">
|
||||
<code-example path="feature-modules/src/app/customer-dashboard/customer-dashboard.module.ts" region="customer-dashboard-component" header="src/app/customer-dashboard/customer-dashboard.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -83,7 +83,7 @@ The `CustomerDashboardComponent` is now in the JavaScript import list at the top
|
||||
|
||||
To incorporate the feature module into your app, you have to let the root module, `app.module.ts`, know about it. Notice the `CustomerDashboardModule` export at the bottom of `customer-dashboard.module.ts`. This exposes it so that other modules can get to it. To import it into the `AppModule`, add it to the imports in `app.module.ts` and to the `imports` array:
|
||||
|
||||
<code-example path="feature-modules/src/app/app.module.ts" region="app-module" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="feature-modules/src/app/app.module.ts" region="app-module" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -94,20 +94,20 @@ Now the `AppModule` knows about the feature module. If you were to add any servi
|
||||
|
||||
When the CLI generated the `CustomerDashboardComponent` for the feature module, it included a template, `customer-dashboard.component.html`, with the following markup:
|
||||
|
||||
<code-example path="feature-modules/src/app/customer-dashboard/customer-dashboard/customer-dashboard.component.html" region="feature-template" title="src/app/customer-dashboard/customer-dashboard/customer-dashboard.component.html" linenums="false">
|
||||
<code-example path="feature-modules/src/app/customer-dashboard/customer-dashboard/customer-dashboard.component.html" region="feature-template" header="src/app/customer-dashboard/customer-dashboard/customer-dashboard.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
To see this HTML in the `AppComponent`, you first have to export the `CustomerDashboardComponent` in the `CustomerDashboardModule`. In `customer-dashboard.module.ts`, just beneath the `declarations` array, add an `exports` array containing `CustomerDashboardModule`:
|
||||
|
||||
<code-example path="feature-modules/src/app/customer-dashboard/customer-dashboard.module.ts" region="component-exports" title="src/app/customer-dashboard/customer-dashboard.module.ts" linenums="false">
|
||||
<code-example path="feature-modules/src/app/customer-dashboard/customer-dashboard.module.ts" region="component-exports" header="src/app/customer-dashboard/customer-dashboard.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
|
||||
Next, in the `AppComponent`, `app.component.html`, add the tag `<app-customer-dashboard>`:
|
||||
|
||||
<code-example path="feature-modules/src/app/app.component.html" region="app-component-template" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="feature-modules/src/app/app.component.html" region="app-component-template" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
|
@ -1,67 +1,110 @@
|
||||
# Workspace and project file structure
|
||||
|
||||
An Angular CLI project is the foundation for both quick experiments and enterprise solutions. The CLI command `ng new` creates an Angular workspace in your file system that is the root for new projects, which can be apps and libraries.
|
||||
You develop apps in the context of an Angular [workspace](guide/glossary#workspace). A workspace contains the files for one or more [projects](guide/glossary#project). A project is the set of files that comprise a standalone app, a library, or a set of end-to-end (e2e) tests.
|
||||
|
||||
## Workspaces and project files
|
||||
The Angular CLI command `ng new <project_name>` gets you started.
|
||||
When you run this command, the CLI installs the necessary Angular npm packages and other dependencies in a new workspace, with a root folder named *project_name*.
|
||||
It also creates the following workspace and starter project files:
|
||||
|
||||
Angular 6 introduced the [workspace](guide/glossary#workspace) directory structure for Angular [projects](guide/glossary#project). A project can be a standalone *application* or a *library*, and a workspace can contain multiple applications, as well as libraries that can be used in any of the apps.
|
||||
* An initial skeleton app project, also called *project_name* (in the `src/` subfolder).
|
||||
* An end-to-end test project (in the `e2e/` subfolder).
|
||||
* Related configuration files.
|
||||
|
||||
The CLI command `ng new my-workspace` creates a workspace folder and generates a new app skeleton in an `app` folder within that workspace.
|
||||
Within the `app/` folder, a `src/` subfolder contains the logic, data, and assets.
|
||||
A newly generated `app/` folder contains the source files for a root module, with a root component and template.
|
||||
The initial app project contains a simple Welcome app, ready to run.
|
||||
|
||||
The `app/` folder also contains project-specific configuration files, end-to-end tests, and the Angular system modules.
|
||||
## Workspace files
|
||||
|
||||
```
|
||||
my-workspace/
|
||||
app/
|
||||
e2e/
|
||||
src/
|
||||
node_modules/
|
||||
src/
|
||||
```
|
||||
The top level of the workspace contains a number of workspace-wide configuration files.
|
||||
|
||||
When this workspace file structure is in place, you can use the `ng generate` command on the command line to add functionality and data to the initial app.
|
||||
| WORKSPACE CONFIG FILES | PURPOSE |
|
||||
| :--------------------- | :------------------------------------------|
|
||||
| `.editorconfig` | Configuration for code editors. See [EditorConfig](https://editorconfig.org/). |
|
||||
| `.gitignore` | Specifies intentionally untracked files that [Git](https://git-scm.com/) should ignore. |
|
||||
| `angular.json` | CLI configuration for all projects in the workspace, including configuration options for build, serve, and test tools that the CLI uses, such as [Karma](https://karma-runner.github.io/) and [Protractor](http://www.protractortest.org/). |
|
||||
| `node_modules` | Provides [npm packages](guide/npm-packages) to the entire workspace. |
|
||||
| `package.json` | Lists package dependencies. See [npm documentation](https://docs.npmjs.com/files/package.json) for the specific format and contents of this file.|
|
||||
| `tsconfig.app.json` | Default [TypeScript](https://www.typescriptlang.org/) configuration for apps in the workspace. |
|
||||
| `tsconfig.spec.json` | Default TypeScript configuration for e2e test apps in the workspace. |
|
||||
| `tslint.json` | Default [TSLint](https://palantir.github.io/tslint/) configuration for apps in the workspace. |
|
||||
| `README.md` | Introductory documentation. |
|
||||
| `package-lock.json` | Provides version information for all packages installed into `node_modules` by the npm client. See [npm documentation](https://docs.npmjs.com/files/package-lock.json) for details. If you use the yarn client, this file will be [yarn.lock](https://yarnpkg.com/lang/en/docs/yarn-lock/) instead. |
|
||||
|
||||
<div class="alert-is-helpful>
|
||||
All projects within a workspace share this configuration context.
|
||||
Project-specific [TypeScript](https://www.typescriptlang.org/) configuration files inherit from the workspace-wide `tsconfig.*.json`, and app-specific [TSLint](https://palantir.github.io/tslint/) configuration files inherit from the workspace-wide `tslint.json`.
|
||||
|
||||
### Default app project files
|
||||
|
||||
The CLI command `ng new my-app` creates a workspace folder named "my-app" and generates a new app skeleton.
|
||||
This initial app is the *default app* for CLI commands (unless you change the default after creating additional apps).
|
||||
|
||||
A newly generated app contains the source files for a root module, with a root component and template.
|
||||
When the workspace file structure is in place, you can use the `ng generate` command on the command line to add functionality and data to the initial app.
|
||||
|
||||
<div class="alert is-helpful>
|
||||
|
||||
Besides using the CLI on the command line, You can also use an interactive development environment like [Angular Console](https://angular.console.com), or manipulate files directly in the app's source folder and configuration files.
|
||||
|
||||
</div>
|
||||
|
||||
{@a global-config}
|
||||
The `src/` subfolder contains the source files (app logic, data, and assets), along with configuration files for the initial app.
|
||||
Workspace-wide `node_modules` dependencies are visible to this project.
|
||||
|
||||
## Global workspace configuration
|
||||
| APP SOURCE & CONFIG FILES | PURPOSE |
|
||||
| :--------------------- | :------------------------------------------|
|
||||
| `app/` | Contains the component files in which your app logic and data are defined. See details in [App source folder](#app-src) below. |
|
||||
| `assets/` | Contains image files and other asset files to be copied as-is when you build your application. |
|
||||
| `environments/` | Contains build configuration options for particular target environments. By default there is an unnamed standard development environment and a production ("prod") environment. You can define additional target environment configurations. |
|
||||
| `browserlist` | Configures sharing of target browsers and Node.js versions among various front-end tools. See [Browserlist on GitHub](https://github.com/browserslist/browserslist) for more information. |
|
||||
| `favicon.ico` | An icon to use for this app in the bookmark bar. |
|
||||
| `index.html` | The main HTML page that is served when someone visits your site. The CLI automatically adds all JavaScript and CSS files when building your app, so you typically don't need to add any `<script>` or` <link>` tags here manually. |
|
||||
| `main.ts` | The main entry point for your app. Compiles the application with the [JIT compiler](https://angular.io/guide/glossary#jit) and bootstraps the application's root module (AppModule) to run in the browser. You can also use the [AOT compiler](https://angular.io/guide/aot-compiler) without changing any code by appending the `--aot` flag to the CLI `build` and `serve` commands. |
|
||||
| `polyfills.ts` | Provides polyfill scripts for browser support. |
|
||||
| `styles.sass` | Lists CSS files that supply styles for a project. The extension reflects the style preprocessor you have configured for the project. |
|
||||
| `test.ts` | The main entry point for your unit tests, with some Angular-specific configuration. You don't typically need to edit this file. |
|
||||
| `tsconfig.app.json` | Inherits from the workspace-wide `tsconfig.json` file. |
|
||||
| `tsconfig.spec.json` | Inherits from the workspace-wide `tsconfig.json` file. |
|
||||
| `tslint.json` | Inherits from the workspace-wide `tslint.json` file. |
|
||||
|
||||
A workspace can contain additional apps and libraries, each with its own root folder under `projects/`.
|
||||
### Default app project e2e files
|
||||
|
||||
```
|
||||
my-workspace/
|
||||
app/
|
||||
projects/
|
||||
my-app/
|
||||
helpful-library/
|
||||
my-other-app/
|
||||
angular.json
|
||||
|
||||
```
|
||||
At the top level of the workspace, the CLI configuration file, `angular.json`, let you set defaults for all projects in the workspace. You can configure a workspace, for example, such that all projects in it have global access to libraries, scripts, and CSS styles. (For more in this, see [Configuring global access](#global-access).)
|
||||
An `e2e/` subfolder contains configuration and source files for a set of end-to-end tests that correspond to the initial app.
|
||||
Workspace-wide `node_modules` dependencies are visible to this project.
|
||||
|
||||
You can also use `ng generate app` to create new Angular apps in the workspace, and use the `ng add` command to add libraries.
|
||||
If you add libraries or generate more apps within a workspace, a `projects/` folder is created to contain the new libraries or apps.
|
||||
Additional apps and library subfolders have the same file structure as the initial app.
|
||||
<code-example language="none" linenums="false">
|
||||
my-app/
|
||||
e2e/ (end-to-end test app for my-app)
|
||||
src/ (app source files)
|
||||
protractor.conf.js (test-tool config)
|
||||
tsconfig.e2e.json (TypeScript config inherits from workspace tsconfig.json)
|
||||
</code-example>
|
||||
|
||||
All of the projects within a workspace share a CLI configuration context, controlled by the `angular.json` configuration file at the root level of the workspace.
|
||||
### Project folders for additional apps and libraries
|
||||
|
||||
| GLOBAL CONFIG FILES | PURPOSE |
|
||||
| :------------- | :------------------------------------------|
|
||||
| `angular.json` | Sets defaults for the CLI and configuration options for build, serve, and test tools that the CLI uses, such as [Karma](https://karma-runner.github.io/) and [Protractor](http://www.protractortest.org/). For complete details, see *CLI Reference (link TBD)*. |
|
||||
When you generate new projects in a workspace,
|
||||
the CLI creates a new *workspace*`/projects` folder, and adds the generated files there.
|
||||
|
||||
When you generate an app (`ng generate application my-other-app`), the CLI adds folders under `projects/` for both the app and its corresponding end-to-end tests. Newly generated libraries are also added under `projects/`.
|
||||
|
||||
<code-example language="none" linenums="false">
|
||||
my-app/
|
||||
...
|
||||
projects/ (additional apps and libs)
|
||||
my-other-app/ (a second app)
|
||||
src/
|
||||
(config files)
|
||||
my-other-app-e2e/ (corresponding test app)
|
||||
src/
|
||||
(config files)
|
||||
my-lib/ (a generated library)
|
||||
(config files)
|
||||
</code-example>
|
||||
|
||||
{@a app-src}
|
||||
## App source folder
|
||||
|
||||
The app-root source folder contains your app's logic and data. Angular components, templates, styles, images, and anything else your app needs go here. Files outside of the source folder support testing and building your app.
|
||||
Inside the `src/` folder, the `app/` folder contains your app's logic and data. Angular components, templates, and styles go here. An `assets/` subfolder contains images and anything else your app needs. Files at the top level of `src/` support testing and running your app.
|
||||
|
||||
```
|
||||
<code-example language="none" linenums="false">
|
||||
src/
|
||||
app/
|
||||
app.component.css
|
||||
@ -70,313 +113,14 @@ The app-root source folder contains your app's logic and data. Angular component
|
||||
app.component.ts
|
||||
app.module.ts
|
||||
assets/...
|
||||
favicon.ico
|
||||
index.html
|
||||
main.ts
|
||||
test.ts
|
||||
```
|
||||
...
|
||||
</code-example>
|
||||
|
||||
| APP SOURCE FILES | PURPOSE |
|
||||
| :----------------------------- | :------------------------------------------|
|
||||
| `app/app.component.ts` | Defines the logic for the app's root component, named AppComponent. The view associated with this root component becomes the root of the [view hierarchy](guide/glossary#view-hierarchy) as you add components and services to your app. |
|
||||
| `app/app.component.html` | Defines the HTML template associated with the root AppComponent. |
|
||||
| `app/app.component.css` | Defines the base CSS stylesheet for the root AppComponent. |
|
||||
| `app/app.component.spec.ts` | Defines a unit test for the root AppComponent. |
|
||||
| `app/app.module.ts` | Defines the root module, named AppModule, that tells Angular how to assemble the application. Initially declares only the AppComponent. As you add more components to the app, they must be declared here. |
|
||||
| `assets/*` | Contains image files and other asset files to be copied as-is when you build your application. |
|
||||
|
||||
| PROJECT-LEVEL FILES | PURPOSE |
|
||||
| :------------------------ | :------------------------------------------|
|
||||
| `favicon.ico` | An icon to use for this app in the bookmark bar. |
|
||||
| `index.html` | The main HTML page that is served when someone visits your site. The CLI automatically adds all JavaScript and CSS files when building your app, so you typically don't need to add any `<script>` or` <link>` tags here manually. |
|
||||
| `main.ts` | The main entry point for your app. Compiles the application with the [JIT compiler](https://angular.io/guide/glossary#jit) and bootstraps the application's root module (AppModule) to run in the browser. You can also use the [AOT compiler](https://angular.io/guide/aot-compiler) without changing any code by appending the `--aot` flag to the CLI `build` and `serve` commands. |
|
||||
| `test.ts` | The main entry point for your unit tests, with some Angular-specific configuration. You don't typically need to edit this file. |
|
||||
|
||||
## App support file structure
|
||||
|
||||
Additional files in a project's root folder help you build, test, maintain, document, and deploy the app. These files go in the app root folder next to `src/`.
|
||||
|
||||
```
|
||||
workspace_root/
|
||||
my-app/
|
||||
e2e/
|
||||
src/
|
||||
app.e2e-spec.ts
|
||||
app.po.ts
|
||||
tsconfig.e2e.json
|
||||
protractor.conf.js
|
||||
node_modules/...
|
||||
src/...
|
||||
```
|
||||
|
||||
| FOLDERS | PURPOSE |
|
||||
| :---------------- | :-------------------------------------------- |
|
||||
| `e2e/` | This folder contains end-to-end tests for the app. This is a separate app that tests your main app. The folder and its contents are generated automatically when you create a new app with the CLI `new` or `generate` command. |
|
||||
| `node_modules/` | Node.js creates this folder and puts all third party modules listed in `package.json` in it. *when? doesn't ng new create it?* |
|
||||
|
||||
### Project-level configuration
|
||||
|
||||
Each project uses the CLI configuration at the workspace root-level `angular.json` file.
|
||||
Additional project-specific configuration files are found at the project root level of each app or library.
|
||||
|
||||
```
|
||||
my-workspace/
|
||||
app/
|
||||
.editorconfig
|
||||
.gitignore
|
||||
package.json
|
||||
README.md
|
||||
tsconfig.json
|
||||
tsconfig.test.json
|
||||
tslint.json
|
||||
projects/
|
||||
helpful-library/
|
||||
my-other-app/
|
||||
.editorconfig
|
||||
.gitignore
|
||||
package.json
|
||||
README.md
|
||||
tsconfig.json
|
||||
tsconfig.test.json
|
||||
tslint.json
|
||||
angular.json
|
||||
```
|
||||
|
||||
| CONFIGURATION FILES | PURPOSE |
|
||||
| :------------------ | :-------------------------------------------- |
|
||||
| `.editorconfig` | Simple configuration for your editor to make sure everyone who uses your project has the same basic configuration. Supported by most editors. See http://editorconfig.org for more information. |
|
||||
| `.gitignore` | Git configuration to make sure autogenerated files are not committed to source control. |
|
||||
| `package.json` | Configures the `npm` package manager, listing the third party packages your project uses. You can also add your own custom scripts here. |
|
||||
| `README.md` | Basic documentation for your project, pre-filled with CLI command information. We recommend that you keep this updated so that anyone checking out the repo can build your app. |
|
||||
| `tsconfig.json` | TypeScript compiler configuration, that an IDE such as [Visual Studio Code](https://code.visualstudio.com/) uses to give you helpful tooling. |
|
||||
| `tslint.json` | Linting configuration for [TSLint](https://palantir.github.io/tslint/) together with [Codelyzer](http://codelyzer.com/), used when running the CLI `lint` command. Linting helps keep your code style consistent. |
|
||||
|
||||
{@a global-access}
|
||||
|
||||
## Configuring global access
|
||||
|
||||
The CLI configuration scope is global for a workspace.
|
||||
You can make scripts, libraries, and styles available to all projects in the workspace by setting options in the `angular.json` file in the root workspace folder.
|
||||
|
||||
|
||||
### Adding global scripts
|
||||
|
||||
You can configure your project to add JavaScript files to the global scope.
|
||||
This is especially useful for legacy libraries or analytic snippets.
|
||||
|
||||
In the CLI configuration file, `angular.json`, add the associated script files to the `scripts` array.
|
||||
The scripts are loaded exactly as if you had added them in a `<script>` tag inside `index.html`.
|
||||
For example:
|
||||
|
||||
```
|
||||
"architect": {
|
||||
"build": {
|
||||
"builder": "@angular-devkit/build-angular:browser",
|
||||
"options": {
|
||||
"scripts": [
|
||||
"src/global-script.js",
|
||||
],
|
||||
```
|
||||
|
||||
You can also rename the output from a script and lazy load it by using the object format in the "scripts" entry.
|
||||
For example:
|
||||
|
||||
```
|
||||
"scripts": [
|
||||
"src/global-script.js",
|
||||
{ "input": "src/lazy-script.js", "lazy": true },
|
||||
{ "input": "src/pre-rename-script.js", "bundleName": "renamed-script" },
|
||||
],
|
||||
```
|
||||
|
||||
If you need to add scripts for unit tests, specify them the same way in the "test" target.
|
||||
|
||||
{@a add-lib}
|
||||
### Adding a global library
|
||||
|
||||
Some JavaScript libraries need to be added to the global scope and loaded as if they were in a script tag.
|
||||
Configure the CLI to do this using the "scripts" and "styles" options of the build target in the CLI configuration file, `angular.json`.
|
||||
|
||||
For example, to use the [Bootstrap 4](https://getbootstrap.com/docs/4.0/getting-started/introduction/)
|
||||
library, first install the library and its dependencies using the `npm` package manager:
|
||||
|
||||
```
|
||||
npm install jquery --save
|
||||
npm install popper.js --save
|
||||
npm install bootstrap --save
|
||||
```
|
||||
|
||||
In the `angular.json` configuration file, add the associated script files to the "scripts" array:
|
||||
|
||||
```
|
||||
"scripts": [
|
||||
"node_modules/jquery/dist/jquery.slim.js",
|
||||
"node_modules/popper.js/dist/umd/popper.js",
|
||||
"node_modules/bootstrap/dist/js/bootstrap.js"
|
||||
],
|
||||
```
|
||||
|
||||
Add the Bootstrap CSS file to the "styles" array:
|
||||
|
||||
```
|
||||
"styles": [
|
||||
"node_modules/bootstrap/dist/css/bootstrap.css",
|
||||
"src/styles.css"
|
||||
],
|
||||
```
|
||||
|
||||
Run or restart `ng serve` to see Bootstrap 4 working in your app.
|
||||
|
||||
#### Using global libraries inside your app
|
||||
|
||||
Once you import a library using the "scripts" array in the configuration file,
|
||||
you should *not* import it using an `import` statement in your TypeScript code
|
||||
(such as `import * as $ from 'jquery';`).
|
||||
If you do, you'll end up with two different copies of the library:
|
||||
one imported as a global library, and one imported as a module.
|
||||
This is especially bad for libraries with plugins, like JQuery,
|
||||
because each copy will have different plugins.
|
||||
|
||||
Instead, download typings for your library (`npm install @types/jquery`) and follow the installation steps
|
||||
given above in [Adding a global library](#add-lib).
|
||||
This gives you access to the global variables exposed by that library.
|
||||
|
||||
{@a define-types}
|
||||
#### Defining typings for global libraries
|
||||
|
||||
If the global library you need to use does not have global typings,
|
||||
you can declare them manually as `any` in `src/typings.d.ts`. For example:
|
||||
|
||||
```
|
||||
declare var libraryName: any;
|
||||
```
|
||||
|
||||
Some scripts extend other libraries; for instance with JQuery plugins:
|
||||
|
||||
```
|
||||
$('.test').myPlugin();
|
||||
```
|
||||
|
||||
In this case, the installed `@types/jquery` doesn't include `myPlugin`,
|
||||
so you need to add an *interface* in `src/typings.d.ts`.
|
||||
For example:
|
||||
|
||||
```
|
||||
interface JQuery {
|
||||
myPlugin(options?: any): any;
|
||||
}
|
||||
```
|
||||
|
||||
If you fail to add the interface for the script-defined extension, your IDE shows an error:
|
||||
|
||||
```
|
||||
[TS][Error] Property 'myPlugin' does not exist on type 'JQuery'
|
||||
```
|
||||
|
||||
### Adding global styles and style preprocessors
|
||||
|
||||
Angular CLI supports CSS imports and all major CSS preprocessors:
|
||||
|
||||
* [Sass/Scss](http://sass-lang.com/)
|
||||
* [Less](http://lesscss.org/)
|
||||
* [Stylus](http://stylus-lang.com/)
|
||||
|
||||
Angular assumes CSS styles by default, but when you create a project with the
|
||||
CLI `new` command, you can specify the `--style` option to use SASS or STYL styles.
|
||||
|
||||
```
|
||||
> ng new sassyproject --style=sass
|
||||
> ng new scss-project --style=scss
|
||||
> ng new less-project --style=less
|
||||
> ng new styl-project --style=styl
|
||||
```
|
||||
|
||||
You can also set the default style for an existing project by configuring `@schematics/angular`,
|
||||
the default schematic for the Angular CLI:
|
||||
|
||||
```
|
||||
> ng config schematics.@schematics/angular:component.styleext scss
|
||||
```
|
||||
|
||||
#### Style configuration
|
||||
|
||||
By default, the `styles.css` configuration file lists CSS files that supply global styles for a project.
|
||||
If you are using another style type, there is a similar configuration file for global style files of that type,
|
||||
with the extension for that style type, such as `styles.sass`.
|
||||
|
||||
You can add more global styles by configuring the build options in the `angular.json` configuration file.
|
||||
List the style files in the "styles" section in your project's "build" target
|
||||
The files are loaded exactly as if you had added them in a `<link>` tag inside `index.html`.
|
||||
|
||||
```
|
||||
"architect": {
|
||||
"build": {
|
||||
"builder": "@angular-devkit/build-angular:browser",
|
||||
"options": {
|
||||
"styles": [
|
||||
"src/styles.css",
|
||||
"src/more-styles.css",
|
||||
],
|
||||
...
|
||||
```
|
||||
|
||||
If you need the styles in your unit tests, add them to the "styles" option in the "test" target configuration as well.
|
||||
|
||||
You can specify styles in an object format to rename the output and lazy load it:
|
||||
|
||||
```
|
||||
"styles": [
|
||||
"src/styles.css",
|
||||
"src/more-styles.css",
|
||||
{ "input": "src/lazy-style.scss", "lazy": true },
|
||||
{ "input": "src/pre-rename-style.scss", "bundleName": "renamed-style" },
|
||||
],
|
||||
```
|
||||
|
||||
In Sass and Stylus you can make use of the `includePaths` functionality for both component and global styles,
|
||||
which allows you to add extra base paths to be checked for imports.
|
||||
To add paths, use the `stylePreprocessorOptions` build-target option:
|
||||
|
||||
```
|
||||
"stylePreprocessorOptions": {
|
||||
"includePaths": [
|
||||
"src/style-paths"
|
||||
]
|
||||
},
|
||||
```
|
||||
|
||||
You can then import files in the given folder (such as `src/style-paths/_variables.scss`)
|
||||
anywhere in your project without the need for a relative path:
|
||||
|
||||
```
|
||||
// src/app/app.component.scss
|
||||
// A relative path works
|
||||
@import '../style-paths/variables';
|
||||
// But now this works as well
|
||||
@import 'variables';
|
||||
```
|
||||
|
||||
#### CSS preprocessor integration
|
||||
|
||||
To use a supported CSS preprocessor, add the URL for the preprocessor
|
||||
to your component's `styleUrls` in the `@Component()` metadata.
|
||||
For example:
|
||||
|
||||
```
|
||||
@Component({
|
||||
selector: 'app-root',
|
||||
templateUrl: './app.component.html',
|
||||
styleUrls: ['./app.component.scss']
|
||||
})
|
||||
export class AppComponent {
|
||||
title = 'app works!';
|
||||
}
|
||||
```
|
||||
|
||||
<div class="alert-is-helpful>
|
||||
|
||||
Style strings added directly to the `@Component() styles array must be written in CSS.
|
||||
The CLI cannot apply a pre-processor to inline styles.
|
||||
|
||||
</div>
|
||||
|
||||
| :-------------------------- | :------------------------------------------|
|
||||
| `app/app.component.ts` | Defines the logic for the app's root component, named `AppComponent`. The view associated with this root component becomes the root of the [view hierarchy](guide/glossary#view-hierarchy) as you add components and services to your app. |
|
||||
| `app/app.component.html` | Defines the HTML template associated with the root `AppComponent`. |
|
||||
| `app/app.component.css` | Defines the base CSS stylesheet for the root `AppComponent`. |
|
||||
| `app/app.component.spec.ts` | Defines a unit test for the root `AppComponent`. |
|
||||
| `app/app.module.ts` | Defines the root module, named `AppModule`, that tells Angular how to assemble the application. Initially declares only the `AppComponent`. As you add more components to the app, they must be declared here. |
|
||||
| `assets/*` | Contains image files and other asset files to be copied as-is when you build your application. |
|
||||
|
@ -29,7 +29,7 @@ either a list of validation errors, which results in an INVALID status, or null,
|
||||
You can then inspect the control's state by exporting `ngModel` to a local template variable.
|
||||
The following example exports `NgModel` into a variable called `name`:
|
||||
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="name-with-error-msg" title="template/hero-form-template.component.html (name)" linenums="false">
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="name-with-error-msg" header="template/hero-form-template.component.html (name)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -92,7 +92,7 @@ built-in validators—this time, in function form. See below:
|
||||
|
||||
{@a reactive-component-class}
|
||||
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.1.ts" region="form-group" title="reactive/hero-form-reactive.component.ts (validator functions)" linenums="false">
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.1.ts" region="form-group" header="reactive/hero-form-reactive.component.ts (validator functions)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Note that:
|
||||
@ -106,7 +106,7 @@ for the template.
|
||||
|
||||
If you look at the template for the name input again, it is fairly similar to the template-driven example.
|
||||
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.html" region="name-with-error-msg" title="reactive/hero-form-reactive.component.html (name with error msg)" linenums="false">
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.html" region="name-with-error-msg" header="reactive/hero-form-reactive.component.html (name with error msg)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Key takeaways:
|
||||
@ -125,7 +125,7 @@ Consider the `forbiddenNameValidator` function from previous
|
||||
[examples](guide/form-validation#reactive-component-class) in
|
||||
this guide. Here's what the definition of that function looks like:
|
||||
|
||||
<code-example path="form-validation/src/app/shared/forbidden-name.directive.ts" region="custom-validator" title="shared/forbidden-name.directive.ts (forbiddenNameValidator)" linenums="false">
|
||||
<code-example path="form-validation/src/app/shared/forbidden-name.directive.ts" region="custom-validator" header="shared/forbidden-name.directive.ts (forbiddenNameValidator)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The function is actually a factory that takes a regular expression to detect a _specific_ forbidden name and returns a validator function.
|
||||
@ -148,7 +148,7 @@ at which point the form uses the last value emitted for validation.
|
||||
In reactive forms, custom validators are fairly simple to add. All you have to do is pass the function directly
|
||||
to the `FormControl`.
|
||||
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.1.ts" region="custom-validator" title="reactive/hero-form-reactive.component.ts (validator functions)" linenums="false">
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.1.ts" region="custom-validator" header="reactive/hero-form-reactive.component.ts (validator functions)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Adding to template-driven forms
|
||||
@ -161,19 +161,19 @@ The corresponding `ForbiddenValidatorDirective` serves as a wrapper around the `
|
||||
Angular recognizes the directive's role in the validation process because the directive registers itself
|
||||
with the `NG_VALIDATORS` provider, a provider with an extensible collection of validators.
|
||||
|
||||
<code-example path="form-validation/src/app/shared/forbidden-name.directive.ts" region="directive-providers" title="shared/forbidden-name.directive.ts (providers)" linenums="false">
|
||||
<code-example path="form-validation/src/app/shared/forbidden-name.directive.ts" region="directive-providers" header="shared/forbidden-name.directive.ts (providers)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The directive class then implements the `Validator` interface, so that it can easily integrate
|
||||
with Angular forms. Here is the rest of the directive to help you get an idea of how it all
|
||||
comes together:
|
||||
|
||||
<code-example path="form-validation/src/app/shared/forbidden-name.directive.ts" region="directive" title="shared/forbidden-name.directive.ts (directive)">
|
||||
<code-example path="form-validation/src/app/shared/forbidden-name.directive.ts" region="directive" header="shared/forbidden-name.directive.ts (directive)">
|
||||
</code-example>
|
||||
|
||||
Once the `ForbiddenValidatorDirective` is ready, you can simply add its selector, `appForbiddenName`, to any input element to activate it. For example:
|
||||
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="name-input" title="template/hero-form-template.component.html (forbidden-name-input)" linenums="false">
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="name-input" header="template/hero-form-template.component.html (forbidden-name-input)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -204,7 +204,7 @@ Like in AngularJS, Angular automatically mirrors many control properties onto th
|
||||
The hero form uses the `.ng-valid` and `.ng-invalid` classes to
|
||||
set the color of each form control's border.
|
||||
|
||||
<code-example path="form-validation/src/assets/forms.css" title="forms.css (status classes)">
|
||||
<code-example path="form-validation/src/assets/forms.css" header="forms.css (status classes)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -245,7 +245,7 @@ const heroForm = new FormGroup({
|
||||
|
||||
The validator code is as follows:
|
||||
|
||||
<code-example path="form-validation/src/app/shared/identity-revealed.directive.ts" region="cross-validation-validator" title="shared/identity-revealed.directive.ts" linenums="false">
|
||||
<code-example path="form-validation/src/app/shared/identity-revealed.directive.ts" region="cross-validation-validator" header="shared/identity-revealed.directive.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The identity validator implements the `ValidatorFn` interface. It takes an Angular control object as an argument and returns either null if the form is valid, or `ValidationErrors` otherwise.
|
||||
@ -255,7 +255,7 @@ First we retrieve the child controls by calling the `FormGroup`'s [get](api/form
|
||||
If the values do not match, the hero's identity remains secret, and we can safely return null. Otherwise, the hero's identity is revealed and we must mark the form as invalid by returning an error object.
|
||||
|
||||
Next, to provide better user experience, we show an appropriate error message when the form is invalid.
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.html" region="cross-validation-error-message" title="reactive/hero-form-template.component.html" linenums="false">
|
||||
<code-example path="form-validation/src/app/reactive/hero-form-reactive.component.html" region="cross-validation-error-message" header="reactive/hero-form-template.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Note that we check if:
|
||||
@ -265,15 +265,15 @@ Note that we check if:
|
||||
### Adding to template driven forms
|
||||
First we must create a directive that will wrap the validator function. We provide it as the validator using the `NG_VALIDATORS` token. If you are not sure why, or you do not fully understand the syntax, revisit the previous [section](guide/form-validation#adding-to-template-driven-forms).
|
||||
|
||||
<code-example path="form-validation/src/app/shared/identity-revealed.directive.ts" region="cross-validation-directive" title="shared/identity-revealed.directive.ts" linenums="false">
|
||||
<code-example path="form-validation/src/app/shared/identity-revealed.directive.ts" region="cross-validation-directive" header="shared/identity-revealed.directive.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Next, we have to add the directive to the html template. Since the validator must be registered at the highest level in the form, we put the directive on the `form` tag.
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="cross-validation-register-validator" title="template/hero-form-template.component.html" linenums="false">
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="cross-validation-register-validator" header="template/hero-form-template.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
To provide better user experience, we show an appropriate error message when the form is invalid.
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="cross-validation-error-message" title="template/hero-form-template.component.html" linenums="false">
|
||||
<code-example path="form-validation/src/app/template/hero-form-template.component.html" region="cross-validation-error-message" header="template/hero-form-template.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Note that we check if:
|
||||
|
@ -1,21 +1,21 @@
|
||||
# Introduction to forms in Angular
|
||||
|
||||
Handling user input with forms is the cornerstone of many common applications. Applications use forms to enable users log in, to update a profile, to enter sensitive information, and to perform many other data-entry tasks.
|
||||
Handling user input with forms is the cornerstone of many common applications. Applications use forms to enable users to log in, to update a profile, to enter sensitive information, and to perform many other data-entry tasks.
|
||||
|
||||
Angular provides two different approaches to handling user input through forms: reactive and template-driven. Both capture user input events from the view, validate the user input, create a form model and data model to update, and provide a way to track changes.
|
||||
|
||||
Reactive and template-driven forms differ, however, in how they do the work of processing and managing forms and form data. Each offers different advantages.
|
||||
Reactive and template-driven forms process and manage form data differently. Each offers different advantages.
|
||||
|
||||
**In general:**
|
||||
|
||||
* **Reactive forms** are more robust: they are more scalable, reusable, and testable. If forms are a key part of your application, or you're already using reactive patterns for building your application, use reactive forms.
|
||||
* **Template-driven forms** are useful for adding a simple form to an app, such as an email list signup form. They are easy to add to an app, but they do not scale as well as reactive forms. If you have very basic form requirements and logic that can be managed solely in the template, use template-driven forms.
|
||||
* **Reactive forms** are more robust: they're more scalable, reusable, and testable. If forms are a key part of your application, or you're already using reactive patterns for building your application, use reactive forms.
|
||||
* **Template-driven forms** are useful for adding a simple form to an app, such as an email list signup form. They're easy to add to an app, but they don't scale as well as reactive forms. If you have very basic form requirements and logic that can be managed solely in the template, use template-driven forms.
|
||||
|
||||
This guide provides information to help you decide which approach works best for your situation. It introduces the common building blocks used by both approaches. It also summarizes the key differences between the two approaches, and demonstrates those differences in the context of setup, data flow, and testing.
|
||||
This guide provides information to help you decide which type of form works best for your situation. It introduces the common building blocks used by both approaches. It also summarizes the key differences between the two approaches, and demonstrates those differences in the context of setup, data flow, and testing.
|
||||
|
||||
<div class="alert is-important">
|
||||
<div class="alert is-helpful">
|
||||
|
||||
*Note:* For complete information about each kind of form, see the [Reactive Forms](guide/reactive-forms) and [Template-driven Forms](guide/forms) guides.
|
||||
**Note:** For complete information about each kind of form, see [Reactive Forms](guide/reactive-forms) and [Template-driven Forms](guide/forms).
|
||||
|
||||
</div>
|
||||
|
||||
@ -30,7 +30,7 @@ The table below summarizes the key differences between reactive and template-dri
|
||||
|
||||
||Reactive|Template-driven|
|
||||
|--- |--- |--- |
|
||||
|Setup (form model)|More explicit, created in the component class.|Less explicit, created by the directives.|
|
||||
|Setup (form model)|More explicit, created in component class|Less explicit, created by directives|
|
||||
|Data model|Structured|Unstructured|
|
||||
|Predictability|Synchronous|Asynchronous|
|
||||
|Form validation|Functions|Directives|
|
||||
@ -41,35 +41,41 @@ The table below summarizes the key differences between reactive and template-dri
|
||||
|
||||
Both reactive and template-driven forms share underlying building blocks.
|
||||
|
||||
- A `FormControl` instance that tracks the value and validation status of an individual form control.
|
||||
- A `FormGroup` instance that tracks the same values and status for a collection of form controls.
|
||||
- A `FormArray` instance that tracks the same values and status for an array of form controls.
|
||||
- A `ControlValueAccessor` that creates a bridge between Angular `FormControl` instances and native DOM elements.
|
||||
|
||||
How these control instances are created and managed with reactive and template-driven forms is introduced in the [form model setup](#setup-the-form-model) section below and detailed further in the [data flow section](#data-flow-in-forms) of this guide.
|
||||
* `FormControl` tracks the value and validation status of an individual form control.
|
||||
|
||||
## Setup: The form model
|
||||
* `FormGroup` tracks the same values and status for a collection of form controls.
|
||||
|
||||
Reactive and template-driven forms both use a form model to track value changes between Angular forms and form input elements. The examples below show how the form model is defined and created.
|
||||
* `FormArray` tracks the same values and status for an array of form controls.
|
||||
|
||||
* `ControlValueAccessor` creates a bridge between Angular `FormControl` instances and native DOM elements.
|
||||
|
||||
See the [Form model setup](#setup-the-form-model) section below for an introduction to how these control instances are created and managed with reactive and template-driven forms. Further details are provided in the [data flow section](#data-flow-in-forms) of this guide.
|
||||
|
||||
{@a setup-the-form-model}
|
||||
|
||||
## Form model setup
|
||||
|
||||
Reactive and template-driven forms both use a form model to track value changes between Angular forms and form input elements. The examples below show how the form model is defined and created.
|
||||
|
||||
### Setup in reactive forms
|
||||
|
||||
Here is a component with an input field for a single control implemented using reactive forms.
|
||||
Here's a component with an input field for a single control implemented using reactive forms.
|
||||
|
||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.ts">
|
||||
</code-example>
|
||||
|
||||
The source of truth provides the value and status of the form element at a given point in time. In reactive forms, the form model is source of truth. The form model in the above example is the `FormControl` instance.
|
||||
The source of truth provides the value and status of the form element at a given point in time. In reactive forms, the form model is the source of truth. In the example above, the form model is the `FormControl` instance.
|
||||
|
||||
<figure>
|
||||
<img src="generated/images/guide/forms-overview/key-diff-reactive-forms.png" alt="Reactive forms key differences">
|
||||
</figure>
|
||||
|
||||
With reactive forms, the form model is explicitly defined in the component class. The reactive form directive (in this case, `FormControlDirective`) then links the existing form control instance to a specific form element in the view using a value accessor (instance of `ControlValueAccessor`).
|
||||
With reactive forms, the form model is explicitly defined in the component class. The reactive form directive (in this case, `FormControlDirective`) then links the existing `FormControl` instance to a specific form element in the view using a value accessor (`ControlValueAccessor` instance).
|
||||
|
||||
### Setup in template-driven forms
|
||||
|
||||
Here is the same component with an input field for a single control implemented using template-driven forms.
|
||||
Here's the same component with an input field for a single control implemented using template-driven forms.
|
||||
|
||||
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.ts">
|
||||
</code-example>
|
||||
@ -80,23 +86,25 @@ In template-driven forms, the source of truth is the template.
|
||||
<img src="generated/images/guide/forms-overview/key-diff-td-forms.png" alt="Template-driven forms key differences">
|
||||
</figure>
|
||||
|
||||
The abstraction of the form model promotes simplicity over structure. The template-driven form directive `NgModel` is responsible for creating and managing the form control instance for a given form element. It is less explicit, but you no longer have direct control over the form model.
|
||||
The abstraction of the form model promotes simplicity over structure. The template-driven form directive `NgModel` is responsible for creating and managing the `FormControl` instance for a given form element. It's less explicit, but you no longer have direct control over the form model.
|
||||
|
||||
{@a data-flow-in-forms}
|
||||
|
||||
## Data flow in forms
|
||||
|
||||
When building forms in Angular, it's important to understand how the framework handles data flowing from the user or from programmatic changes. Reactive and template-driven forms follow two different strategies when handling form input. The data flow examples below begin with the favorite color input field example from above, and they show how changes to favorite color are handled in reactive forms compared to template-driven forms.
|
||||
When building forms in Angular, it's important to understand how the framework handles data flowing from the user or from programmatic changes. Reactive and template-driven forms follow two different strategies when handling form input. The data flow examples below begin with the favorite color input field example from above, and then show how changes to favorite color are handled in reactive forms compared to template-driven forms.
|
||||
|
||||
### Data flow in reactive forms
|
||||
|
||||
As described above, in reactive forms each form element in the view is directly linked to a form model (`FormControl` instance). Updates from the view to model and model to view are synchronous and not dependent on the UI rendered. The diagrams below use the same favorite color example to demonstrate how data flows when an input field's value is changed from the view and then from the model.
|
||||
As described above, in reactive forms each form element in the view is directly linked to a form model (`FormControl` instance). Updates from the view to the model and from the model to the view are synchronous and aren't dependent on the UI rendered. The diagrams below use the same favorite color example to demonstrate how data flows when an input field's value is changed from the view and then from the model.
|
||||
|
||||
<figure>
|
||||
<img src="generated/images/guide/forms-overview/dataflow-reactive-forms-vtm.png" alt="Reactive forms data flow - view to model" width="100%">
|
||||
</figure>
|
||||
|
||||
The steps below outline the view to model data flow.
|
||||
The steps below outline the data flow from view to model.
|
||||
|
||||
1. The end user types a value into the input element, in this case the favorite color "Blue".
|
||||
1. The user types a value into the input element, in this case the favorite color *Blue*.
|
||||
1. The form input element emits an "input" event with the latest value.
|
||||
1. The control value accessor listening for events on the form input element immediately relays the new value to the `FormControl` instance.
|
||||
1. The `FormControl` instance emits the new value through the `valueChanges` observable.
|
||||
@ -106,37 +114,37 @@ The steps below outline the view to model data flow.
|
||||
<img src="generated/images/guide/forms-overview/dataflow-reactive-forms-mtv.png" alt="Reactive forms data flow - model to view" width="100%">
|
||||
</figure>
|
||||
|
||||
The steps below outline the model to view data flow.
|
||||
The steps below outline the data flow from model to view.
|
||||
|
||||
1. The `favoriteColorControl.setValue()` method is called, which updates the `FormControl` value.
|
||||
1. The user calls the `favoriteColorControl.setValue()` method, which updates the `FormControl` value.
|
||||
1. The `FormControl` instance emits the new value through the `valueChanges` observable.
|
||||
1. Any subscribers to the `valueChanges` observable receive the new value.
|
||||
1. The control value accessor on the form input element updates the element with the new value.
|
||||
|
||||
### Data flow in template-driven forms
|
||||
|
||||
In template-driven forms, each form element is linked to a directive that manages the form model internally. The diagrams below uses the same favorite color example to demonstrate how data flows when an input field's value is changed from the view and then from the model.
|
||||
In template-driven forms, each form element is linked to a directive that manages the form model internally. The diagrams below use the same favorite color example to demonstrate how data flows when an input field's value is changed from the view and then from the model.
|
||||
|
||||
<figure>
|
||||
<img src="generated/images/guide/forms-overview/dataflow-td-forms-vtm.png" alt="Template-driven forms view to model data flow" width="100%">
|
||||
<img src="generated/images/guide/forms-overview/dataflow-td-forms-vtm.png" alt="Template-driven forms data flow - view to model" width="100%">
|
||||
</figure>
|
||||
|
||||
The steps below outline the view to model data flow.
|
||||
The steps below outline the data flow from view to model when the input value changes from *Red* to *Blue*.
|
||||
|
||||
1. The end user types "Blue" into the input element.
|
||||
1. The input element emits an "input" event with the value "Blue".
|
||||
1. The user types *Blue* into the input element.
|
||||
1. The input element emits an "input" event with the value *Blue*.
|
||||
1. The control value accessor attached to the input triggers the `setValue()` method on the `FormControl` instance.
|
||||
1. The `FormControl` instance emits the new value through the `valueChanges` observable.
|
||||
1. Any subscribers to the `valueChanges` observable receive the new value.
|
||||
1. The control value accessor also calls the `NgModel.viewToModel()` method which emits an `ngModelChange` event.
|
||||
1. Because the component template uses two-way data binding for the `favoriteColor`, the `favoriteColor` property in the component
|
||||
is updated to the value emitted by the `ngModelChange` event ("Blue").
|
||||
1. The control value accessor also calls the `NgModel.viewToModelUpdate()` method which emits an `ngModelChange` event.
|
||||
1. Because the component template uses two-way data binding for the `favoriteColor` property, the `favoriteColor` property in the component
|
||||
is updated to the value emitted by the `ngModelChange` event (*Blue*).
|
||||
|
||||
<figure>
|
||||
<img src="generated/images/guide/forms-overview/dataflow-td-forms-mtv.png" alt="Template-driven forms model to view data flow" width="100%">
|
||||
<img src="generated/images/guide/forms-overview/dataflow-td-forms-mtv.png" alt="Template-driven forms data flow - model to view" width="100%">
|
||||
</figure>
|
||||
|
||||
The steps below outline the model to view data flow.
|
||||
The steps below outline the data flow from model to view when the `favoriteColor` changes from *Blue* to *Red*.
|
||||
|
||||
1. The `favoriteColor` value is updated in the component.
|
||||
1. Change detection begins.
|
||||
@ -150,110 +158,117 @@ The steps below outline the model to view data flow.
|
||||
|
||||
## Form validation
|
||||
|
||||
Validation is an integral part of managing any set of forms. Whether you’re checking for required fields or querying an external API for an existing username, Angular provides a set of built-in validators as well as the ability to create custom validators.
|
||||
Validation is an integral part of managing any set of forms. Whether you're checking for required fields or querying an external API for an existing username, Angular provides a set of built-in validators as well as the ability to create custom validators.
|
||||
|
||||
* **Reactive forms** define custom validators as **functions** that receive a control to validate.
|
||||
* **Template-driven forms** are tied to template **directives**, and must provide custom validator directives that wrap validation functions.
|
||||
|
||||
For more on form validation, see the [Form Validation](guide/form-validation) guide.
|
||||
For more information, see [Form Validation](guide/form-validation).
|
||||
|
||||
## Testing
|
||||
|
||||
Testing also plays a large part in complex applications and an easier testing strategy is always welcomed. One difference in testing reactive forms and template-driven forms is their reliance on rendering the UI in order to perform assertions based on form control and form field changes. The following examples demonstrate the process of testing forms with reactive and template-driven forms.
|
||||
Testing plays a large part in complex applications and a simpler testing strategy is useful when validating that your forms function correctly. Reactive forms and template-driven forms have different levels of reliance on rendering the UI to perform assertions based on form control and form field changes. The following examples demonstrate the process of testing forms with reactive and template-driven forms.
|
||||
|
||||
### Testing reactive forms
|
||||
|
||||
Reactive forms provide a relatively easy testing strategy because they provide synchronous access to the form and data models, and they can be tested without rendering the UI. In these set of tests, controls and data are queried and manipulated through the control without interacting with the change detection cycle.
|
||||
Reactive forms provide a relatively easy testing strategy because they provide synchronous access to the form and data models, and they can be tested without rendering the UI. In these tests, status and data are queried and manipulated through the control without interacting with the change detection cycle.
|
||||
|
||||
The following tests use the favorite color components mentioned earlier to verify the view to model and model to view data flows for a reactive form.
|
||||
The following tests use the favorite color components mentioned earlier to verify the data flows from view to model and model to view for a reactive form.
|
||||
|
||||
The following test verifies the view to model data flow:
|
||||
The following test verifies the data flow from view to model.
|
||||
|
||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="view-to-model" title="Favorite color test - view to model">
|
||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="view-to-model" header="Favorite color test - view to model">
|
||||
</code-example>
|
||||
|
||||
The steps performed in the view to model test.
|
||||
Here are the steps performed in the view to model test.
|
||||
|
||||
1. Query the view for the form input element, and create a custom "input" event for the test.
|
||||
1. Set the new value for the input is set to *Red*, and dispatch the "input" event on the form input element.
|
||||
1. Assert that the `favoriteColor` `FormControl` instance value matches the value from the input.
|
||||
1. Set the new value for the input to *Red*, and dispatch the "input" event on the form input element.
|
||||
1. Assert that the component's `favoriteColorControl` value matches the value from the input.
|
||||
|
||||
The following test verifies the model to view data flow:
|
||||
The following test verifies the data flow from model to view.
|
||||
|
||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="model-to-view" title="Favorite color test - model to view">
|
||||
<code-example path="forms-overview/src/app/reactive/favorite-color/favorite-color.component.spec.ts" region="model-to-view" header="Favorite color test - model to view">
|
||||
</code-example>
|
||||
|
||||
The steps performed in the model to view test.
|
||||
Here are the steps performed in the model to view test.
|
||||
|
||||
1. Use the `favoriteColor` `FormControl` instance to set the new value.
|
||||
1. Use the `favoriteColorControl`, a `FormControl` instance, to set the new value.
|
||||
1. Query the view for the form input element.
|
||||
1. Assert that the new value set on the control matches the value in the input.
|
||||
|
||||
### Testing template-driven forms
|
||||
|
||||
Writing tests with template-driven forms requires more detailed knowledge of the change detection process and how directives run on each cycle to ensure elements are queried, tested, or changed at the correct time.
|
||||
Writing tests with template-driven forms requires a detailed knowledge of the change detection process and an understanding of how directives run on each cycle to ensure that elements are queried, tested, or changed at the correct time.
|
||||
|
||||
The following tests use the favorite color components mentioned earlier to verify the view to model and model to view data flows for a template-driven form.
|
||||
The following tests use the favorite color components mentioned earlier to verify the data flows from view to model and model to view for a template-driven form.
|
||||
|
||||
The following test verifies the view to model data flow:
|
||||
The following test verifies the data flow from view to model.
|
||||
|
||||
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.spec.ts" region="view-to-model" title="Favorite color test - view to model">
|
||||
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.spec.ts" region="view-to-model" header="Favorite color test - view to model">
|
||||
</code-example>
|
||||
|
||||
The steps performed in the view to model test.
|
||||
Here are the steps performed in the view to model test.
|
||||
|
||||
1. Query the view for the form input element, and create a custom "input" event for the test.
|
||||
1. Set the new value for the input is set to *Red*, and dispatch the "input" event on the form input element.
|
||||
1. Set the new value for the input to *Red*, and dispatch the "input" event on the form input element.
|
||||
1. Run change detection through the test fixture.
|
||||
1. Assert that the component `favoriteColor` property value matches the value from the input.
|
||||
|
||||
The following test verifies the model to view data flow:
|
||||
The following test verifies the data flow from model to view.
|
||||
|
||||
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.spec.ts" region="model-to-view" title="Favorite color test - model to view">
|
||||
<code-example path="forms-overview/src/app/template/favorite-color/favorite-color.component.spec.ts" region="model-to-view" header="Favorite color test - model to view">
|
||||
</code-example>
|
||||
|
||||
The steps performed in the model to view test.
|
||||
Here are the steps performed in the model to view test.
|
||||
|
||||
1. Use the component instance to set the value of `favoriteColor` property.
|
||||
1. Use the component instance to set the value of the `favoriteColor` property.
|
||||
1. Run change detection through the test fixture.
|
||||
1. Use the `tick()` method to simulate passage of time within the `fakeAsync()` task.
|
||||
1. Use the `tick()` method to simulate the passage of time within the `fakeAsync()` task.
|
||||
1. Query the view for the form input element.
|
||||
1. Assert that the input value matches the `favoriteColor` value property in the component instance.
|
||||
1. Assert that the input value matches the value of the `favoriteColor` property in the component instance.
|
||||
|
||||
## Mutability
|
||||
|
||||
How changes are tracked plays a role in the efficiency of your application.
|
||||
The change tracking method plays a role in the efficiency of your application.
|
||||
|
||||
- **Reactive forms** keep the data model pure by providing it as an immutable data structure. Each time a change is triggered on the data model, the `FormControl` instance returns a new data model rather than updating the data model directly. This gives you the ability track unique changes to the data model through the control's observable. This allows change detection to be more efficient because it only needs to update on unique changes. It also follows reactive patterns that integrate with observable operators to transform data.
|
||||
- **Template-driven** forms rely on mutability with two-way data binding to update the data model in the component as changes are made in the template. Because there are no unique changes to track on the data model when using two-way data binding, change detection is less efficient at determining when updates are required.
|
||||
|
||||
* **Reactive forms** keep the data model pure by providing it as an immutable data structure. Each time a change is triggered on the data model, the `FormControl` instance returns a new data model rather than updating the existing data model. This gives you the ability to track unique changes to the data model through the control's observable. This provides one way for change detection to be more efficient because it only needs to update on unique changes. It also follows reactive patterns that integrate with observable operators to transform data.
|
||||
|
||||
* **Template-driven** forms rely on mutability with two-way data binding to update the data model in the component as changes are made in the template. Because there are no unique changes to track on the data model when using two-way data binding, change detection is less efficient at determining when updates are required.
|
||||
|
||||
The difference is demonstrated in the examples above using the **favorite color** input element.
|
||||
|
||||
- With reactive forms, the **`FormControl` instance** always returns a new value when the control's value is updated.
|
||||
- With template-driven forms, the **favorite color property** is always modified to its new value.
|
||||
|
||||
* With reactive forms, the **`FormControl` instance** always returns a new value when the control's value is updated.
|
||||
|
||||
* With template-driven forms, the **favorite color property** is always modified to its new value.
|
||||
|
||||
## Scalability
|
||||
|
||||
If forms are a central part of your application, scalability is very important. Being able to reuse form models across components is critical.
|
||||
|
||||
- **Reactive forms** make creating large scale forms easier by providing access to low-level APIs and synchronous access to the form model.
|
||||
- **Template-driven** forms focus on simple scenarios, are not as reusable, abstract away the low-level APIs and access to the form model is provided asynchronously. The abstraction with template-driven forms surfaces in testing also, where testing reactive forms requires less setup and no dependence on the change detection cycle when updating and validating the form and data models during testing.
|
||||
|
||||
## Final Thoughts
|
||||
* **Reactive forms** provide access to low-level APIs and synchronous access to the form model, making creating large-scale forms easier.
|
||||
|
||||
Choosing a strategy begins with understanding the strengths and weaknesses of the options presented. Low-level API and form model access, predictability, mutability, straightforward validation and testing strategies, and scalability are all important consideration in choosing the infrastructure you use when building your forms in Angular. Template-driven forms are similar to patterns in AngularJS, but they have limitations given the criteria of many modern, large-scale Angular apps. Reactive forms integrate with reactive patterns already present in other areas of the Angular architecture, and complement those requirements well. Those limitations are alleviated with reactive forms.
|
||||
* **Template-driven** forms focus on simple scenarios, are not as reusable, abstract away the low-level APIs, and provide asynchronous access to the form model. The abstraction with template-driven forms also surfaces in testing, where testing reactive forms requires less setup and no dependence on the change detection cycle when updating and validating the form and data models during testing.
|
||||
|
||||
## Final thoughts
|
||||
|
||||
Choosing a strategy begins with understanding the strengths and weaknesses of the options presented. Low-level API and form model access, predictability, mutability, straightforward validation and testing strategies, and scalability are all important considerations in choosing the infrastructure you use to build your forms in Angular. Template-driven forms are similar to patterns in AngularJS, but they have limitations given the criteria of many modern, large-scale Angular apps. Reactive forms minimize these limitations. Reactive forms integrate with reactive patterns already present in other areas of the Angular architecture, and complement those requirements well.
|
||||
|
||||
## Next steps
|
||||
|
||||
## Next Steps
|
||||
|
||||
The following guides are the next steps in the learning process.
|
||||
|
||||
To learn more about reactive forms, see the following guides:
|
||||
|
||||
* [Reactive Forms](guide/reactive-forms)
|
||||
* [Form Validation](guide/form-validation#reactive-form-validation)
|
||||
* [Dynamic forms](guide/dynamic-form)
|
||||
* [Dynamic Forms](guide/dynamic-form)
|
||||
|
||||
To learn more about template-driven forms, see the following guides:
|
||||
|
||||
* [Template-driven Forms](guide/forms)
|
||||
* [Template-driven Forms](guide/forms#template-driven-forms)
|
||||
* [Form Validation](guide/form-validation#template-driven-validation)
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Forms
|
||||
# Template-driven forms
|
||||
|
||||
Forms are the mainstay of business applications.
|
||||
You use forms to log in, submit a help request, place an order, book a flight,
|
||||
@ -7,6 +7,8 @@ schedule a meeting, and perform countless other data-entry tasks.
|
||||
In developing a form, it's important to create a data-entry experience that guides the
|
||||
user efficiently and effectively through the workflow.
|
||||
|
||||
## Introduction to Template-driven forms
|
||||
|
||||
Developing forms requires design skills (which are out of scope for this page), as well as framework support for
|
||||
*two-way data binding, change tracking, validation, and error handling*,
|
||||
which you'll learn about on this page.
|
||||
@ -24,8 +26,6 @@ You can run the <live-example></live-example> in Stackblitz and download the cod
|
||||
|
||||
{@a template-driven}
|
||||
|
||||
## Template-driven forms
|
||||
|
||||
You can build forms by writing templates in the Angular [template syntax](guide/template-syntax) with
|
||||
the form-specific directives and techniques described in this page.
|
||||
|
||||
@ -99,7 +99,7 @@ A model can be as simple as a "property bag" that holds facts about a thing of a
|
||||
That describes well the `Hero` class with its three required fields (`id`, `name`, `power`)
|
||||
and one optional field (`alterEgo`).
|
||||
|
||||
Using the Angular CLI, generate a new class named `Hero`:
|
||||
Using the Angular CLI command [`ng generate class`](cli/generate), generate a new class named `Hero`:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
|
||||
@ -109,7 +109,7 @@ Using the Angular CLI, generate a new class named `Hero`:
|
||||
|
||||
With this content:
|
||||
|
||||
<code-example path="forms/src/app/hero.ts" title="src/app/hero.ts">
|
||||
<code-example path="forms/src/app/hero.ts" header="src/app/hero.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -132,7 +132,7 @@ An Angular form has two parts: an HTML-based _template_ and a component _class_
|
||||
to handle data and user interactions programmatically.
|
||||
Begin with the class because it states, in brief, what the hero editor can do.
|
||||
|
||||
Using the Angular CLI, generate a new component named `HeroForm`:
|
||||
Using the Angular CLI command [`ng generate component`](cli/generate), generate a new component named `HeroForm`:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
|
||||
@ -142,7 +142,7 @@ Using the Angular CLI, generate a new component named `HeroForm`:
|
||||
|
||||
With this content:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" title="src/app/hero-form/hero-form.component.ts (v1)" region="v1">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" header="src/app/hero-form/hero-form.component.ts (v1)" region="v1">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -176,7 +176,7 @@ Because template-driven forms are in their own module, you need to add the `Form
|
||||
|
||||
Update it with the following:
|
||||
|
||||
<code-example path="forms/src/app/app.module.ts" title="src/app/app.module.ts">
|
||||
<code-example path="forms/src/app/app.module.ts" header="src/app/app.module.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -204,7 +204,7 @@ Update it with the following:
|
||||
|
||||
Replace the contents of its template with the following:
|
||||
|
||||
<code-example path="forms/src/app/app.component.html" title="src/app/app.component.html">
|
||||
<code-example path="forms/src/app/app.component.html" header="src/app/app.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -221,7 +221,7 @@ Replace the contents of its template with the following:
|
||||
|
||||
Update the template file with the following contents:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="start" title="src/app/hero-form/hero-form.component.html">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="start" header="src/app/hero-form/hero-form.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -259,7 +259,7 @@ Bootstrap gives the form a little style.
|
||||
|
||||
To add the stylesheet, open `styles.css` and add the following import line at the top:
|
||||
|
||||
<code-example path="forms/src/styles.1.css" linenums="false" title="src/styles.css">
|
||||
<code-example path="forms/src/styles.1.css" linenums="false" header="src/styles.css">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -274,7 +274,7 @@ a technique seen previously in the [Displaying Data](guide/displaying-data) page
|
||||
|
||||
Add the following HTML *immediately below* the *Alter Ego* group:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (powers)" region="powers">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (powers)" region="powers">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -307,7 +307,7 @@ makes binding the form to the model easy.
|
||||
|
||||
Find the `<input>` tag for *Name* and update it like this:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModelName-1">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModelName-1">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -325,7 +325,7 @@ You need one more addition to display the data. Declare
|
||||
a template variable for the form. Update the `<form>` tag with
|
||||
`#heroForm="ngForm"` as follows:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="template-variable">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="template-variable">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -391,7 +391,7 @@ Then you can confirm that two-way data binding works *for the entire hero model*
|
||||
|
||||
After revision, the core of the form should look like this:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModel-2">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModel-2">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -493,7 +493,7 @@ You can leverage those class names to change the appearance of the control.
|
||||
Temporarily add a [template reference variable](guide/template-syntax#ref-vars) named `spy`
|
||||
to the _Name_ `<input>` tag and use it to display the input's CSS classes.
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModelName-2">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModelName-2">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -535,13 +535,13 @@ on the left of the input box:
|
||||
You achieve this effect by adding these class definitions to a new `forms.css` file
|
||||
that you add to the project as a sibling to `index.html`:
|
||||
|
||||
<code-example path="forms/src/assets/forms.css" title="src/assets/forms.css">
|
||||
<code-example path="forms/src/assets/forms.css" header="src/assets/forms.css">
|
||||
|
||||
</code-example>
|
||||
|
||||
Update the `<head>` of `index.html` to include this style sheet:
|
||||
|
||||
<code-example path="forms/src/index.html" linenums="false" title="src/index.html (styles)" region="styles">
|
||||
<code-example path="forms/src/index.html" linenums="false" header="src/index.html (styles)" region="styles">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -564,7 +564,7 @@ To achieve this effect, extend the `<input>` tag with the following:
|
||||
|
||||
Here's an example of an error message added to the _name_ input box:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="name-with-error-msg">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="name-with-error-msg">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -583,7 +583,7 @@ Here you created a variable called `name` and gave it the value "ngModel".
|
||||
You control visibility of the name error message by binding properties of the `name`
|
||||
control to the message `<div>` element's `hidden` property.
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (hidden-error-msg)" region="hidden-error-msg">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (hidden-error-msg)" region="hidden-error-msg">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -609,11 +609,11 @@ power to valid values.
|
||||
Now you'll add a new hero in this form.
|
||||
Place a *New Hero* button at the bottom of the form and bind its click event to a `newHero` component method.
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="new-hero-button-no-reset" title="src/app/hero-form/hero-form.component.html (New Hero button)">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="new-hero-button-no-reset" header="src/app/hero-form/hero-form.component.html (New Hero button)">
|
||||
|
||||
</code-example>
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.ts" region="new-hero" title="src/app/hero-form/hero-form.component.ts (New Hero method)" linenums="false">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.ts" region="new-hero" header="src/app/hero-form/hero-form.component.ts (New Hero method)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -634,7 +634,7 @@ Replacing the hero object *did not restore the pristine state* of the form contr
|
||||
You have to clear all of the flags imperatively, which you can do
|
||||
by calling the form's `reset()` method after calling the `newHero()` method.
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="new-hero-button-form-reset" title="src/app/hero-form/hero-form.component.html (Reset the form)">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="new-hero-button-form-reset" header="src/app/hero-form/hero-form.component.html (Reset the form)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -651,7 +651,7 @@ A "form submit" is useless at the moment.
|
||||
To make it useful, bind the form's `ngSubmit` event property
|
||||
to the hero form component's `onSubmit()` method:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (ngSubmit)" region="ngSubmit">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (ngSubmit)" region="ngSubmit">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -664,7 +664,7 @@ You'll bind the form's overall validity via
|
||||
the `heroForm` variable to the button's `disabled` property
|
||||
using an event binding. Here's the code:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (submit-button)" region="submit-button">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (submit-button)" region="submit-button">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -703,7 +703,7 @@ hide the data entry area and display something else.
|
||||
Wrap the form in a `<div>` and bind
|
||||
its `hidden` property to the `HeroFormComponent.submitted` property.
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="edit-div">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="edit-div">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -711,7 +711,7 @@ The main form is visible from the start because the
|
||||
`submitted` property is false until you submit the form,
|
||||
as this fragment from the `HeroFormComponent` shows:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" title="src/app/hero-form/hero-form.component.ts (submitted)" region="submitted">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" header="src/app/hero-form/hero-form.component.ts (submitted)" region="submitted">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -721,7 +721,7 @@ as planned.
|
||||
Now the app needs to show something else while the form is in the submitted state.
|
||||
Add the following HTML below the `<div>` wrapper you just wrote:
|
||||
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="submitted">
|
||||
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" header="src/app/hero-form/hero-form.component.html (excerpt)" region="submitted">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -752,35 +752,35 @@ Here’s the code for the final version of the application:
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="hero-form/hero-form.component.ts" path="forms/src/app/hero-form/hero-form.component.ts" region="final">
|
||||
<code-pane header="hero-form/hero-form.component.ts" path="forms/src/app/hero-form/hero-form.component.ts" region="final">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="hero-form/hero-form.component.html" path="forms/src/app/hero-form/hero-form.component.html" region="final">
|
||||
<code-pane header="hero-form/hero-form.component.html" path="forms/src/app/hero-form/hero-form.component.html" region="final">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="hero.ts" path="forms/src/app/hero.ts">
|
||||
<code-pane header="hero.ts" path="forms/src/app/hero.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.module.ts" path="forms/src/app/app.module.ts">
|
||||
<code-pane header="app.module.ts" path="forms/src/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.component.html" path="forms/src/app/app.component.html">
|
||||
<code-pane header="app.component.html" path="forms/src/app/app.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.component.ts" path="forms/src/app/app.component.ts">
|
||||
<code-pane header="app.component.ts" path="forms/src/app/app.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="main.ts" path="forms/src/main.ts">
|
||||
<code-pane header="main.ts" path="forms/src/main.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="forms.css" path="forms/src/assets/forms.css">
|
||||
<code-pane header="forms.css" path="forms/src/assets/forms.css">
|
||||
|
||||
</code-pane>
|
||||
|
||||
|
@ -71,7 +71,7 @@ of some of the things they contain:
|
||||
|
||||
When you use these Angular modules, import them in `AppModule`,
|
||||
or your feature module as appropriate, and list them in the `@NgModule`
|
||||
`imports` array. For example, in the basic app generated by the CLI,
|
||||
`imports` array. For example, in the basic app generated by the [Angular CLI](cli),
|
||||
`BrowserModule` is the first import at the top of the `AppModule`,
|
||||
`app.module.ts`.
|
||||
|
||||
|
@ -130,10 +130,10 @@ A [decorator](guide/glossary#decorator) statement immediately before a field in
|
||||
|
||||
## command-line interface (CLI)
|
||||
|
||||
The [Angular CLI](https://cli.angular.io/) is a command-line tool for managing the Angular development cycle. Use it to create the initial filesystem scaffolding for a [workspace](guide/glossary#workspace) or [project](guide/glossary#project), and to run [schematics](guide/glossary#schematic) that add and modify code for initial generic versions of various elements. The CLI supports all stages of the development cycle, including building, testing, bundling, and deployment.
|
||||
The [Angular CLI](cli) is a command-line tool for managing the Angular development cycle. Use it to create the initial filesystem scaffolding for a [workspace](guide/glossary#workspace) or [project](guide/glossary#project), and to run [schematics](guide/glossary#schematic) that add and modify code for initial generic versions of various elements. The CLI supports all stages of the development cycle, including building, testing, bundling, and deployment.
|
||||
|
||||
* To begin using the CLI for a new project, see [Getting Started](guide/quickstart).
|
||||
* To learn more about the full capabilities of the CLI, see the [Angular CLI documentation](https://github.com/angular/angular-cli/wiki).
|
||||
* To learn more about the full capabilities of the CLI, see the [CLI command reference](cli).
|
||||
|
||||
{@a component}
|
||||
|
||||
@ -621,8 +621,7 @@ For more information, see [Routing and Navigation](guide/router).
|
||||
A scaffolding library that defines how to generate or transform a programming project by creating, modifying, refactoring, or moving files and code.
|
||||
The Angular [CLI](guide/glossary#cli) uses schematics to generate and modify [Angular projects](guide/glossary#project) and parts of projects.
|
||||
|
||||
* Angular provides a set of schematics for use with the CLI.
|
||||
For details, see [Angular CLI documentation](https://github.com/angular/angular-cli/wiki).
|
||||
* Angular provides a set of schematics for use with the CLI. See the [Angular CLI command reference](cli). The [`ng add`](cli/add) command runs schematics as part of adding a library to your project. The [`ng generate`](cli/generate) command runs schematics to create apps, libraries, and Angular code constructs.
|
||||
|
||||
* Library developers can create schematics that enable the CLI to generate their published libraries.
|
||||
For more information, see [devkit documentation](https://www.npmjs.com/package/@angular-devkit/schematics).
|
||||
@ -636,7 +635,7 @@ NgModules are delivered within scoped packages whose names begin with the Angula
|
||||
|
||||
Import a scoped package in the same way that you import a normal package.
|
||||
|
||||
<code-example path="architecture/src/app/app.component.ts" linenums="false" title="architecture/src/app/app.component.ts (import)" region="import">
|
||||
<code-example path="architecture/src/app/app.component.ts" linenums="false" header="architecture/src/app/app.component.ts (import)" region="import">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -785,7 +784,7 @@ See [custom element](guide/glossary#custom-element).
|
||||
## workspace
|
||||
|
||||
In Angular, a folder that contains [projects](guide/glossary#project) (that is, apps and libraries).
|
||||
The [CLI](guide/glossary#cli) `new` command creates a workspace to contain projects.
|
||||
The [CLI](guide/glossary#cli) `ng new` command creates a workspace to contain projects.
|
||||
Commands that create or operate on apps and libraries (such as `add` and `generate`) must be executed from within a workspace folder.
|
||||
|
||||
{@a X}
|
||||
|
@ -23,9 +23,9 @@ When you specify providers in the `@Injectable()` decorator of the service itsel
|
||||
|
||||
* Learn more about [tree-shakable providers](guide/dependency-injection-providers#tree-shakable-providers).
|
||||
|
||||
You're likely to inject `UserService` in many places throughout the app and will want to inject the same service instance every time. Providing `UserService` through the `root` injector is a good choice, and is the default that the CLI uses when you generate a service for your app.
|
||||
You're likely to inject `UserService` in many places throughout the app and will want to inject the same service instance every time. Providing `UserService` through the `root` injector is a good choice, and is the default that the [Angular CLI](cli) uses when you generate a service for your app.
|
||||
|
||||
<div class="alert-is-helpful">
|
||||
<div class="alert is-helpful">
|
||||
<header>Platform injector</header>
|
||||
|
||||
When you use `providedIn:'root'`, you are configuring the root injector for the _app_, which is the injector for `AppModule`.
|
||||
@ -75,7 +75,7 @@ When an injectable class provides its own service to the `root` injector, the se
|
||||
|
||||
The following example configures a provider for `HeroService` using the `@Injectable()` decorator on the class.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.0.ts" title="src/app/heroes/heroes.service.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.0.ts" header="src/app/heroes/heroes.service.ts" linenums="false"> </code-example>
|
||||
|
||||
This configuration tells Angular that the app's root injector is responsible for creating an
|
||||
instance of `HeroService` by invoking its constructor,
|
||||
@ -92,7 +92,7 @@ Instead of specifying the `root` injector, you can set `providedIn` to a specifi
|
||||
For example, in the following excerpt, the `@Injectable()` decorator configures a provider
|
||||
that is available in any injector that includes the `HeroModule`.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.4.ts" title="src/app/heroes/hero.service.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/heroes/hero.service.4.ts" header="src/app/heroes/hero.service.ts" linenums="false"> </code-example>
|
||||
|
||||
This is generally no different from configuring the injector of the NgModule itself,
|
||||
except that the service is tree-shakable if the NgModule doesn't use it.
|
||||
@ -117,7 +117,7 @@ Here is an example of the case where the component router configuration includes
|
||||
a non-default [location strategy](guide/router#location-strategy) by listing its provider
|
||||
in the `providers` list of the `AppModule`.
|
||||
|
||||
<code-example path="dependency-injection-in-action/src/app/app.module.ts" region="providers" title="src/app/app.module.ts (providers)" linenums="false">
|
||||
<code-example path="dependency-injection-in-action/src/app/app.module.ts" region="providers" header="src/app/app.module.ts (providers)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -132,7 +132,7 @@ by configuring the provider at the component level using the `@Component` metada
|
||||
|
||||
The following example is a revised `HeroesComponent` that specifies `HeroService` in its `providers` array. `HeroService` can provide heroes to instances of this component, or to any child component instances.
|
||||
|
||||
<code-example path="dependency-injection/src/app/heroes/heroes.component.1.ts" title="src/app/heroes/heroes.component.ts" linenums="false">
|
||||
<code-example path="dependency-injection/src/app/heroes/heroes.component.1.ts" header="src/app/heroes/heroes.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Element injectors
|
||||
@ -207,7 +207,7 @@ that would make the `VillainsService` available everywhere in the application, i
|
||||
Instead, you can provide the `VillainsService` in the `providers` metadata of the `VillainsListComponent` like this:
|
||||
|
||||
|
||||
<code-example path="hierarchical-dependency-injection/src/app/villains-list.component.ts" linenums="false" title="src/app/villains-list.component.ts (metadata)" region="metadata">
|
||||
<code-example path="hierarchical-dependency-injection/src/app/villains-list.component.ts" linenums="false" header="src/app/villains-list.component.ts (metadata)" region="metadata">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -250,14 +250,14 @@ It caches a single `HeroTaxReturn`, tracks changes to that return, and can save
|
||||
It also delegates to the application-wide singleton `HeroService`, which it gets by injection.
|
||||
|
||||
|
||||
<code-example path="hierarchical-dependency-injection/src/app/hero-tax-return.service.ts" title="src/app/hero-tax-return.service.ts">
|
||||
<code-example path="hierarchical-dependency-injection/src/app/hero-tax-return.service.ts" header="src/app/hero-tax-return.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
Here is the `HeroTaxReturnComponent` that makes use of it.
|
||||
|
||||
|
||||
<code-example path="hierarchical-dependency-injection/src/app/hero-tax-return.component.ts" title="src/app/hero-tax-return.component.ts">
|
||||
<code-example path="hierarchical-dependency-injection/src/app/hero-tax-return.component.ts" header="src/app/hero-tax-return.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -273,7 +273,7 @@ Every component would share the same service instance, and each component would
|
||||
To prevent this, we configure the component-level injector of `HeroTaxReturnComponent` to provide the service, using the `providers` property in the component metadata.
|
||||
|
||||
|
||||
<code-example path="hierarchical-dependency-injection/src/app/hero-tax-return.component.ts" linenums="false" title="src/app/hero-tax-return.component.ts (providers)" region="providers">
|
||||
<code-example path="hierarchical-dependency-injection/src/app/hero-tax-return.component.ts" linenums="false" header="src/app/hero-tax-return.component.ts (providers)" region="providers">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -28,7 +28,7 @@ Most apps do so in the root `AppModule`.
|
||||
<code-example
|
||||
path="http/src/app/app.module.ts"
|
||||
region="sketch"
|
||||
title="app/app.module.ts (excerpt)" linenums="false">
|
||||
header="app/app.module.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Having imported `HttpClientModule` into the `AppModule`, you can inject the `HttpClient`
|
||||
@ -37,7 +37,7 @@ into an application class as shown in the following `ConfigService` example.
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="proto"
|
||||
title="app/config/config.service.ts (excerpt)" linenums="false">
|
||||
header="app/config/config.service.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
## Getting JSON data
|
||||
@ -48,7 +48,7 @@ that specifies resource URLs.
|
||||
|
||||
<code-example
|
||||
path="http/src/assets/config.json"
|
||||
title="assets/config.json" linenums="false">
|
||||
header="assets/config.json" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `ConfigService` fetches this file with a `get()` method on `HttpClient`.
|
||||
@ -56,7 +56,7 @@ The `ConfigService` fetches this file with a `get()` method on `HttpClient`.
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="getConfig_1"
|
||||
title="app/config/config.service.ts (getConfig v.1)" linenums="false">
|
||||
header="app/config/config.service.ts (getConfig v.1)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
A component, such as `ConfigComponent`, injects the `ConfigService` and calls
|
||||
@ -65,7 +65,7 @@ the `getConfig` service method.
|
||||
<code-example
|
||||
path="http/src/app/config/config.component.ts"
|
||||
region="v1"
|
||||
title="app/config/config.component.ts (showConfig v.1)" linenums="false">
|
||||
header="app/config/config.component.ts (showConfig v.1)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Because the service method returns an `Observable` of configuration data,
|
||||
@ -116,7 +116,7 @@ Then, specify that interface as the `HttpClient.get()` call's type parameter in
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="getConfig_2"
|
||||
title="app/config/config.service.ts (getConfig v.2)" linenums="false">
|
||||
header="app/config/config.service.ts (getConfig v.2)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The callback in the updated component method receives a typed data object, which is
|
||||
@ -125,7 +125,7 @@ easier and safer to consume:
|
||||
<code-example
|
||||
path="http/src/app/config/config.component.ts"
|
||||
region="v2"
|
||||
title="app/config/config.component.ts (showConfig v.2)" linenums="false">
|
||||
header="app/config/config.component.ts (showConfig v.2)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Reading the full response
|
||||
@ -146,7 +146,7 @@ The component's `showConfigResponse()` method displays the response headers as w
|
||||
<code-example
|
||||
path="http/src/app/config/config.component.ts"
|
||||
region="showConfigResponse"
|
||||
title="app/config/config.component.ts (showConfigResponse)"
|
||||
header="app/config/config.component.ts (showConfigResponse)"
|
||||
linenums="false">
|
||||
</code-example>
|
||||
|
||||
@ -161,7 +161,7 @@ You _could_ handle in the component by adding a second callback to the `.subscri
|
||||
<code-example
|
||||
path="http/src/app/config/config.component.ts"
|
||||
region="v3"
|
||||
title="app/config/config.component.ts (showConfig v.3 with error handling)"
|
||||
header="app/config/config.component.ts (showConfig v.3 with error handling)"
|
||||
linenums="false">
|
||||
</code-example>
|
||||
|
||||
@ -188,7 +188,7 @@ You might first devise an error handler like this one:
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="handleError"
|
||||
title="app/config/config.service.ts (handleError)" linenums="false">
|
||||
header="app/config/config.service.ts (handleError)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Notice that this handler returns an RxJS [`ErrorObservable`](#rxjs) with a user-friendly error message.
|
||||
@ -201,7 +201,7 @@ and _pipe them through_ to the error handler.
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="getConfig_3"
|
||||
title="app/config/config.service.ts (getConfig v.3 with error handler)" linenums="false">
|
||||
header="app/config/config.service.ts (getConfig v.3 with error handler)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### `retry()`
|
||||
@ -218,7 +218,7 @@ _Pipe_ it onto the `HttpClient` method result just before the error handler.
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="getConfig"
|
||||
title="app/config/config.service.ts (getConfig with retry)" linenums="false">
|
||||
header="app/config/config.service.ts (getConfig with retry)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a rxjs}
|
||||
@ -239,7 +239,7 @@ If you're following along with these code snippets, note that you must import th
|
||||
<code-example
|
||||
path="http/src/app/config/config.service.ts"
|
||||
region="rxjs-imports"
|
||||
title="app/config/config.service.ts (RxJS imports)" linenums="false">
|
||||
header="app/config/config.service.ts (RxJS imports)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
## Requesting non-JSON data
|
||||
@ -252,7 +252,7 @@ as an `Observable<string>`.
|
||||
<code-example
|
||||
path="http/src/app/downloader/downloader.service.ts"
|
||||
region="getTextFile"
|
||||
title="app/downloader/downloader.service.ts (getTextFile)" linenums="false">
|
||||
header="app/downloader/downloader.service.ts (getTextFile)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
`HttpClient.get()` returns a string rather than the default JSON because of the `responseType` option.
|
||||
@ -264,7 +264,7 @@ A `download()` method in the `DownloaderComponent` initiates the request by subs
|
||||
<code-example
|
||||
path="http/src/app/downloader/downloader.component.ts"
|
||||
region="download"
|
||||
title="app/downloader/downloader.component.ts (download)" linenums="false">
|
||||
header="app/downloader/downloader.component.ts (download)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
## Sending data to the server
|
||||
@ -289,7 +289,7 @@ to every `HttpClient` save method.
|
||||
<code-example
|
||||
path="http/src/app/heroes/heroes.service.ts"
|
||||
region="http-options"
|
||||
title="app/heroes/heroes.service.ts (httpOptions)" linenums="false">
|
||||
header="app/heroes/heroes.service.ts (httpOptions)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Making a POST request
|
||||
@ -300,7 +300,7 @@ In the following example, the `HeroesService` posts when adding a hero to the da
|
||||
<code-example
|
||||
path="http/src/app/heroes/heroes.service.ts"
|
||||
region="addHero"
|
||||
title="app/heroes/heroes.service.ts (addHero)" linenums="false">
|
||||
header="app/heroes/heroes.service.ts (addHero)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `HttpClient.post()` method is similar to `get()` in that it has a type parameter
|
||||
@ -320,7 +320,7 @@ the `Observable` returned by this service method.
|
||||
<code-example
|
||||
path="http/src/app/heroes/heroes.component.ts"
|
||||
region="add-hero-subscribe"
|
||||
title="app/heroes/heroes.component.ts (addHero)" linenums="false">
|
||||
header="app/heroes/heroes.component.ts (addHero)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
When the server responds successfully with the newly added hero, the component adds
|
||||
@ -334,7 +334,7 @@ in the request URL.
|
||||
<code-example
|
||||
path="http/src/app/heroes/heroes.service.ts"
|
||||
region="deleteHero"
|
||||
title="app/heroes/heroes.service.ts (deleteHero)" linenums="false">
|
||||
header="app/heroes/heroes.service.ts (deleteHero)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `HeroesComponent` initiates the actual DELETE operation by subscribing to
|
||||
@ -343,7 +343,7 @@ the `Observable` returned by this service method.
|
||||
<code-example
|
||||
path="http/src/app/heroes/heroes.component.ts"
|
||||
region="delete-hero-subscribe"
|
||||
title="app/heroes/heroes.component.ts (deleteHero)" linenums="false">
|
||||
header="app/heroes/heroes.component.ts (deleteHero)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The component isn't expecting a result from the delete operation, so it subscribes without a callback. Even though you are not using the result, you still have to subscribe. Calling the `subscribe()` method _executes_ the observable, which is what initiates the DELETE request.
|
||||
@ -403,7 +403,7 @@ The following `HeroesService` example is just like the POST example.
|
||||
<code-example
|
||||
path="http/src/app/heroes/heroes.service.ts"
|
||||
region="updateHero"
|
||||
title="app/heroes/heroes.service.ts (updateHero)" linenums="false">
|
||||
header="app/heroes/heroes.service.ts (updateHero)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
For the reasons [explained above](#always-subscribe), the caller (`HeroesComponent.update()` in this case) must `subscribe()` to the observable returned from the `HttpClient.put()`
|
||||
@ -464,7 +464,7 @@ Here's a pertinent excerpt from the template:
|
||||
<code-example
|
||||
path="http/src/app/package-search/package-search.component.html"
|
||||
region="search"
|
||||
title="app/package-search/package-search.component.html (search)">
|
||||
header="app/package-search/package-search.component.html (search)">
|
||||
</code-example>
|
||||
|
||||
The `(keyup)` event binding sends every keystroke to the component's `search()` method.
|
||||
@ -476,7 +476,7 @@ That's easy to implement with RxJS operators, as shown in this excerpt.
|
||||
<code-example
|
||||
path="http/src/app/package-search/package-search.component.ts"
|
||||
region="debounce"
|
||||
title="app/package-search/package-search.component.ts (excerpt))">
|
||||
header="app/package-search/package-search.component.ts (excerpt))">
|
||||
</code-example>
|
||||
|
||||
The `searchText$` is the sequence of search-box values coming from the user.
|
||||
@ -543,7 +543,7 @@ To implement an interceptor, declare a class that implements the `intercept()` m
|
||||
Here is a do-nothing _noop_ interceptor that simply passes the request through without touching it:
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/noop-interceptor.ts"
|
||||
title="app/http-interceptors/noop-interceptor.ts"
|
||||
header="app/http-interceptors/noop-interceptor.ts"
|
||||
linenums="false">
|
||||
</code-example>
|
||||
|
||||
@ -608,7 +608,7 @@ Consider creating a "barrel" file that gathers all the interceptor providers int
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/index.ts"
|
||||
region="interceptor-providers"
|
||||
title="app/http-interceptors/index.ts" linenums="false">
|
||||
header="app/http-interceptors/index.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Then import and add it to the `AppModule` _providers array_ like this:
|
||||
@ -616,7 +616,7 @@ Then import and add it to the `AppModule` _providers array_ like this:
|
||||
<code-example
|
||||
path="http/src/app/app.module.ts"
|
||||
region="interceptor-providers"
|
||||
title="app/app.module.ts (interceptor providers)" linenums="false">
|
||||
header="app/app.module.ts (interceptor providers)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
As you create new interceptors, add them to the `httpInterceptorProviders` array and
|
||||
@ -672,7 +672,7 @@ You can clone and modify the request in a single step as in this example.
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/ensure-https-interceptor.ts"
|
||||
region="excerpt"
|
||||
title="app/http-interceptors/ensure-https-interceptor.ts (excerpt)" linenums="false">
|
||||
header="app/http-interceptors/ensure-https-interceptor.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `clone()` method's hash argument allows you to mutate specific properties of the request while copying the others.
|
||||
@ -692,7 +692,7 @@ If you must mutate the request body, copy it first, change the copy,
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/trim-name-interceptor.ts"
|
||||
region="excerpt"
|
||||
title="app/http-interceptors/trim-name-interceptor.ts (excerpt)" linenums="false">
|
||||
header="app/http-interceptors/trim-name-interceptor.ts (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
##### Clearing the request body
|
||||
@ -718,7 +718,7 @@ adds an authorization header with that token to every outgoing request:
|
||||
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/auth-interceptor.ts"
|
||||
title="app/http-interceptors/auth-interceptor.ts">
|
||||
header="app/http-interceptors/auth-interceptor.ts">
|
||||
</code-example>
|
||||
|
||||
The practice of cloning a request to set new headers is so common that
|
||||
@ -747,7 +747,7 @@ with the injected `MessageService`.
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/logging-interceptor.ts"
|
||||
region="excerpt"
|
||||
title="app/http-interceptors/logging-interceptor.ts)">
|
||||
header="app/http-interceptors/logging-interceptor.ts)">
|
||||
</code-example>
|
||||
|
||||
The RxJS `tap` operator captures whether the request succeed or failed.
|
||||
@ -768,7 +768,7 @@ The `CachingInterceptor` demonstrates this approach.
|
||||
<code-example
|
||||
path="http/src/app/http-interceptors/caching-interceptor.ts"
|
||||
region="v1"
|
||||
title="app/http-interceptors/caching-interceptor.ts)" linenums="false">
|
||||
header="app/http-interceptors/caching-interceptor.ts)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `isCachable()` function determines if the request is cachable.
|
||||
@ -858,7 +858,7 @@ with the `reportProgress` option set true to enable tracking of progress events.
|
||||
<code-example
|
||||
path="http/src/app/uploader/uploader.service.ts"
|
||||
region="upload-request"
|
||||
title="app/uploader/uploader.service.ts (upload request)">
|
||||
header="app/uploader/uploader.service.ts (upload request)">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-important">
|
||||
@ -873,7 +873,7 @@ returns an `Observable` of `HttpEvents`, the same events processed by intercepto
|
||||
<code-example
|
||||
path="http/src/app/uploader/uploader.service.ts"
|
||||
region="upload-body"
|
||||
title="app/uploader/uploader.service.ts (upload body)" linenums="false">
|
||||
header="app/uploader/uploader.service.ts (upload body)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `getEventMessage` method interprets each type of `HttpEvent` in the event stream.
|
||||
@ -881,7 +881,7 @@ The `getEventMessage` method interprets each type of `HttpEvent` in the event st
|
||||
<code-example
|
||||
path="http/src/app/uploader/uploader.service.ts"
|
||||
region="getEventMessage"
|
||||
title="app/uploader/uploader.service.ts (getEventMessage)" linenums="false">
|
||||
header="app/uploader/uploader.service.ts (getEventMessage)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -964,7 +964,7 @@ along with the other symbols your tests require.
|
||||
<code-example
|
||||
path="http/src/testing/http-client.spec.ts"
|
||||
region="imports"
|
||||
title="app/testing/http-client.spec.ts (imports)" linenums="false">
|
||||
header="app/testing/http-client.spec.ts (imports)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Then add the `HttpClientTestingModule` to the `TestBed` and continue with
|
||||
@ -973,7 +973,7 @@ the setup of the _service-under-test_.
|
||||
<code-example
|
||||
path="http/src/testing/http-client.spec.ts"
|
||||
region="setup"
|
||||
title="app/testing/http-client.spec.ts(setup)" linenums="false">
|
||||
header="app/testing/http-client.spec.ts(setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Now requests made in the course of your tests will hit the testing backend instead of the normal backend.
|
||||
@ -988,7 +988,7 @@ Now you can write a test that expects a GET Request to occur and provides a mock
|
||||
<code-example
|
||||
path="http/src/testing/http-client.spec.ts"
|
||||
region="get-test"
|
||||
title="app/testing/http-client.spec.ts(httpClient.get)" linenums="false">
|
||||
header="app/testing/http-client.spec.ts(httpClient.get)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The last step, verifying that no requests remain outstanding, is common enough for you to move it into an `afterEach()` step:
|
||||
|
@ -19,7 +19,7 @@ Angular simplifies the following aspects of internationalization:
|
||||
* Handling plural forms of words.
|
||||
* Handling alternative text.
|
||||
|
||||
For localization, you can use the [**Angular CLI**](https://cli.angular.io/) to generate most of the boilerplate necessary to create files for translators, and to publish your app in multiple languages.
|
||||
For localization, you can use the [Angular CLI](cli) to generate most of the boilerplate necessary to create files for translators, and to publish your app in multiple languages.
|
||||
After you have set up your app to use i18n, the CLI can help you with the following steps:
|
||||
* Extracting localizable text into a file that you can send out to be translated.
|
||||
* Building and serving the app for a given locale, using the translated text.
|
||||
@ -57,7 +57,7 @@ To set your app's locale to another value, use the CLI parameter `--configuratio
|
||||
|
||||
If you use JIT, you also need to define the `LOCALE_ID` provider in your main module:
|
||||
|
||||
<code-example path="i18n/doc-files/app.module.ts" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.module.ts" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -97,7 +97,7 @@ The CLI imports the locale data for you when you use the parameter `--configurat
|
||||
|
||||
If you want to import locale data for other languages, you can do it manually:
|
||||
|
||||
<code-example path="i18n/doc-files/app.locale_data.ts" region="import-locale" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.locale_data.ts" region="import-locale" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The first parameter is an object containing the locale data imported from `@angular/common/locales`.
|
||||
@ -112,7 +112,7 @@ The files in `@angular/common/locales` contain most of the locale data that you
|
||||
need, but some advanced formatting options might only be available in the extra dataset that you can
|
||||
import from `@angular/common/locales/extra`. An error message informs you when this is the case.
|
||||
|
||||
<code-example path="i18n/doc-files/app.locale_data_extra.ts" region="import-locale-extra" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.locale_data_extra.ts" region="import-locale-extra" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -158,12 +158,12 @@ text is to be translated.
|
||||
|
||||
In the example below, an `<h1>` tag displays a simple English language greeting, "Hello i18n!"
|
||||
|
||||
<code-example path="i18n/doc-files/app.component.html" region="greeting" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.component.html" region="greeting" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
To mark the greeting for translation, add the `i18n` attribute to the `<h1>` tag.
|
||||
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-attribute" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-attribute" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -183,7 +183,7 @@ To translate a text message accurately, the translator may need additional infor
|
||||
You can add a description of the text message as the value of the `i18n` attribute, as shown in the
|
||||
example below:
|
||||
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-attribute-desc" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-attribute-desc" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The translator may also need to know the meaning or intent of the text message within this particular
|
||||
@ -192,7 +192,7 @@ app context.
|
||||
You add context by beginning the `i18n` attribute value with the _meaning_ and
|
||||
separating it from the _description_ with the `|` character: `<meaning>|<description>`
|
||||
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-attribute-meaning" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-attribute-meaning" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
All occurrences of a text message that have the same meaning will have the same translation.
|
||||
@ -220,7 +220,7 @@ You must then update the translation file with the new id.
|
||||
Alternatively, you can specify a custom id in the `i18n` attribute by using the prefix `@@`.
|
||||
The example below defines the custom id `introductionHeader`:
|
||||
|
||||
<code-example path='i18n/doc-files/app.component.html' region='i18n-attribute-solo-id' title='app/app.component.html' linenums="false">
|
||||
<code-example path='i18n/doc-files/app.component.html' region='i18n-attribute-solo-id' header='app/app.component.html' linenums="false">
|
||||
</code-example>
|
||||
|
||||
When you specify a custom id, the extractor tool and compiler generate a translation unit with that
|
||||
@ -238,12 +238,12 @@ You can use a custom id in combination with a description by including both in t
|
||||
`i18n` attribute. In the example below, the `i18n` attribute value includes a description, followed
|
||||
by the custom `id`:
|
||||
|
||||
<code-example path='i18n/doc-files/app.component.html' region='i18n-attribute-id' title='app/app.component.html' linenums="false">
|
||||
<code-example path='i18n/doc-files/app.component.html' region='i18n-attribute-id' header='app/app.component.html' linenums="false">
|
||||
</code-example>
|
||||
|
||||
You also can add a meaning, as shown in this example:
|
||||
|
||||
<code-example path='i18n/doc-files/app.component.html' region='i18n-attribute-meaning-and-id' title='app/app.component.html' linenums="false">
|
||||
<code-example path='i18n/doc-files/app.component.html' region='i18n-attribute-meaning-and-id' header='app/app.component.html' linenums="false">
|
||||
</code-example>
|
||||
|
||||
#### Define unique custom ids
|
||||
@ -287,7 +287,7 @@ However, if you don't want to create a new DOM element merely to facilitate tran
|
||||
you can wrap the text in an `<ng-container>` element.
|
||||
The `<ng-container>` is transformed into an html comment:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-ng-container" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-ng-container" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a translate-attributes}
|
||||
@ -296,14 +296,14 @@ The `<ng-container>` is transformed into an html comment:
|
||||
Displayed text is sometimes supplied as the value of an attribute, rather than the content of tag.
|
||||
For example, if your template has an image with a `title` attribute, the text value of the `title` attribute needs to be translated.
|
||||
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-title" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.component.html" region="i18n-title" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
To mark an attribute for translation, add an attribute in the form of `i18n-x`,
|
||||
where `x` is the name of the attribute to translate. The following example shows how to mark the
|
||||
`title` attribute for translation by adding the `i18n-title` attribute on the `img` tag:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-title-translate" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-title-translate" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
This technique works for any attribute of any element.
|
||||
@ -328,7 +328,7 @@ Other languages might express the cardinality differently.
|
||||
The example below shows how to use a `plural` ICU expression to display one of those three options
|
||||
based on when the update occurred:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-plural" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-plural" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
* The first parameter is the key. It is bound to the component property (`minutes`), which determines
|
||||
@ -384,7 +384,7 @@ The following format message in the component template binds to the component's
|
||||
which outputs one of the following string values: "m", "f" or "o".
|
||||
The message maps those values to the appropriate translations:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-select" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-select" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a nesting-ICUS}
|
||||
@ -392,7 +392,7 @@ The message maps those values to the appropriate translations:
|
||||
|
||||
You can also nest different ICU expressions together, as shown in this example:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-nested" title="src/app/app.component.html">
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-nested" header="src/app/app.component.html">
|
||||
</code-example>
|
||||
|
||||
{@a ng-xi18n}
|
||||
@ -413,7 +413,7 @@ By default, the command creates a file named `messages.xlf` in your `src/` folde
|
||||
|
||||
If you don't use the CLI, you have two options:
|
||||
* You can use the `ng-xi18n` tool directly from the `@angular/compiler-cli` package.
|
||||
For more information, see [i18n in the CLI documentation](https://github.com/angular/angular-cli/wiki/xi18n).
|
||||
For more information, see the [`ng xi18n` command documentation](cli/xi18n).
|
||||
* You can use the CLI Webpack plugin `AngularCompilerPlugin` from the `@ngtools/webpack` package.
|
||||
Set the parameters `i18nOutFile` and `i18nOutFormat` to trigger the extraction.
|
||||
For more information, see the [Angular Ahead-of-Time Webpack Plugin documentation](https://github.com/angular/angular-cli/tree/master/packages/%40ngtools/webpack).
|
||||
@ -530,7 +530,7 @@ This sample file is easy to translate without a special editor or knowledge of F
|
||||
|
||||
1. Open `messages.fr.xlf` and find the first `<trans-unit>` section:
|
||||
|
||||
> <code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-hello-before" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
> <code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-hello-before" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
> This XML element represents the translation of the `<h1>` greeting tag that you marked with the
|
||||
@ -546,12 +546,12 @@ This sample file is easy to translate without a special editor or knowledge of F
|
||||
and context provided by the source, description, and meaning elements to guide your selection of
|
||||
the appropriate French translation.
|
||||
|
||||
> <code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-hello" title="src/locale/messages.fr.xlf (<trans-unit>, after translation)" linenums="false">
|
||||
> <code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-hello" header="src/locale/messages.fr.xlf (<trans-unit>, after translation)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
3. Translate the other text nodes the same way:
|
||||
|
||||
> <code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-other-nodes" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
> <code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-other-nodes" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-important">
|
||||
@ -578,7 +578,7 @@ must be just below the translation unit for the logo.
|
||||
|
||||
To translate a `plural`, translate its ICU format match values:
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-plural" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-plural" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You can add or remove plural cases, with each language having its own cardinality. (See
|
||||
@ -589,7 +589,7 @@ You can add or remove plural cases, with each language having its own cardinalit
|
||||
|
||||
Below is the content of our example `select` ICU expression in the component template:
|
||||
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-select" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="i18n/src/app/app.component.html" region="i18n-select" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The extraction tool broke that into two translation units because ICU expressions are extracted
|
||||
@ -600,18 +600,18 @@ In place of the `select` is a placeholder, `<x id="ICU">`, that represents the `
|
||||
Translate the text and move around the placeholder if necessary, but don't remove it. If you remove
|
||||
the placeholder, the ICU expression will not be present in your translated app.
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-select-1" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-select-1" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The second translation unit, immediately below the first one, contains the `select` message.
|
||||
Translate that as well.
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-select-2" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-select-2" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here they are together, after translation:
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-select" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translated-select" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a translate-nested}
|
||||
@ -620,17 +620,17 @@ Here they are together, after translation:
|
||||
A nested expression is similar to the previous examples. As in the previous example, there are
|
||||
two translation units. The first one contains the text outside of the nested expression:
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-nested-1" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-nested-1" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The second unit contains the complete nested expression:
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-nested-2" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-nested-2" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
And both together:
|
||||
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-nested" title="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
<code-example path="i18n/doc-files/messages.fr.xlf.html" region="translate-nested" header="src/locale/messages.fr.xlf (<trans-unit>)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The entire template translation is complete. The next section describes how to load that translation
|
||||
@ -642,15 +642,15 @@ into the app.
|
||||
The sample app and its translation file are now as follows:
|
||||
|
||||
<code-tabs>
|
||||
<code-pane title="src/app/app.component.html" path="i18n/src/app/app.component.html">
|
||||
<code-pane header="src/app/app.component.html" path="i18n/src/app/app.component.html">
|
||||
</code-pane>
|
||||
<code-pane title="src/app/app.component.ts" path="i18n/src/app/app.component.ts">
|
||||
<code-pane header="src/app/app.component.ts" path="i18n/src/app/app.component.ts">
|
||||
</code-pane>
|
||||
<code-pane title="src/app/app.module.ts" path="i18n/src/app/app.module.ts">
|
||||
<code-pane header="src/app/app.module.ts" path="i18n/src/app/app.module.ts">
|
||||
</code-pane>
|
||||
<code-pane title="src/main.ts" path="i18n/doc-files/main.1.ts">
|
||||
<code-pane header="src/main.ts" path="i18n/doc-files/main.1.ts">
|
||||
</code-pane>
|
||||
<code-pane title="src/locale/messages.fr.xlf" path="i18n/doc-files/messages.fr.xlf.html">
|
||||
<code-pane header="src/locale/messages.fr.xlf" path="i18n/doc-files/messages.fr.xlf.html">
|
||||
</code-pane>
|
||||
</code-tabs>
|
||||
|
||||
@ -790,12 +790,12 @@ while compiling the app:
|
||||
The Angular `bootstrapModule` method has a second `compilerOptions` parameter that can influence the
|
||||
behavior of the compiler. You can use it to specify the translation providers:
|
||||
|
||||
<code-example path="i18n/doc-files/main.2.ts" title="src/main.ts">
|
||||
<code-example path="i18n/doc-files/main.2.ts" header="src/main.ts">
|
||||
</code-example>
|
||||
|
||||
Then provide the `LOCALE_ID` in the main module:
|
||||
|
||||
<code-example path="i18n/doc-files/app.module.ts" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="i18n/doc-files/app.module.ts" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -826,7 +826,7 @@ If you use the JIT compiler, specify the warning level in the compiler config at
|
||||
the 'MissingTranslationStrategy' property. The example below shows how to set the warning level to
|
||||
error:
|
||||
|
||||
<code-example path="i18n/doc-files/main.3.ts" title="src/main.ts">
|
||||
<code-example path="i18n/doc-files/main.3.ts" header="src/main.ts">
|
||||
</code-example>
|
||||
|
||||
### Build for multiple locales
|
||||
|
@ -98,7 +98,7 @@ placeholder markup in `app.component.html` with a custom nav
|
||||
so you can easily navigate to your modules in the browser:
|
||||
|
||||
|
||||
<code-example path="lazy-loading-ngmodules/src/app/app.component.html" region="app-component-template" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="lazy-loading-ngmodules/src/app/app.component.html" region="app-component-template" header="src/app/app.component.html" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -138,19 +138,19 @@ Each feature module acts as a doorway via the router. In the `AppRoutingModule`,
|
||||
In `AppRoutingModule`, update the `routes` array with the following:
|
||||
|
||||
|
||||
<code-example path="lazy-loading-ngmodules/src/app/app-routing.module.ts" region="const-routes" title="src/app/app-routing.module.ts" linenums="false">
|
||||
<code-example path="lazy-loading-ngmodules/src/app/app-routing.module.ts" region="const-routes" header="src/app/app-routing.module.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
||||
The import statements stay the same. The first two paths are the routes to the `CustomersModule` and the `OrdersModule` respectively. Notice that the lazy loading syntax uses `loadChildren` followed by a string that is the path to the module, a hash mark or `#`, and the module’s class name.
|
||||
The import statements stay the same. The first two paths are the routes to the `CustomersModule` and the `OrdersModule` respectively. Notice that the lazy loading syntax uses `loadChildren` followed by a string that is the relative path to the module, a hash mark or `#`, and the module’s class name.
|
||||
|
||||
### Inside the feature module
|
||||
|
||||
Next, take a look at `customers.module.ts`. If you’re using the CLI and following the steps outlined in this page, you don’t have to do anything here. The feature module is like a connector between the `AppRoutingModule` and the feature routing module. The `AppRoutingModule` imports the feature module, `CustomersModule`, and `CustomersModule` in turn imports the `CustomersRoutingModule`.
|
||||
|
||||
|
||||
<code-example path="lazy-loading-ngmodules/src/app/customers/customers.module.ts" region="customers-module" title="src/app/customers/customers.module.ts" linenums="false">
|
||||
<code-example path="lazy-loading-ngmodules/src/app/customers/customers.module.ts" region="customers-module" header="src/app/customers/customers.module.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -163,7 +163,7 @@ The `customers.module.ts` file imports the `CustomersRoutingModule` and `Custome
|
||||
|
||||
The next step is in `customers-routing.module.ts`. First, import the component at the top of the file with the other JavaScript import statements. Then, add the route to `CustomerListComponent`.
|
||||
|
||||
<code-example path="lazy-loading-ngmodules/src/app/customers/customers-routing.module.ts" region="customers-routing-module" title="src/app/customers/customers-routing.module.ts" linenums="false">
|
||||
<code-example path="lazy-loading-ngmodules/src/app/customers/customers-routing.module.ts" region="customers-routing-module" header="src/app/customers/customers-routing.module.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -172,7 +172,7 @@ Notice that the `path` is set to an empty string. This is because the path in `A
|
||||
|
||||
Repeat this last step of importing the `OrdersListComponent` and configuring the Routes array for the `orders-routing.module.ts`:
|
||||
|
||||
<code-example path="lazy-loading-ngmodules/src/app/orders/orders-routing.module.ts" region="orders-routing-module-detail" title="src/app/orders/orders-routing.module.ts (excerpt)" linenums="false">
|
||||
<code-example path="lazy-loading-ngmodules/src/app/orders/orders-routing.module.ts" region="orders-routing-module-detail" header="src/app/orders/orders-routing.module.ts (excerpt)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -23,7 +23,7 @@ Each interface has a single hook method whose name is the interface name prefixe
|
||||
For example, the `OnInit` interface has a hook method named `ngOnInit()`
|
||||
that Angular calls shortly after creating the component:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/peek-a-boo.component.ts" region="ngOnInit" title="peek-a-boo.component.ts (excerpt)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/peek-a-boo.component.ts" region="ngOnInit" header="peek-a-boo.component.ts (excerpt)" linenums="false"></code-example>
|
||||
|
||||
No directive or component will implement all of the lifecycle hooks.
|
||||
Angular only calls a directive/component hook method *if it is defined*.
|
||||
@ -339,13 +339,13 @@ The heroes will never know they're being watched.
|
||||
The sneaky spy directive is simple, consisting almost entirely of `ngOnInit()` and `ngOnDestroy()` hooks
|
||||
that log messages to the parent via an injected `LoggerService`.
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/spy.directive.ts" region="spy-directive" title="src/app/spy.directive.ts" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/spy.directive.ts" region="spy-directive" header="src/app/spy.directive.ts" linenums="false"></code-example>
|
||||
|
||||
You can apply the spy to any native or component element and it'll be initialized and destroyed
|
||||
at the same time as that element.
|
||||
Here it is attached to the repeated hero `<div>`:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/spy.component.html" region="template" title="src/app/spy.component.html" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/spy.component.html" region="template" header="src/app/spy.component.html" linenums="false"></code-example>
|
||||
|
||||
Each spy's birth and death marks the birth and death of the attached hero `<div>`
|
||||
with an entry in the *Hook Log* as seen here:
|
||||
@ -425,7 +425,7 @@ You risk memory leaks if you neglect to do so.
|
||||
Angular calls its `ngOnChanges()` method whenever it detects changes to ***input properties*** of the component (or directive).
|
||||
This example monitors the `OnChanges` hook.
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/on-changes.component.ts" region="ng-on-changes" title="on-changes.component.ts (excerpt)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/on-changes.component.ts" region="ng-on-changes" header="on-changes.component.ts (excerpt)" linenums="false"></code-example>
|
||||
|
||||
The `ngOnChanges()` method takes an object that maps each changed property name to a
|
||||
[SimpleChange](api/core/SimpleChange) object holding the current and previous property values.
|
||||
@ -433,11 +433,11 @@ This hook iterates over the changed properties and logs them.
|
||||
|
||||
The example component, `OnChangesComponent`, has two input properties: `hero` and `power`.
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/on-changes.component.ts" region="inputs" title="src/app/on-changes.component.ts" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/on-changes.component.ts" region="inputs" header="src/app/on-changes.component.ts" linenums="false"></code-example>
|
||||
|
||||
The host `OnChangesParentComponent` binds to them like this:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/on-changes-parent.component.html" region="on-changes" title="src/app/on-changes-parent.component.html"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/on-changes-parent.component.html" region="on-changes" header="src/app/on-changes-parent.component.html"></code-example>
|
||||
|
||||
Here's the sample in action as the user makes changes.
|
||||
|
||||
@ -468,7 +468,7 @@ Use the `DoCheck` hook to detect and act upon changes that Angular doesn't catch
|
||||
|
||||
The *DoCheck* sample extends the *OnChanges* sample with the following `ngDoCheck()` hook:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/do-check.component.ts" region="ng-do-check" title="DoCheckComponent (ngDoCheck)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/do-check.component.ts" region="ng-do-check" header="DoCheckComponent (ngDoCheck)" linenums="false"></code-example>
|
||||
|
||||
This code inspects certain _values of interest_, capturing and comparing their current state against previous values.
|
||||
It writes a special message to the log when there are no substantive changes to the `hero` or the `power`
|
||||
@ -497,25 +497,25 @@ The *AfterView* sample explores the `AfterViewInit()` and `AfterViewChecked()` h
|
||||
|
||||
Here's a child view that displays a hero's name in an `<input>`:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="child-view" title="ChildComponent" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="child-view" header="ChildComponent" linenums="false"></code-example>
|
||||
|
||||
The `AfterViewComponent` displays this child view *within its template*:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="template" title="AfterViewComponent (template)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="template" header="AfterViewComponent (template)" linenums="false"></code-example>
|
||||
|
||||
The following hooks take action based on changing values *within the child view*,
|
||||
which can only be reached by querying for the child view via the property decorated with
|
||||
[@ViewChild](api/core/ViewChild).
|
||||
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="hooks" title="AfterViewComponent (class excerpts)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="hooks" header="AfterViewComponent (class excerpts)" linenums="false"></code-example>
|
||||
|
||||
{@a wait-a-tick}
|
||||
|
||||
### Abide by the unidirectional data flow rule
|
||||
The `doSomething()` method updates the screen when the hero name exceeds 10 characters.
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="do-something" title="AfterViewComponent (doSomething)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-view.component.ts" region="do-something" header="AfterViewComponent (doSomething)" linenums="false"></code-example>
|
||||
|
||||
Why does the `doSomething()` method wait a tick before updating `comment`?
|
||||
|
||||
@ -559,7 +559,7 @@ Consider this variation on the [previous _AfterView_](guide/lifecycle-hooks#afte
|
||||
This time, instead of including the child view within the template, it imports the content from
|
||||
the `AfterContentComponent`'s parent. Here's the parent's template:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-content.component.ts" region="parent-template" title="AfterContentParentComponent (template excerpt)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-content.component.ts" region="parent-template" header="AfterContentParentComponent (template excerpt)" linenums="false"></code-example>
|
||||
|
||||
Notice that the `<app-child>` tag is tucked between the `<after-content>` tags.
|
||||
Never put content between a component's element tags *unless you intend to project that content
|
||||
@ -567,7 +567,7 @@ into the component*.
|
||||
|
||||
Now look at the component's template:
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-content.component.ts" region="template" title="AfterContentComponent (template)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-content.component.ts" region="template" header="AfterContentComponent (template)" linenums="false"></code-example>
|
||||
|
||||
The `<ng-content>` tag is a *placeholder* for the external content.
|
||||
It tells Angular where to insert that content.
|
||||
@ -603,7 +603,7 @@ The following *AfterContent* hooks take action based on changing values in a *co
|
||||
which can only be reached by querying for them via the property decorated with
|
||||
[@ContentChild](api/core/ContentChild).
|
||||
|
||||
<code-example path="lifecycle-hooks/src/app/after-content.component.ts" region="hooks" title="AfterContentComponent (class excerpts)" linenums="false"></code-example>
|
||||
<code-example path="lifecycle-hooks/src/app/after-content.component.ts" region="hooks" header="AfterContentComponent (class excerpts)" linenums="false"></code-example>
|
||||
|
||||
{@a no-unidirectional-flow-worries}
|
||||
|
||||
|
@ -480,7 +480,7 @@ You can throw an error or take other remedial action.
|
||||
Certain NgModules, such as `BrowserModule`, implement such a guard.
|
||||
Here is a custom constructor for an NgModule called `CoreModule`.
|
||||
|
||||
<code-example path="ngmodule-faq/src/app/core/core.module.ts" region="ctor" title="src/app/core/core.module.ts (Constructor)" linenums="false">
|
||||
<code-example path="ngmodule-faq/src/app/core/core.module.ts" region="ctor" header="src/app/core/core.module.ts (Constructor)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<hr/>
|
||||
|
@ -29,7 +29,7 @@ JavaScript modules help you namespace, preventing accidental global variables.
|
||||
<!-- KW-- perMisko: let's discuss. This does not answer the question why it is different. Also, last sentence is confusing.-->
|
||||
NgModules are classes decorated with `@NgModule`. The `@NgModule` decorator’s `imports` array tells Angular what other NgModules the current module needs. The modules in the `imports` array are different than JavaScript modules because they are NgModules rather than regular JavaScript modules. Classes with an `@NgModule` decorator are by convention kept in their own files, but what makes them an `NgModule` isn’t being in their own file, like JavaScript modules; it’s the presence of `@NgModule` and its metadata.
|
||||
|
||||
The `AppModule` generated from the Angular CLI demonstrates both kinds of modules in action:
|
||||
The `AppModule` generated from the [Angular CLI](cli) demonstrates both kinds of modules in action:
|
||||
|
||||
```typescript
|
||||
/* These are JavaScript import statements. Angular doesn’t know anything about these. */
|
||||
|
@ -57,9 +57,9 @@ You then import these modules into the root module.
|
||||
|
||||
## The basic NgModule
|
||||
|
||||
The CLI generates the following basic app module when creating a new app.
|
||||
The [Angular CLI](cli) generates the following basic app module when creating a new app.
|
||||
|
||||
<code-example path="bootstrapping/src/app/app.module.ts" region="whole-ngmodule" title="src/app/app.module.ts" linenums="false">
|
||||
<code-example path="bootstrapping/src/app/app.module.ts" region="whole-ngmodule" header="src/app/app.module.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
At the top are the import statements. The next section is where you configure the `@NgModule` by stating what components and directives belong to it (`declarations`) as well as which other modules it uses (`imports`). This page builds on [Bootstrapping](guide/bootstrapping), which covers the structure of an NgModule in detail. If you need more information on the structure of an `@NgModule`, be sure to read [Bootstrapping](guide/bootstrapping).
|
||||
|
@ -1,173 +1,141 @@
|
||||
# Npm Packages
|
||||
# Workspace npm dependencies
|
||||
|
||||
The [**Angular CLI**](https://cli.angular.io/), Angular applications, and Angular itself depend upon features and functionality provided by libraries that are available as [**npm**](https://docs.npmjs.com/) packages.
|
||||
The Angular Framework, Angular CLI, and components used by Angular applicatins are packaged as [npm packages](https://docs.npmjs.com/getting-started/what-is-npm "What is npm?") and distributed via the [npm registry](https://docs.npmjs.com/).
|
||||
|
||||
You can download and install these npm packages with the [**npm client**](https://docs.npmjs.com/cli/install), which runs as a Node.js® application.
|
||||
You can download and install these npm packages by using the [npm CLI client](https://docs.npmjs.com/cli/install), which is installed with and runs as a [Node.js®](https://nodejs.org "Nodejs.org") application. By default, the Angular CLI uses the npm client.
|
||||
|
||||
Alternatively, you can use the [yarn client](https://yarnpkg.com/) for downloading and installing npm packages.
|
||||
|
||||
The [**yarn client**](https://yarnpkg.com/en/) is a popular alternative for downloading and installing npm packages.
|
||||
The Angular CLI uses `yarn` by default to install npm packages when you create a new project.
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Node.js and npm are essential to Angular development.
|
||||
See [Getting Started](guide/quickstart#prerequisites) for information about the required versions and installation of Node.js and npm.
|
||||
|
||||
[Get them now](https://docs.npmjs.com/getting-started/installing-node "Installing Node.js and updating npm")
|
||||
if they're not already installed on your machine.
|
||||
|
||||
**Verify that you are running Node.js `v8.x` or higher and npm `5.x` or higher**
|
||||
by running the commands `node -v` and `npm -v` in a terminal/console window.
|
||||
Older versions produce errors.
|
||||
|
||||
Consider using [nvm](https://github.com/creationix/nvm) for managing multiple
|
||||
versions of Node.js and npm. You may need [nvm](https://github.com/creationix/nvm) if
|
||||
you already have projects running on your machine that use other versions of Node.js and npm.
|
||||
If you already have projects running on your machine that use other versions of Node.js and npm, consider using [nvm](https://github.com/creationix/nvm) to manage the multiple versions of Node.js and npm.
|
||||
|
||||
</div>
|
||||
|
||||
## _package.json_
|
||||
|
||||
Both `npm` and `yarn` install packages that are identified in a [**package.json**](https://docs.npmjs.com/files/package.json) file.
|
||||
## `package.json`
|
||||
|
||||
The CLI `ng new` command creates a default `package.json` file for your project.
|
||||
This `package.json` specifies _a starter set of packages_ that work well together and
|
||||
jointly support many common application scenarios.
|
||||
Both `npm` and `yarn` install the packages that are identified in a [`package.json`](https://docs.npmjs.com/files/package.json) file.
|
||||
|
||||
You will add packages to `package.json` as your application evolves.
|
||||
You may even remove some.
|
||||
The CLI command `ng new` creates a `package.json` file when it creates the new workspace.
|
||||
This `package.json` is used by all projects in the workspace, including the initial app project that is created by the CLI when it creates the workspace.
|
||||
|
||||
This guide focuses on the most important packages in the starter set.
|
||||
Initially, this `package.json` includes _a starter set of packages_, some of which are required by Angular and others that support common application scenarios.
|
||||
You add packages to `package.json` as your application evolves.
|
||||
You may even remove some.
|
||||
|
||||
#### *dependencies* and *devDependencies*
|
||||
The `package.json` is organized into two groups of packages:
|
||||
|
||||
The `package.json` includes two sets of packages,
|
||||
[dependencies](guide/npm-packages#dependencies) and [devDependencies](guide/npm-packages#dev-dependencies).
|
||||
* [Dependencies](guide/npm-packages#dependencies) are essential to *running* applications.
|
||||
* [DevDependencies](guide/npm-packages#dev-dependencies) are only necessary to *develop* applications.
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
**Library developers:** By default, the CLI command [`ng generate library`](cli/generate) creates a `package.json` for the new library. That `package.json` is used when publishing the library to npm.
|
||||
For more information, see the CLI wiki page [Library Support](https://github.com/angular/angular-cli/wiki/stories-create-library).
|
||||
</div>
|
||||
|
||||
The *dependencies* are essential to *running* the application.
|
||||
The *devDependencies* are only necessary to *develop* the application.
|
||||
|
||||
{@a dependencies}
|
||||
## Dependencies
|
||||
|
||||
The packages listed in the `dependencies` section of `package.json` are essential to *running* applications.
|
||||
|
||||
## *Dependencies*
|
||||
The `dependencies` section of `package.json` contains:
|
||||
|
||||
* **Angular packages**: Angular core and optional modules; their package names begin `@angular/`.
|
||||
* [**Angular packages**](#angular-packages): Angular core and optional modules; their package names begin `@angular/`.
|
||||
|
||||
* **Support packages**: 3rd party libraries that must be present for Angular apps to run.
|
||||
* [**Support packages**](#support-packages): 3rd party libraries that must be present for Angular apps to run.
|
||||
|
||||
* **Polyfill packages**: Polyfills plug gaps in a browser's JavaScript implementation.
|
||||
* [**Polyfill packages**](#polyfills): Polyfills plug gaps in a browser's JavaScript implementation.
|
||||
|
||||
### Angular Packages
|
||||
To add a new dependency, use the [`ng add`](cli/add) command.
|
||||
|
||||
**@angular/animations**: Angular's animations library makes it easy to define and apply animation effects such as page and list transitions.
|
||||
Read about it in the [Animations guide](guide/animations).
|
||||
{@a angular-packages}
|
||||
### Angular packages
|
||||
|
||||
**@angular/common**: The commonly needed services, pipes, and directives provided by the Angular team.
|
||||
The [`HttpClientModule`](guide/http) is also here, in the '@angular/common/http' subfolder.
|
||||
The following Angular packages are included as dependencies in the default `package.json` file for a new Angular workspace.
|
||||
For a complete list of Angular packages, see the [API reference](http://angular.io/api?type=package).
|
||||
|
||||
**@angular/core**: Critical runtime parts of the framework needed by every application.
|
||||
Includes all metadata decorators, `Component`, `Directive`, dependency injection, and the component lifecycle hooks.
|
||||
Package name | Description
|
||||
---------------------------------------- | --------------------------------------------------
|
||||
[**@angular/animations**](api/animations) | Angular's animations library makes it easy to define and apply animation effects such as page and list transitions. For more information, see the [Animations guide](guide/animations).
|
||||
[**@angular/common**](api/common) | The commonly-needed services, pipes, and directives provided by the Angular team. The [`HttpClientModule`](api/common/http/HttpClientModule) is also here, in the [`@angular/common/http`](api/common/http) subfolder. For more information, see the [HttpClient guide](guide/http).
|
||||
**@angular/compiler** | Angular's template compiler. It understands templates and can convert them to code that makes the application run and render. Typically you don’t interact with the compiler directly; rather, you use it indirectly via `platform-browser-dynamic` when JIT compiling in the browser. For more information, see the [Ahead-of-time Compilation guide](guide/aot-compiler).
|
||||
[**@angular/core**](api/core) | Critical runtime parts of the framework that are needed by every application. Includes all metadata decorators, `Component`, `Directive`, dependency injection, and the component lifecycle hooks.
|
||||
[**@angular/forms**](api/forms) | Support for both [template-driven](guide/forms) and [reactive forms](guide/reactive-forms). For information about choosing the best forms approach for your app, see [Introduction to forms](guide/forms-overview).
|
||||
[**@angular/http**](api/http) | Angular's legacy HTTP client, which was deprecated in version 5.0 in favor of [@angular/common/http](api/common/http).
|
||||
[**@angular/<br />platform‑browser**](api/platform-browser) | Everything DOM and browser related, especially the pieces that help render into the DOM. This package also includes the `bootstrapModuleFactory()` method for bootstrapping applications for production builds that pre-compile with [AOT](guide/aot-compiler).
|
||||
[**@angular/<br />platform‑browser‑dynamic**](api/platform-browser-dynamic) | Includes [providers](api/core/Provider) and methods to compile and run the app on the client using the [JIT compiler](guide/aot-compiler).
|
||||
[**@angular/router**](api/router) | The router module navigates among your app pages when the browser URL changes. For more information, see [Routing and Navigation](guide/router).
|
||||
|
||||
**@angular/compiler**: Angular's *Template Compiler*.
|
||||
It understands templates and can convert them to code that makes the application run and render.
|
||||
Typically you don’t interact with the compiler directly; rather, you use it indirectly via `platform-browser-dynamic` when [JIT compiling](guide/aot-compiler) in the browser.
|
||||
|
||||
**@angular/forms**: support for both [template-driven](guide/forms) and [reactive forms](guide/reactive-forms).
|
||||
{@a support-packages}
|
||||
### Support packages
|
||||
|
||||
**@angular/http**: Angular's old, deprecated, HTTP client.
|
||||
The following support packages are included as dependencies in the default `package.json` file for a new Angular workspace.
|
||||
|
||||
**@angular/platform-browser**: Everything DOM and browser related, especially
|
||||
the pieces that help render into the DOM.
|
||||
This package also includes the `bootstrapModuleFactory()` method
|
||||
for bootstrapping applications for production builds that pre-compile with [AOT](guide/aot-compiler).
|
||||
|
||||
**@angular/platform-browser-dynamic**: Includes [Providers](api/core/Provider)
|
||||
and methods to compile and run the app on the client
|
||||
using the [JIT compiler](guide/aot-compiler).
|
||||
Package name | Description
|
||||
---------------------------------------- | --------------------------------------------------
|
||||
[**rxjs**](https://github.com/ReactiveX/rxjs) | Many Angular APIs return [_observables_](guide/glossary#observable). RxJS is an implementation of the proposed [Observables specification](https://github.com/zenparsing/es-observable) currently before the [TC39](http://www.ecma-international.org/memento/TC39.htm) committee, which determines standards for the JavaScript language.
|
||||
[**zone.js**](https://github.com/angular/zone.js) | Angular relies on zone.js to run Angular's change detection processes when native JavaScript operations raise events. Zone.js is an implementation of a [specification](https://gist.github.com/mhevery/63fdcdf7c65886051d55) currently before the [TC39](http://www.ecma-international.org/memento/TC39.htm) committee that determines standards for the JavaScript language.
|
||||
|
||||
**@angular/router**: The [router module](/guide/router) navigates among your app pages when the browser URL changes.
|
||||
|
||||
**@angular/upgrade**: Set of utilities for upgrading AngularJS applications to Angular.
|
||||
|
||||
{@a polyfills}
|
||||
|
||||
### Polyfill packages
|
||||
|
||||
Many browsers lack native support for some features in the latest HTML standards,
|
||||
features that Angular requires.
|
||||
"[Polyfills](https://en.wikipedia.org/wiki/Polyfill)" can emulate the missing features.
|
||||
[_Polyfills_](https://en.wikipedia.org/wiki/Polyfill) can emulate the missing features.
|
||||
The [Browser Support](guide/browser-support) guide explains which browsers need polyfills and
|
||||
how you can add them.
|
||||
|
||||
The default `package.json` installs the **[core-js](https://github.com/zloirock/core-js)** package
|
||||
The `package.json` for a new Angular workspace installs the [core-js](https://github.com/zloirock/core-js) package,
|
||||
which polyfills missing features for several popular browser.
|
||||
|
||||
### Support packages
|
||||
|
||||
**[rxjs](https://github.com/benlesh/RxJS)**: Many Angular APIs return _observables_. RxJS is an implementation of the proposed [Observables specification](https://github.com/zenparsing/es-observable) currently before the
|
||||
[TC39](http://www.ecma-international.org/memento/TC39.htm) committee that determines standards for the JavaScript language.
|
||||
|
||||
|
||||
**[zone.js](https://github.com/angular/zone.js)**: Angular relies on zone.js to run Angular's change detection processes when native JavaScript operations raise events. Zone.js is an implementation of a [specification](https://gist.github.com/mhevery/63fdcdf7c65886051d55) currently before the
|
||||
[TC39](http://www.ecma-international.org/memento/TC39.htm) committee that determines standards for the JavaScript language.
|
||||
|
||||
|
||||
{@a dev-dependencies}
|
||||
|
||||
## *DevDependencies*
|
||||
## DevDependencies
|
||||
|
||||
The packages listed in the *devDependencies* section of the `package.json` help you develop the application on your local machine.
|
||||
The packages listed in the `devDependencies` section of `package.json` help you develop the application on your local machine. You don't deploy them with the production application.
|
||||
|
||||
You don't deploy them with the production application although there is no harm in doing so.
|
||||
To add a new `devDependency`, use either one of the following commands:
|
||||
|
||||
**[@angular/cli](https://github.com/angular/angular-cli/)**: The Angular CLI tools.
|
||||
<code-example language="sh" class="code-shell">
|
||||
npm install --dev <package-name>
|
||||
</code-example>
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
yarn add --dev <package-name>
|
||||
</code-example>
|
||||
|
||||
The following `devDependencies` are provided in the default `package.json` file for a new Angular workspace.
|
||||
|
||||
|
||||
**[@angular/compiler-cli](https://github.com/angular/angular/blob/master/packages/compiler-cli/README.md)**: The Angular compiler, which is invoked by the Angular CLI's `build` and `serve` commands.
|
||||
Package name | Description
|
||||
---------------------------------------- | -----------------------------------
|
||||
[**@angular‑devkit/<br />build‑angular**](https://github.com/angular/angular-cli/) | The Angular build tools.
|
||||
[**@angular/cli**](https://github.com/angular/angular-cli/) | The Angular CLI tools.
|
||||
**@angular/<br />compiler‑cli** | The Angular compiler, which is invoked by the Angular CLI's `ng build` and `ng serve` commands.
|
||||
**@angular/<br />language‑service** | The [Angular language service](guide/language-service) analyzes component templates and provides type and error information that TypeScript-aware editors can use to improve the developer's experience. For example, see the [Angular language service extension for VS Code](https://marketplace.visualstudio.com/items?itemName=Angular.ng-template).
|
||||
**@types/... ** | TypeScript definition files for 3rd party libraries such as Jasmine and Node.js.
|
||||
[**codelyzer**](https://www.npmjs.com/package/codelyzer) | A linter for Angular apps whose rules conform to the Angular [style guide](guide/styleguide).
|
||||
**jasmine/... ** | Packages to support the [Jasmine](https://jasmine.github.io/) test library.
|
||||
**karma/... ** | Packages to support the [karma](https://www.npmjs.com/package/karma) test runner.
|
||||
[**protractor**](https://www.npmjs.com/package/protractor) | An end-to-end (e2e) framework for Angular apps. Built on top of [WebDriverJS](https://github.com/SeleniumHQ/selenium/wiki/WebDriverJs).
|
||||
[**ts-node**](https://www.npmjs.com/package/ts-node) | TypeScript execution environment and REPL for Node.js.
|
||||
[**tslint**](https://www.npmjs.com/package/tslint) | A static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors.
|
||||
[**typescript**](https://www.npmjs.com/package/typescript) | The TypeScript language server, including the *tsc* TypeScript compiler.
|
||||
|
||||
|
||||
**[@angular/language-service](https://github.com/angular/angular-cli/)**: The Angular language service analyzes component templates and provides type and error information that TypeScript-aware editors can use to improve the developer's experience.
|
||||
For example, see the [Angular language service extension for VS Code](https://marketplace.visualstudio.com/items?itemName=Angular.ng-template)
|
||||
## Related information
|
||||
|
||||
|
||||
**@types/... **: TypeScript definition files for 3rd party libraries such as Jasmine and Node.js.
|
||||
|
||||
|
||||
**[codelyzer](https://www.npmjs.com/package/codelyzer)**: A linter for Angular apps whose rules conform to the Angular [style guide](guide/styleguide).
|
||||
|
||||
|
||||
**jasmine/... **: packages to support the [Jasmine](https://jasmine.github.io/) test library.
|
||||
|
||||
|
||||
**karma/... **: packages to support the [karma](https://www.npmjs.com/package/karma) test runner.
|
||||
|
||||
|
||||
**[protractor](https://www.npmjs.com/package/protractor)**: an end-to-end (e2e) framework for Angular apps.
|
||||
Built on top of [WebDriverJS](https://github.com/SeleniumHQ/selenium/wiki/WebDriverJs).
|
||||
|
||||
|
||||
**[ts-node](https://www.npmjs.com/package/ts-node)**: TypeScript execution environment and REPL for Node.js.
|
||||
|
||||
|
||||
**[tslint](https://www.npmjs.com/package/tslint)**: a static analysis tool that checks TypeScript code for readability, maintainability, and functionality errors.
|
||||
|
||||
|
||||
**[typescript](https://www.npmjs.com/package/typescript)**:
|
||||
the TypeScript language server, including the *tsc* TypeScript compiler.
|
||||
|
||||
|
||||
## So many packages! So many files!
|
||||
|
||||
The default `package.json` installs more packages than you'll need for your project.
|
||||
|
||||
A given package may contain tens, hundreds, even thousands of files,
|
||||
all of them in your local machine's `node_modules` directory.
|
||||
The sheer volume of files is intimidating,
|
||||
|
||||
You can remove packages that you don't need but how can you be sure that you won't need it?
|
||||
As a practical matter, it's better to install a package you don't need than worry about it.
|
||||
Extra packages and package files on your local development machine are harmless.
|
||||
|
||||
By default the Angular CLI build process bundles into a single file just the few "vendor" library files that your application actually needs.
|
||||
The browser downloads this bundle, not the original package files.
|
||||
|
||||
See the [Deployment](guide/deployment) to learn more.
|
||||
For information about how the Angular CLI handles packages see the following guides:
|
||||
|
||||
* [Building and serving](guide/build) describes how packages come together to create a development build.
|
||||
* [Deployment](guide/deployment) describes how packages come together to create a production build.
|
@ -16,7 +16,7 @@ A good example of usage can be found on the [EventEmitter](https://angular.io/ap
|
||||
|
||||
Here is the component definition:
|
||||
|
||||
<code-example path="observables-in-angular/src/main.ts" title="EventEmitter" region="eventemitter"></code-example>
|
||||
<code-example path="observables-in-angular/src/main.ts" header="EventEmitter" region="eventemitter"></code-example>
|
||||
|
||||
## HTTP
|
||||
Angular’s `HttpClient` returns observables from HTTP method calls. For instance, `http.get(‘/api’)` returns an observable. This provides several advantages over promise-based HTTP APIs:
|
||||
@ -32,20 +32,20 @@ The [AsyncPipe](https://angular.io/api/common/AsyncPipe) subscribes to an observ
|
||||
|
||||
The following example binds the `time` observable to the component's view. The observable continuously updates the view with the current time.
|
||||
|
||||
<code-example path="observables-in-angular/src/main.ts" title="Using async pipe" region="pipe"></code-example>
|
||||
<code-example path="observables-in-angular/src/main.ts" header="Using async pipe" region="pipe"></code-example>
|
||||
|
||||
## Router
|
||||
|
||||
[`Router.events`](https://angular.io/api/router/Router#events) provides events as observables. You can use the `filter()` operator from RxJS to look for events of interest, and subscribe to them in order to make decisions based on the sequence of events in the navigation process. Here's an example:
|
||||
|
||||
<code-example path="observables-in-angular/src/main.ts" title="Router events" region="router"></code-example>
|
||||
<code-example path="observables-in-angular/src/main.ts" header="Router events" region="router"></code-example>
|
||||
|
||||
The [ActivatedRoute](https://angular.io/api/router/ActivatedRoute) is an injected router service that makes use of observables to get information about a route path and parameters. For example, `ActivateRoute.url` contains an observable that reports the route path or paths. Here's an example:
|
||||
|
||||
<code-example path="observables-in-angular/src/main.ts" title="ActivatedRoute" region="activated_route"></code-example>
|
||||
<code-example path="observables-in-angular/src/main.ts" header="ActivatedRoute" region="activated_route"></code-example>
|
||||
|
||||
## Reactive forms
|
||||
|
||||
Reactive forms have properties that use observables to monitor form control values. The [`FormControl`](https://angular.io/api/forms/FormControl) properties `valueChanges` and `statusChanges` contain observables that raise change events. Subscribing to an observable form-control property is a way of triggering application logic within the component class. For example:
|
||||
|
||||
<code-example path="observables-in-angular/src/main.ts" title="Reactive forms" region="forms"></code-example>
|
||||
<code-example path="observables-in-angular/src/main.ts" header="Reactive forms" region="forms"></code-example>
|
||||
|
@ -17,7 +17,7 @@ To execute the observable you have created and begin receiving notifications, yo
|
||||
|
||||
Here's an example that demonstrates the basic usage model by showing how an observable could be used to provide geolocation updates.
|
||||
|
||||
<code-example path="observables/src/geolocation.ts" title="Observe geolocation updates"></code-example>
|
||||
<code-example path="observables/src/geolocation.ts" header="Observe geolocation updates"></code-example>
|
||||
|
||||
## Defining observers
|
||||
|
||||
@ -49,11 +49,11 @@ Here's an example of creating and subscribing to a simple observable, with an ob
|
||||
<code-example
|
||||
path="observables/src/subscribing.ts"
|
||||
region="observer"
|
||||
title="Subscribe using observer"></code-example>
|
||||
header="Subscribe using observer"></code-example>
|
||||
|
||||
Alternatively, the `subscribe()` method can accept callback function definitions in line, for `next`, `error`, and `complete` handlers. For example, the following `subscribe()` call is the same as the one that specifies the predefined observer:
|
||||
|
||||
<code-example path="observables/src/subscribing.ts" region="sub_fn" title="Subscribe with positional arguments"></code-example>
|
||||
<code-example path="observables/src/subscribing.ts" region="sub_fn" header="Subscribe with positional arguments"></code-example>
|
||||
|
||||
In either case, a `next` handler is required. The `error` and `complete` handlers are optional.
|
||||
|
||||
@ -65,15 +65,15 @@ Use the `Observable` constructor to create an observable stream of any type. The
|
||||
|
||||
For example, to create an observable equivalent to the `of(1, 2, 3)` above, you could do something like this:
|
||||
|
||||
<code-example path="observables/src/creating.ts" region="subscriber" title="Create observable with constructor"></code-example>
|
||||
<code-example path="observables/src/creating.ts" region="subscriber" header="Create observable with constructor"></code-example>
|
||||
|
||||
To take this example a little further, we can create an observable that publishes events. In this example, the subscriber function is defined inline.
|
||||
|
||||
<code-example path="observables/src/creating.ts" region="fromevent" title="Create with custom fromEvent function"></code-example>
|
||||
<code-example path="observables/src/creating.ts" region="fromevent" header="Create with custom fromEvent function"></code-example>
|
||||
|
||||
Now you can use this function to create an observable that publishes keydown events:
|
||||
|
||||
<code-example path="observables/src/creating.ts" region="fromevent_use" title="Use custom fromEvent function"></code-example>
|
||||
<code-example path="observables/src/creating.ts" region="fromevent_use" header="Use custom fromEvent function"></code-example>
|
||||
|
||||
## Multicasting
|
||||
|
||||
@ -87,15 +87,15 @@ When creating an observable you should determine how you want that observable to
|
||||
|
||||
Let’s look at an example that counts from 1 to 3, with a one-second delay after each number emitted.
|
||||
|
||||
<code-example path="observables/src/multicasting.ts" region="delay_sequence" title="Create a delayed sequence"></code-example>
|
||||
<code-example path="observables/src/multicasting.ts" region="delay_sequence" header="Create a delayed sequence"></code-example>
|
||||
|
||||
Notice that if you subscribe twice, there will be two separate streams, each emitting values every second. It looks something like this:
|
||||
|
||||
<code-example path="observables/src/multicasting.ts" region="subscribe_twice" title="Two subscriptions"></code-example>
|
||||
<code-example path="observables/src/multicasting.ts" region="subscribe_twice" header="Two subscriptions"></code-example>
|
||||
|
||||
Changing the observable to be multicasting could look something like this:
|
||||
|
||||
<code-example path="observables/src/multicasting.ts" region="multicast_sequence" title="Create a multicast subscriber"></code-example>
|
||||
<code-example path="observables/src/multicasting.ts" region="multicast_sequence" header="Create a multicast subscriber"></code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
Multicasting observables take a bit more setup, but they can be useful for certain applications. Later we will look at tools that simplify the process of multicasting, allowing you to take any observable and make it multicasting.
|
||||
|
@ -26,7 +26,7 @@ In this page, you'll use pipes to transform a component's birthday property into
|
||||
a human-friendly date.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/hero-birthday1.component.ts" title="src/app/hero-birthday1.component.ts" linenums="false">
|
||||
<code-example path="pipes/src/app/hero-birthday1.component.ts" header="src/app/hero-birthday1.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -35,7 +35,7 @@ a human-friendly date.
|
||||
Focus on the component's template.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/app.component.html" region="hero-birthday-template" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="pipes/src/app/app.component.html" region="hero-birthday-template" header="src/app/app.component.html" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -79,7 +79,7 @@ Modify the birthday template to give the date pipe a format parameter.
|
||||
After formatting the hero's April 15th birthday, it renders as **<samp>04/15/88</samp>**:
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/app.component.html" region="format-birthday" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="pipes/src/app/app.component.html" region="format-birthday" header="src/app/app.component.html" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -95,7 +95,7 @@ Write a second component that *binds* the pipe's format parameter
|
||||
to the component's `format` property. Here's the template for that component:
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/hero-birthday2.component.ts" region="template" title="src/app/hero-birthday2.component.ts (template)" linenums="false">
|
||||
<code-example path="pipes/src/app/hero-birthday2.component.ts" region="template" header="src/app/hero-birthday2.component.ts (template)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -106,7 +106,7 @@ That method toggles the component's `format` property between a short form
|
||||
(`'shortDate'`) and a longer form (`'fullDate'`).
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/hero-birthday2.component.ts" region="class" title="src/app/hero-birthday2.component.ts (class)" linenums="false">
|
||||
<code-example path="pipes/src/app/hero-birthday2.component.ts" region="class" header="src/app/hero-birthday2.component.ts (class)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -143,7 +143,7 @@ the birthday is chained to the `DatePipe` and on to the `UpperCasePipe`.
|
||||
The birthday displays as **<samp>APR 15, 1988</samp>**.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/app.component.html" region="chained-birthday" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="pipes/src/app/app.component.html" region="chained-birthday" header="src/app/app.component.html" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -153,7 +153,7 @@ This example—which displays **<samp>FRIDAY, APRIL 15, 1988</samp>**—
|
||||
the same pipes as above, but passes in a parameter to `date` as well.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/app.component.html" region="chained-parameter-birthday" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="pipes/src/app/app.component.html" region="chained-parameter-birthday" header="src/app/app.component.html" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -166,7 +166,7 @@ You can write your own custom pipes.
|
||||
Here's a custom pipe named `ExponentialStrengthPipe` that can boost a hero's powers:
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/exponential-strength.pipe.ts" title="src/app/exponential-strength.pipe.ts" linenums="false">
|
||||
<code-example path="pipes/src/app/exponential-strength.pipe.ts" header="src/app/exponential-strength.pipe.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -200,7 +200,7 @@ Technically, it's optional; Angular looks for and executes the `transform` metho
|
||||
|
||||
Now you need a component to demonstrate the pipe.
|
||||
|
||||
<code-example path="pipes/src/app/power-booster.component.ts" title="src/app/power-booster.component.ts" linenums="false">
|
||||
<code-example path="pipes/src/app/power-booster.component.ts" header="src/app/power-booster.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<figure>
|
||||
@ -223,7 +223,7 @@ Note the following:
|
||||
|
||||
You must register custom pipes.
|
||||
If you don't, Angular reports an error.
|
||||
Angular CLI's generator registers the pipe automatically.
|
||||
The [Angular CLI's](cli) generator registers the pipe automatically.
|
||||
|
||||
|
||||
</div>
|
||||
@ -240,7 +240,7 @@ Upgrade the example to a "Power Boost Calculator" that combines
|
||||
your pipe and two-way data binding with `ngModel`.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/power-boost-calculator.component.ts" title="src/app/power-boost-calculator.component.ts">
|
||||
<code-example path="pipes/src/app/power-boost-calculator.component.ts" header="src/app/power-boost-calculator.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -270,7 +270,7 @@ In the next example, the component uses the default, aggressive change detection
|
||||
its display of every hero in the `heroes` array. Here's the template:
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.component.html" region="template-1" title="src/app/flying-heroes.component.html (v1)" linenums="false">
|
||||
<code-example path="pipes/src/app/flying-heroes.component.html" region="template-1" header="src/app/flying-heroes.component.html (v1)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -278,7 +278,7 @@ its display of every hero in the `heroes` array. Here's the template:
|
||||
|
||||
The companion component class provides heroes, adds heroes into the array, and can reset the array.
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.component.ts" region="v1" title="src/app/flying-heroes.component.ts (v1)" linenums="false">
|
||||
<code-example path="pipes/src/app/flying-heroes.component.ts" region="v1" header="src/app/flying-heroes.component.ts (v1)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -292,7 +292,7 @@ If you added the ability to remove or change a hero, Angular would detect those
|
||||
|
||||
Add a `FlyingHeroesPipe` to the `*ngFor` repeater that filters the list of heroes to just those heroes who can fly.
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.component.html" region="template-flying-heroes" title="src/app/flying-heroes.component.html (flyers)" linenums="false">
|
||||
<code-example path="pipes/src/app/flying-heroes.component.html" region="template-flying-heroes" header="src/app/flying-heroes.component.html (flyers)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -300,7 +300,7 @@ Add a `FlyingHeroesPipe` to the `*ngFor` repeater that filters the list of heroe
|
||||
|
||||
Here's the `FlyingHeroesPipe` implementation, which follows the pattern for custom pipes described earlier.
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.pipe.ts" region="pure" title="src/app/flying-heroes.pipe.ts" linenums="false">
|
||||
<code-example path="pipes/src/app/flying-heroes.pipe.ts" region="pure" header="src/app/flying-heroes.pipe.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -314,7 +314,7 @@ It's just using a different change-detection algorithm that ignores changes to t
|
||||
|
||||
Notice how a hero is added:
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.component.ts" region="push" title="src/app/flying-heroes.component.ts" linenums="false">
|
||||
<code-example path="pipes/src/app/flying-heroes.component.ts" region="push" header="src/app/flying-heroes.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -364,7 +364,7 @@ You make a pipe impure by setting its pure flag to false. You could make the `Fl
|
||||
impure like this:
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.pipe.ts" region="pipe-decorator" title="src/app/flying-heroes.pipe.ts" linenums="false">
|
||||
<code-example path="pipes/src/app/flying-heroes.pipe.ts" region="pipe-decorator" header="src/app/flying-heroes.pipe.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -422,11 +422,11 @@ The complete implementation is as follows:
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="FlyingHeroesImpurePipe" path="pipes/src/app/flying-heroes.pipe.ts" region="impure">
|
||||
<code-pane header="FlyingHeroesImpurePipe" path="pipes/src/app/flying-heroes.pipe.ts" region="impure">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="FlyingHeroesPipe" path="pipes/src/app/flying-heroes.pipe.ts" region="pure">
|
||||
<code-pane header="FlyingHeroesPipe" path="pipes/src/app/flying-heroes.pipe.ts" region="pure">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -440,7 +440,7 @@ The only difference is the `pure` flag in the pipe metadata.
|
||||
This is a good candidate for an impure pipe because the `transform` function is trivial and fast.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes.pipe.ts" linenums="false" title="src/app/flying-heroes.pipe.ts (filter)" region="filter">
|
||||
<code-example path="pipes/src/app/flying-heroes.pipe.ts" linenums="false" header="src/app/flying-heroes.pipe.ts (filter)" region="filter">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -449,7 +449,7 @@ This is a good candidate for an impure pipe because the `transform` function is
|
||||
You can derive a `FlyingHeroesImpureComponent` from `FlyingHeroesComponent`.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/flying-heroes-impure.component.html" linenums="false" title="src/app/flying-heroes-impure.component.html (excerpt)" region="template-flying-heroes">
|
||||
<code-example path="pipes/src/app/flying-heroes-impure.component.html" linenums="false" header="src/app/flying-heroes-impure.component.html (excerpt)" region="template-flying-heroes">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -476,7 +476,7 @@ This next example binds an `Observable` of message strings
|
||||
(`message$`) to a view with the `async` pipe.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/hero-async-message.component.ts" title="src/app/hero-async-message.component.ts">
|
||||
<code-example path="pipes/src/app/hero-async-message.component.ts" header="src/app/hero-async-message.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -499,7 +499,7 @@ In the following code, the pipe only calls the server when the request URL chang
|
||||
The code uses the [Angular http](guide/http) client to retrieve data:
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/fetch-json.pipe.ts" title="src/app/fetch-json.pipe.ts">
|
||||
<code-example path="pipes/src/app/fetch-json.pipe.ts" header="src/app/fetch-json.pipe.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -509,7 +509,7 @@ Now demonstrate it in a harness component whose template defines two bindings to
|
||||
both requesting the heroes from the `heroes.json` file.
|
||||
|
||||
|
||||
<code-example path="pipes/src/app/hero-list.component.ts" title="src/app/hero-list.component.ts">
|
||||
<code-example path="pipes/src/app/hero-list.component.ts" header="src/app/hero-list.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -14,10 +14,10 @@ Observables can simplify the implementation of type-ahead suggestions. Typically
|
||||
|
||||
Writing this in full JavaScript can be quite involved. With observables, you can use a simple series of RxJS operators:
|
||||
|
||||
<code-example path="practical-observable-usage/src/typeahead.ts" title="Typeahead"></code-example>
|
||||
<code-example path="practical-observable-usage/src/typeahead.ts" header="Typeahead"></code-example>
|
||||
|
||||
## Exponential backoff
|
||||
|
||||
Exponential backoff is a technique in which you retry an API after failure, making the time in between retries longer after each consecutive failure, with a maximum number of retries after which the request is considered to have failed. This can be quite complex to implement with promises and other methods of tracking AJAX calls. With observables, it is very easy:
|
||||
|
||||
<code-example path="practical-observable-usage/src/backoff.ts" title="Exponential backoff"></code-example>
|
||||
<code-example path="practical-observable-usage/src/backoff.ts" header="Exponential backoff"></code-example>
|
||||
|
@ -13,7 +13,7 @@ A provider is an instruction to the DI system on how to obtain a value for a dep
|
||||
|
||||
## Providing a service
|
||||
|
||||
If you already have a CLI generated app, create a service using the following CLI command in the root project directory. Replace _User_ with the name of your service.
|
||||
If you already have an app that was created with the [Angular CLI](cli), you can create a service using the [`ng generate`](cli/generate) CLI command in the root project directory. Replace _User_ with the name of your service.
|
||||
|
||||
```sh
|
||||
ng generate service User
|
||||
@ -21,7 +21,7 @@ ng generate service User
|
||||
|
||||
This command creates the following `UserService` skeleton:
|
||||
|
||||
<code-example path="providers/src/app/user.service.0.ts" title="src/app/user.service.0.ts" linenums="false"> </code-example>
|
||||
<code-example path="providers/src/app/user.service.0.ts" header="src/app/user.service.0.ts" linenums="false"> </code-example>
|
||||
|
||||
You can now inject `UserService` anywhere in your application.
|
||||
|
||||
@ -38,15 +38,15 @@ You should always provide your service in the root injector unless there is a ca
|
||||
|
||||
It's also possible to specify that a service should be provided in a particular `@NgModule`. For example, if you don't want `UserService` to be available to applications unless they import a `UserModule` you've created, you can specify that the service should be provided in the module:
|
||||
|
||||
<code-example path="providers/src/app/user.service.1.ts" title="src/app/user.service.1.ts" linenums="false"> </code-example>
|
||||
<code-example path="providers/src/app/user.service.1.ts" header="src/app/user.service.1.ts" linenums="false"> </code-example>
|
||||
|
||||
The example above shows the preferred way to provide a service in a module. This method is preferred because it enables tree-shaking of the service if nothing injects it. If it's not possible to specify in the service which module should provide it, you can also declare a provider for the service within the module:
|
||||
|
||||
<code-example path="providers/src/app/user.module.ts" title="src/app/user.module.ts" linenums="false"> </code-example>
|
||||
<code-example path="providers/src/app/user.module.ts" header="src/app/user.module.ts" linenums="false"> </code-example>
|
||||
|
||||
## Limiting provider scope by lazy loading modules
|
||||
|
||||
In the basic CLI generated app, modules are eagerly loaded which means that they are all loaded when the app launches. Angular uses an injector system to make things available between modules. In an eagerly loaded app, the root application injector makes all of the providers in all of the modules available throughout the app.
|
||||
In the basic CLI-generated app, modules are eagerly loaded which means that they are all loaded when the app launches. Angular uses an injector system to make things available between modules. In an eagerly loaded app, the root application injector makes all of the providers in all of the modules available throughout the app.
|
||||
|
||||
This behavior necessarily changes when you use lazy loading. Lazy loading is when you load modules only when you need them; for example, when routing. They aren’t loaded right away like with eagerly loaded modules. This means that any services listed in their provider arrays aren’t available because the root injector doesn’t know about these modules.
|
||||
|
||||
@ -67,7 +67,7 @@ method is helpful for when you want to eagerly load a module that needs a servic
|
||||
Providing a service in the component limits the service only to that component (other components in
|
||||
the same module can’t access it.)
|
||||
|
||||
<code-example path="providers/src/app/app.component.ts" region="component-providers" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="providers/src/app/app.component.ts" region="component-providers" header="src/app/app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
|
@ -126,13 +126,13 @@ As part of the initial app, the CLI created the first Angular component for you.
|
||||
|
||||
2. Change the `title` property from `'my-app'` to `'My First Angular App'`.
|
||||
|
||||
<code-example path="cli-quickstart/src/app/app.component.ts" region="component" title="src/app/app.component.ts" linenums="false"></code-example>
|
||||
<code-example path="cli-quickstart/src/app/app.component.ts" region="component" header="src/app/app.component.ts" linenums="false"></code-example>
|
||||
|
||||
The browser reloads automatically with the revised title. That's nice, but it could look better.
|
||||
|
||||
3. Open `./src/app/app.component.css` and give the component some style.
|
||||
|
||||
<code-example path="cli-quickstart/src/app/app.component.css" title="src/app/app.component.css" linenums="false"></code-example>
|
||||
<code-example path="cli-quickstart/src/app/app.component.css" header="src/app/app.component.css" linenums="false"></code-example>
|
||||
|
||||
Looking good!
|
||||
|
||||
|
@ -26,7 +26,7 @@ This section describes how to add a single form control. In the example, the use
|
||||
|
||||
To use reactive forms, import `ReactiveFormsModule` from the `@angular/forms` package and add it to your NgModule's `imports` array.
|
||||
|
||||
<code-example path="reactive-forms/src/app/app.module.ts" region="imports" title="src/app/app.module.ts (excerpt)">
|
||||
<code-example path="reactive-forms/src/app/app.module.ts" region="imports" header="src/app/app.module.ts (excerpt)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -42,7 +42,7 @@ Generate a component for the control.
|
||||
|
||||
The `FormControl` class is the basic building block when using reactive forms. To register a single form control, import the `FormControl` class into your component and create a new instance of the form control to save as a class property.
|
||||
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.ts" region="create-control" title="src/app/name-editor/name-editor.component.ts">
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.ts" region="create-control" header="src/app/name-editor/name-editor.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -52,7 +52,7 @@ Use the constructor of `FormControl` to set its initial value, which in this cas
|
||||
|
||||
After you create the control in the component class, you must associate it with a form control element in the template. Update the template with the form control using the `formControl` binding provided by `FormControlDirective` included in `ReactiveFormsModule`.
|
||||
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.html" region="control-binding" linenums="false" title="src/app/name-editor/name-editor.component.html">
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.html" region="control-binding" linenums="false" header="src/app/name-editor/name-editor.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -68,7 +68,7 @@ Using the template binding syntax, the form control is now registered to the `na
|
||||
|
||||
The form control assigned to `name` is displayed when the component is added to a template.
|
||||
|
||||
<code-example path="reactive-forms/src/app/app.component.1.html" region="app-name-editor" linenums="false" title="src/app/app.component.html (name editor)">
|
||||
<code-example path="reactive-forms/src/app/app.component.1.html" region="app-name-editor" linenums="false" header="src/app/app.component.html (name editor)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -92,7 +92,7 @@ You can display the value in these ways:
|
||||
|
||||
The following example shows you how to display the current value using interpolation in the template.
|
||||
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.html" region="display-value" linenums="false" title="src/app/name-editor/name-editor.component.html (control value)">
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.html" region="display-value" linenums="false" header="src/app/name-editor/name-editor.component.html (control value)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -108,13 +108,13 @@ Reactive forms have methods to change a control's value programmatically, which
|
||||
|
||||
The following example adds a method to the component class to update the value of the control to *Nancy* using the `setValue()` method.
|
||||
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.ts" region="update-value" title="src/app/name-editor/name-editor.component.ts (update value)">
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.ts" region="update-value" header="src/app/name-editor/name-editor.component.ts (update value)">
|
||||
|
||||
</code-example>
|
||||
|
||||
Update the template with a button to simulate a name update. When you click the **Update Name** button, the value entered in the form control element is reflected as its current value.
|
||||
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.html" region="update-value" linenums="false" title="src/app/name-editor/name-editor.component.html (update value)">
|
||||
<code-example path="reactive-forms/src/app/name-editor/name-editor.component.html" region="update-value" linenums="false" header="src/app/name-editor/name-editor.component.html (update value)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -142,7 +142,7 @@ Generate a `ProfileEditor` component and import the `FormGroup` and `FormControl
|
||||
|
||||
</code-example>
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="imports" title="src/app/profile-editor/profile-editor.component.ts (imports)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="imports" header="src/app/profile-editor/profile-editor.component.ts (imports)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -152,7 +152,7 @@ Create a property in the component class named `profileForm` and set the propert
|
||||
|
||||
For the profile form, add two form control instances with the names `firstName` and `lastName`.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="formgroup" title="src/app/profile-editor/profile-editor.component.ts (form group)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="formgroup" header="src/app/profile-editor/profile-editor.component.ts (form group)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -162,7 +162,7 @@ The individual form controls are now collected within a group. A `FormGroup` ins
|
||||
|
||||
A form group tracks the status and changes for each of its controls, so if one of the controls changes, the parent control also emits a new status or value change. The model for the group is maintained from its members. After you define the model, you must update the template to reflect the model in the view.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.html" region="formgroup" linenums="false" title="src/app/profile-editor/profile-editor.component.html (template form group)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.html" region="formgroup" linenums="false" header="src/app/profile-editor/profile-editor.component.html (template form group)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -174,13 +174,13 @@ The `ProfileEditor` component accepts input from the user, but in a real scenari
|
||||
|
||||
Add an `ngSubmit` event listener to the `form` tag with the `onSubmit()` callback method.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="ng-submit" linenums="false" title="src/app/profile-editor/profile-editor.component.html (submit event)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="ng-submit" linenums="false" header="src/app/profile-editor/profile-editor.component.html (submit event)">
|
||||
|
||||
</code-example>
|
||||
|
||||
The `onSubmit()` method in the `ProfileEditor` component captures the current value of `profileForm`. Use `EventEmitter` to keep the form encapsulated and to provide the form value outside the component. The following example uses `console.warn` to log a message to the browser console.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="on-submit" title="src/app/profile-editor/profile-editor.component.ts (submit method)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="on-submit" header="src/app/profile-editor/profile-editor.component.ts (submit method)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -188,7 +188,7 @@ The `submit` event is emitted by the `form` tag using the native DOM event. You
|
||||
|
||||
Use a `button` element to add a button to the bottom of the form to trigger the form submission.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="submit-button" linenums="false" title="src/app/profile-editor/profile-editor.component.html (submit button)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="submit-button" linenums="false" header="src/app/profile-editor/profile-editor.component.html (submit button)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -202,7 +202,7 @@ Use a `button` element to add a button to the bottom of the form to trigger the
|
||||
|
||||
To display the `ProfileEditor` component that contains the form, add it to a component template.
|
||||
|
||||
<code-example path="reactive-forms/src/app/app.component.1.html" region="app-profile-editor" linenums="false" title="src/app/app.component.html (profile editor)">
|
||||
<code-example path="reactive-forms/src/app/app.component.1.html" region="app-profile-editor" linenums="false" header="src/app/app.component.html (profile editor)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -220,7 +220,7 @@ When building complex forms, managing the different areas of information is easi
|
||||
|
||||
An address is a good example of information that can be grouped together. Form groups can accept both form control and form group instances as children. This makes composing complex form models easier to maintain and logically group together. To create a nested group in `profileForm`, add a nested `address` element to the form group instance.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="nested-formgroup" linenums="false" title="src/app/profile-editor/profile-editor.component.ts (nested form group)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="nested-formgroup" linenums="false" header="src/app/profile-editor/profile-editor.component.ts (nested form group)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -232,7 +232,7 @@ After you update the model in the component class, update the template to connec
|
||||
|
||||
Add the `address` form group containing the `firstName` and `lastName` fields to the `ProfileEditor` template.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.html" region="formgroupname" linenums="false" title="src/app/profile-editor/profile-editor.component.html (template nested form group)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.html" region="formgroupname" linenums="false" header="src/app/profile-editor/profile-editor.component.html (template nested form group)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -264,13 +264,13 @@ The strict checks of the `setValue()` method help catch nesting errors in comple
|
||||
|
||||
In `ProfileEditorComponent`, use the `updateProfile` method with the example below to update the first name and street address for the user.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="patch-value" title="src/app/profile-editor/profile-editor.component.ts (patch value)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="patch-value" header="src/app/profile-editor/profile-editor.component.ts (patch value)">
|
||||
|
||||
</code-example>
|
||||
|
||||
Simulate an update by adding a button to the template to update the user profile on demand.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.html" region="patch-value" linenums="false" title="src/app/profile-editor/profile-editor.component.html (update value)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.1.html" region="patch-value" linenums="false" header="src/app/profile-editor/profile-editor.component.html (update value)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -286,7 +286,7 @@ The following section refactors the `ProfileEditor` component to use the form bu
|
||||
|
||||
Import the `FormBuilder` class from the `@angular/forms` package.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="form-builder-imports" title="src/app/profile-editor/profile-editor.component.ts (import)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="form-builder-imports" header="src/app/profile-editor/profile-editor.component.ts (import)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -294,7 +294,7 @@ Import the `FormBuilder` class from the `@angular/forms` package.
|
||||
|
||||
The `FormBuilder` service is an injectable provider that is provided with the reactive forms module. Inject this dependency by adding it to the component constructor.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="inject-form-builder" title="src/app/profile-editor/profile-editor.component.ts (constructor)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="inject-form-builder" header="src/app/profile-editor/profile-editor.component.ts (constructor)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -304,7 +304,7 @@ The `FormBuilder` service has three methods: `control()`, `group()`, and `array(
|
||||
|
||||
Use the `group` method to create the `profileForm` controls.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="form-builder" title="src/app/profile-editor/profile-editor.component.ts (form builder)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="form-builder" header="src/app/profile-editor/profile-editor.component.ts (form builder)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -320,11 +320,11 @@ Compare using the form builder to creating the instances manually.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="formgroup-compare" title="src/app/profile-editor/profile-editor.component.ts (instances)">
|
||||
<code-pane path="reactive-forms/src/app/profile-editor/profile-editor.component.1.ts" region="formgroup-compare" header="src/app/profile-editor/profile-editor.component.ts (instances)">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="formgroup-compare" title="src/app/profile-editor/profile-editor.component.ts (form builder)">
|
||||
<code-pane path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="formgroup-compare" header="src/app/profile-editor/profile-editor.component.ts (form builder)">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -340,7 +340,7 @@ Reactive forms include a set of validator functions for common use cases. These
|
||||
|
||||
Import the `Validators` class from the `@angular/forms` package.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="validator-imports" title="src/app/profile-editor/profile-editor.component.ts (import)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="validator-imports" header="src/app/profile-editor/profile-editor.component.ts (import)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -350,13 +350,13 @@ The most common validation is making a field required. This section describes ho
|
||||
|
||||
In the `ProfileEditor` component, add the `Validators.required` static method as the second item in the array for the `firstName` control.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="required-validator" title="src/app/profile-editor/profile-editor.component.ts (required validator)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="required-validator" header="src/app/profile-editor/profile-editor.component.ts (required validator)">
|
||||
|
||||
</code-example>
|
||||
|
||||
HTML5 has a set of built-in attributes that you can use for native validation, including `required`, `minlength`, and `maxlength`. You can take advantage of these optional attributes on your form input elements. Add the `required` attribute to the `firstName` input element.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="required-attribute" linenums="false" title="src/app/profile-editor/profile-editor.component.html (required attribute)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="required-attribute" linenums="false" header="src/app/profile-editor/profile-editor.component.html (required attribute)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -372,7 +372,7 @@ When you add a required field to the form control, its initial status is invalid
|
||||
|
||||
Display the current status of `profileForm` using interpolation.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="display-status" linenums="false" title="src/app/profile-editor/profile-editor.component.html (display status)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="display-status" linenums="false" header="src/app/profile-editor/profile-editor.component.html (display status)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -392,7 +392,7 @@ For more on form validation, visit the [Form Validation](guide/form-validation)
|
||||
|
||||
Import the `FormArray` class from `@angular/forms` to use for type information. The `FormBuilder` service is ready to create a `FormArray` instance.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="form-array-imports" title="src/app/profile-editor/profile-editor.component.ts (import)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.2.ts" region="form-array-imports" header="src/app/profile-editor/profile-editor.component.ts (import)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -402,7 +402,7 @@ You can initialize a form array with any number of controls, from zero to many,
|
||||
|
||||
Use the `FormBuilder.array()` method to define the array, and the `FormBuilder.control()` method to populate the array with an initial control.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="aliases" title="src/app/profile-editor/profile-editor.component.ts (aliases form array)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="aliases" header="src/app/profile-editor/profile-editor.component.ts (aliases form array)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -414,7 +414,7 @@ A getter provides easy access to the aliases in the form array instance compared
|
||||
|
||||
Use the getter syntax to create an `aliases` class property to retrieve the alias's form array control from the parent form group.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="aliases-getter" title="src/app/profile-editor/profile-editor.component.ts (aliases getter)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="aliases-getter" header="src/app/profile-editor/profile-editor.component.ts (aliases getter)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -426,7 +426,7 @@ Use the getter syntax to create an `aliases` class property to retrieve the alia
|
||||
|
||||
Define a method to dynamically insert an alias control into the alias's form array. The `FormArray.push()` method inserts the control as a new item in the array.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="add-alias" title="src/app/profile-editor/profile-editor.component.ts (add alias)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.ts" region="add-alias" header="src/app/profile-editor/profile-editor.component.ts (add alias)">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -438,7 +438,7 @@ To attach the aliases from your form model, you must add it to the template. Sim
|
||||
|
||||
Add the template HTML below after the `<div>` closing the `formGroupName` element.
|
||||
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="formarrayname" linenums="false" title="src/app/profile-editor/profile-editor.component.html (aliases form array template)">
|
||||
<code-example path="reactive-forms/src/app/profile-editor/profile-editor.component.html" region="formarrayname" linenums="false" header="src/app/profile-editor/profile-editor.component.html (aliases form array template)">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -65,68 +65,34 @@ Disclaimer: The dates are offered as general guidance and may be adjusted by us
|
||||
|
||||
The following table contains our current target release dates for the next two major versions of Angular:
|
||||
|
||||
Date | Stable Release | Compatibility
|
||||
---------------------- | -------------- | ----------------
|
||||
September/October 2018 | 7.0.0 | ^6.0.0
|
||||
Date | Stable Release | Compatibility
|
||||
---------------------- | -------------- | -------------
|
||||
March/April 2019 | 8.0.0 | ^7.0.0
|
||||
September/October 2019 | 9.0.0 | ^8.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.
|
||||
|
||||
|
||||
{@a lts}
|
||||
{@a support}
|
||||
## Support policy
|
||||
## Support policy and schedule
|
||||
|
||||
All of our major releases are supported for 18 months.
|
||||
|
||||
* 6 months of active support, during which regularly-scheduled updates and patches are released, as described above in [Release frequency](#frequency "Release frequency").
|
||||
* 6 months of *active support*, during which regularly-scheduled updates and patches are released.
|
||||
|
||||
* 12 months of long-term support (LTS). During the LTS period, only critical fixes and security patches will be released.
|
||||
* 12 months of *long-term support (LTS)*, during which only critical fixes and security patches are released.
|
||||
|
||||
The following table provides the support status and key dates for Angular version 4.0.0 and higher.
|
||||
The following table provides the support status and key dates for Angular version 5.0.0 and higher.
|
||||
|
||||
<style>
|
||||
|
||||
td, th {vertical-align: top}
|
||||
|
||||
</style>
|
||||
|
||||
<table>
|
||||
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Status</th>
|
||||
<th>Release Date</th>
|
||||
<th>LTS Start Date</th>
|
||||
<th>LTS End Date</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>^4.0.0</td>
|
||||
<td>LTS</td>
|
||||
<td>March 23, 2017</td>
|
||||
<td>September 23, 2017</td>
|
||||
<td>September 23, 2018</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>^5.0.0</td>
|
||||
<td>LTS</td>
|
||||
<td>November 1, 2017</td>
|
||||
<td>May 1, 2018</td>
|
||||
<td>May 1, 2019</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>^6.0.0</td>
|
||||
<td>Active</td>
|
||||
<td>May 3, 2018</td>
|
||||
<td>November 3, 2018</td>
|
||||
<td>November 3, 2019</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
Version | Status | Released | Active Ends | LTS Ends
|
||||
------- | ------ | ------------ | ------------ | ------------
|
||||
^7.0.0 | Active | Oct 18, 2018 | Apr 18, 2019 | Apr 18, 2020
|
||||
^6.0.0 | LTS | May 3, 2018 | Nov 3, 2018 | Nov 3, 2019
|
||||
^5.0.0 | LTS | Nov 1, 2017 | May 1, 2018 | May 1, 2019
|
||||
|
||||
LTS for Angular version ^4.0.0 ended on September 23, 2018.
|
||||
|
||||
|
||||
{@a deprecation}
|
||||
|
@ -15,7 +15,7 @@ The [AnimationOptions](https://angular.io/api/animations/AnimationOptions) inter
|
||||
|
||||
To create a reusable animation, use the [`animation()`](https://angular.io/api/animations/animation) method to define an animation in a separate `.ts` file and declare this animation definition as a `const` export variable. You can then import and reuse this animation in any of your app components using the [`useAnimation()`](https://angular.io/api/animations/useAnimation) API.
|
||||
|
||||
<code-example path="animations/src/app/animations.ts" title="src/app/animations.ts" region="reusable" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/animations.ts" header="src/app/animations.ts" region="reusable" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
In the above code snippet, `transAnimation` is made reusable by declaring it as an export variable.
|
||||
@ -27,7 +27,7 @@ In the above code snippet, `transAnimation` is made reusable by declaring it as
|
||||
|
||||
You can import the reusable `transAnimation` variable in your component class and reuse it using the `useAnimation()` method as shown below.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.3.ts" title="src/app/open-close.component.ts" region="reusable" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/open-close.component.3.ts" header="src/app/open-close.component.ts" region="reusable" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
## More on Angular animations
|
||||
|
@ -43,7 +43,7 @@ Use the `RouterModule.forRoot` method to define a set of routes. Also, import th
|
||||
|
||||
The following configuration defines the possible routes for the application.
|
||||
|
||||
<code-example path="animations/src/app/app.module.ts" linenums="false" title="src/app/app.module.ts" region="route-animation-data" language="typescript">
|
||||
<code-example path="animations/src/app/app.module.ts" linenums="false" header="src/app/app.module.ts" region="route-animation-data" language="typescript">
|
||||
</code-example>
|
||||
|
||||
The `home` and `about` paths are associated with the `HomeComponent` and `AboutComponent` views. The route configuration tells the Angular router to instantiate the `HomeComponent` and `AboutComponent` views when the navigation matches the corresponding path.
|
||||
@ -62,12 +62,12 @@ After configuring the routes, tell the Angular router where to render the views
|
||||
|
||||
The `<router-outlet>` container has an attribute directive that contains data about active routes and their states, based on the `data` property that we set in the route configuration.
|
||||
|
||||
<code-example path="animations/src/app/app.component.html" title="src/app/app.component.html" region="route-animations-outlet">
|
||||
<code-example path="animations/src/app/app.component.html" header="src/app/app.component.html" region="route-animations-outlet">
|
||||
</code-example>
|
||||
|
||||
`AppComponent` defines a method that can detect when a view changes. The method assigns an animation state value to the animation trigger (`@routeAnimation`) based on the route configuration `data` property value. Here's an example of an `AppComponent` method that detects when a route change happens.
|
||||
|
||||
<code-example path="animations/src/app/app.component.ts" linenums="false" title="src/app/app.component.ts" region="prepare-router-outlet" language="typescript">
|
||||
<code-example path="animations/src/app/app.component.ts" linenums="false" header="src/app/app.component.ts" region="prepare-router-outlet" language="typescript">
|
||||
</code-example>
|
||||
|
||||
Here, the `prepareRoute()` method takes the value of the output directive (established through `#outlet="outlet"`) and returns a string value representing the state of the animation based on the custom data of the current active route. You can use this data to control which transition to execute for each route.
|
||||
@ -79,7 +79,7 @@ Animations can be defined directly inside your components. For this example we a
|
||||
The following code snippet defines a reusable animation named `slideInAnimation`.
|
||||
|
||||
|
||||
<code-example path="animations/src/app/animations.ts" linenums="false" title="src/app/animations.ts" region="route-animations" language="typescript">
|
||||
<code-example path="animations/src/app/animations.ts" linenums="false" header="src/app/animations.ts" region="route-animations" language="typescript">
|
||||
</code-example>
|
||||
|
||||
The animation definition does several things:
|
||||
@ -97,14 +97,14 @@ A route change activates the animation trigger, and a transition matching the st
|
||||
|
||||
Make the animation definition available in your application by adding the reusable animation (`slideInAnimation`) to the `animations` metadata of the `AppComponent`.
|
||||
|
||||
<code-example path="animations/src/app/app.component.ts" linenums="false" title="src/app/app.component.ts" region="define" language="typescript">
|
||||
<code-example path="animations/src/app/app.component.ts" linenums="false" header="src/app/app.component.ts" region="define" language="typescript">
|
||||
</code-example>
|
||||
|
||||
### Styling the host and child components
|
||||
|
||||
During a transition, a new view is inserted directly after the old one and both elements appear on screen at the same time. To prevent this, apply additional styling to the host view, and to the removed and inserted child views. The host view must use relative positioning, and the child views must use absolute positioning. Adding styling to the views animates the containers in place, without the DOM moving things around.
|
||||
|
||||
<code-example path="animations/src/app/animations.ts" linenums="false" title="src/app/animations.ts" region="style-view" language="typescript">
|
||||
<code-example path="animations/src/app/animations.ts" linenums="false" header="src/app/animations.ts" region="style-view" language="typescript">
|
||||
</code-example>
|
||||
|
||||
### Querying the view containers
|
||||
@ -113,7 +113,7 @@ Use the `query()` method to find and animate elements within the current host co
|
||||
|
||||
Let's assume that we are routing from the *Home => About*.
|
||||
|
||||
<code-example path="animations/src/app/animations.ts" linenums="false" title="src/app/animations.ts" region="query" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/animations.ts" linenums="false" header="src/app/animations.ts" region="query" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The animation code does the following after styling the views:
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -15,13 +15,13 @@ RxJS provides an implementation of the `Observable` type, which is needed until
|
||||
RxJS offers a number of functions that can be used to create new observables. These functions can simplify the process of creating observables from things such as events, timers, promises, and so on. For example:
|
||||
|
||||
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="promise" title="Create an observable from a promise"></code-example>
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="promise" header="Create an observable from a promise"></code-example>
|
||||
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="interval" title="Create an observable from a counter"></code-example>
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="interval" header="Create an observable from a counter"></code-example>
|
||||
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="event" title="Create an observable from an event"></code-example>
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="event" header="Create an observable from an event"></code-example>
|
||||
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="ajax" title="Create an observable that creates an AJAX request"></code-example>
|
||||
<code-example path="rx-library/src/simple-creation.ts" region="ajax" header="Create an observable that creates an AJAX request"></code-example>
|
||||
|
||||
## Operators
|
||||
|
||||
@ -29,7 +29,7 @@ Operators are functions that build on the observables foundation to enable sophi
|
||||
|
||||
Operators take configuration options, and they return a function that takes a source observable. When executing this returned function, the operator observes the source observable’s emitted values, transforms them, and returns a new observable of those transformed values. Here is a simple example:
|
||||
|
||||
<code-example path="rx-library/src/operators.ts" title="Map operator"></code-example>
|
||||
<code-example path="rx-library/src/operators.ts" header="Map operator"></code-example>
|
||||
|
||||
You can use _pipes_ to link operators together. Pipes let you combine multiple functions into a single function. The `pipe()` function takes as its arguments the functions you want to combine, and returns a new function that, when executed, runs the composed functions in sequence.
|
||||
|
||||
@ -37,11 +37,11 @@ A set of operators applied to an observable is a recipe—that is, a set of
|
||||
|
||||
Here’s an example:
|
||||
|
||||
<code-example path="rx-library/src/operators.1.ts" title="Standalone pipe function"></code-example>
|
||||
<code-example path="rx-library/src/operators.1.ts" header="Standalone pipe function"></code-example>
|
||||
|
||||
The `pipe()` function is also a method on the RxJS `Observable`, so you use this shorter form to define the same operation:
|
||||
|
||||
<code-example path="rx-library/src/operators.2.ts" title="Observable.pipe function"></code-example>
|
||||
<code-example path="rx-library/src/operators.2.ts" header="Observable.pipe function"></code-example>
|
||||
|
||||
### Common operators
|
||||
|
||||
@ -68,7 +68,7 @@ For instance, suppose you have an observable that makes an API request and maps
|
||||
|
||||
Here's an example of using the `catchError` operator to do this:
|
||||
|
||||
<code-example path="rx-library/src/error-handling.ts" title="catchError operator"></code-example>
|
||||
<code-example path="rx-library/src/error-handling.ts" header="catchError operator"></code-example>
|
||||
|
||||
### Retry failed observable
|
||||
|
||||
@ -78,7 +78,7 @@ Use the `retry` operator before the `catchError` operator. It resubscribes to th
|
||||
|
||||
The following converts the previous example to retry the request before catching the error:
|
||||
|
||||
<code-example path="rx-library/src/retry-on-error.ts" title="retry operator"></code-example>
|
||||
<code-example path="rx-library/src/retry-on-error.ts" header="retry operator"></code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
@ -94,4 +94,4 @@ This can be useful when scanning through code and looking for observable values.
|
||||
|
||||
For example:
|
||||
|
||||
<code-example path="rx-library/src/naming-convention.ts" title="Naming observables"></code-example>
|
||||
<code-example path="rx-library/src/naming-convention.ts" header="Naming observables"></code-example>
|
@ -98,7 +98,7 @@ The following template binds the value of `htmlSnippet`, once by interpolating i
|
||||
content, and once by binding it to the `innerHTML` property of an element:
|
||||
|
||||
|
||||
<code-example path="security/src/app/inner-html-binding.component.html" title="src/app/inner-html-binding.component.html">
|
||||
<code-example path="security/src/app/inner-html-binding.component.html" header="src/app/inner-html-binding.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -112,7 +112,7 @@ a value that an attacker might control into `innerHTML` normally causes an XSS
|
||||
vulnerability. For example, code contained in a `<script>` tag is executed:
|
||||
|
||||
|
||||
<code-example path="security/src/app/inner-html-binding.component.ts" linenums="false" title="src/app/inner-html-binding.component.ts (class)" region="class">
|
||||
<code-example path="security/src/app/inner-html-binding.component.ts" linenums="false" header="src/app/inner-html-binding.component.ts (class)" region="class">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -200,7 +200,7 @@ your intended use of the value. Imagine that the following template needs to bin
|
||||
`javascript:alert(...)` call:
|
||||
|
||||
|
||||
<code-example path="security/src/app/bypass-security.component.html" linenums="false" title="src/app/bypass-security.component.html (URL)" region="URL">
|
||||
<code-example path="security/src/app/bypass-security.component.html" linenums="false" header="src/app/bypass-security.component.html (URL)" region="URL">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -211,7 +211,7 @@ in development mode, logs this action to the console. To prevent
|
||||
this, mark the URL value as a trusted URL using the `bypassSecurityTrustUrl` call:
|
||||
|
||||
|
||||
<code-example path="security/src/app/bypass-security.component.ts" linenums="false" title="src/app/bypass-security.component.ts (trust-url)" region="trust-url">
|
||||
<code-example path="security/src/app/bypass-security.component.ts" linenums="false" header="src/app/bypass-security.component.ts (trust-url)" region="trust-url">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -231,13 +231,13 @@ could execute. So call a method on the controller to construct a trusted video U
|
||||
Angular to allow binding into `<iframe src>`:
|
||||
|
||||
|
||||
<code-example path="security/src/app/bypass-security.component.html" linenums="false" title="src/app/bypass-security.component.html (iframe)" region="iframe">
|
||||
<code-example path="security/src/app/bypass-security.component.html" linenums="false" header="src/app/bypass-security.component.html (iframe)" region="iframe">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
||||
|
||||
<code-example path="security/src/app/bypass-security.component.ts" linenums="false" title="src/app/bypass-security.component.ts (trust-video-url)" region="trust-video-url">
|
||||
<code-example path="security/src/app/bypass-security.component.ts" linenums="false" header="src/app/bypass-security.component.ts (trust-video-url)" region="trust-video-url">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -24,7 +24,7 @@ The `SwUpdate` service supports four separate operations:
|
||||
|
||||
The two update events, `available` and `activated`, are `Observable` properties of `SwUpdate`:
|
||||
|
||||
<code-example path="service-worker-getting-started/src/app/log-update.service.ts" linenums="false" title="log-update.service.ts" region="sw-update"> </code-example>
|
||||
<code-example path="service-worker-getting-started/src/app/log-update.service.ts" linenums="false" header="log-update.service.ts" region="sw-update"> </code-example>
|
||||
|
||||
|
||||
You can use these events to notify the user of a pending update or to refresh their pages when the code they are running is out of date.
|
||||
@ -35,7 +35,7 @@ It's possible to ask the service worker to check if any updates have been deploy
|
||||
|
||||
Do this with the `checkForUpdate()` method:
|
||||
|
||||
<code-example path="service-worker-getting-started/src/app/check-for-update.service.ts" linenums="false" title="check-for-update.service.ts" region="sw-check-update"> </code-example>
|
||||
<code-example path="service-worker-getting-started/src/app/check-for-update.service.ts" linenums="false" header="check-for-update.service.ts" region="sw-check-update"> </code-example>
|
||||
|
||||
|
||||
This method returns a `Promise` which indicates that the update check has completed successfully, though it does not indicate whether an update was discovered as a result of the check. Even if one is found, the service worker must still successfully download the changed files, which can fail. If successful, the `available` event will indicate availability of a new version of the app.
|
||||
@ -44,7 +44,7 @@ This method returns a `Promise` which indicates that the update check has comple
|
||||
|
||||
If the current tab needs to be updated to the latest app version immediately, it can ask to do so with the `activateUpdate()` method:
|
||||
|
||||
<code-example path="service-worker-getting-started/src/app/prompt-update.service.ts" linenums="false" title="prompt-update.service.ts" region="sw-activate"> </code-example>
|
||||
<code-example path="service-worker-getting-started/src/app/prompt-update.service.ts" linenums="false" header="prompt-update.service.ts" region="sw-activate"> </code-example>
|
||||
|
||||
Doing this could break lazy-loading into currently running apps, especially if the lazy-loaded chunks use filenames with hashes, which change every version.
|
||||
|
||||
|
@ -9,7 +9,7 @@ A basic understanding of the following:
|
||||
|
||||
The `src/ngsw-config.json` configuration file specifies which files and data URLs the Angular
|
||||
service worker should cache and how it should update the cached files and data. The
|
||||
CLI processes the configuration file during `ng build --prod`. Manually, you can process
|
||||
[Angular CLI](cli) processes the configuration file during `ng build --prod`. Manually, you can process
|
||||
it with the `ngsw-config` tool:
|
||||
|
||||
```sh
|
||||
@ -161,7 +161,15 @@ This section defines the policy by which matching requests will be cached.
|
||||
For example, the string `3d12h` will cache content for up to three and a half days.
|
||||
|
||||
#### `timeout`
|
||||
This duration string specifies the network timeout. The network timeout is how long the Angular service worker will wait for the network to respond before using a cached response, if configured to do so.
|
||||
This duration string specifies the network timeout. The network timeout is how long the Angular service worker will wait for the network to respond before using a cached response, if configured to do so. `timeout` is a duration string, using the following unit suffixes:
|
||||
|
||||
* `d`: days
|
||||
* `h`: hours
|
||||
* `m`: minutes
|
||||
* `s`: seconds
|
||||
* `u`: milliseconds
|
||||
|
||||
For example, the string `5s30u` will translate to five seconds and 30 milliseconds of network timeout.
|
||||
|
||||
#### `strategy`
|
||||
|
||||
|
@ -55,7 +55,7 @@ gets the correct content.
|
||||
|
||||
To ensure resource integrity, the Angular service worker validates
|
||||
the hashes of all resources for which it has a hash. Typically for
|
||||
a CLI app, this is everything in the `dist` directory covered by
|
||||
an app created with the [Angular CLI](cli), this is everything in the `dist` directory covered by
|
||||
the user's `src/ngsw-config.json` configuration.
|
||||
|
||||
If a particular file fails validation, the Angular service worker
|
||||
|
@ -1,15 +1,11 @@
|
||||
# Getting started with service workers
|
||||
|
||||
|
||||
This document explains how to enable Angular service worker support in your CLI projects. It then uses a simple example to show you a service worker in action, demonstrating loading and basic caching.
|
||||
This document explains how to enable Angular service worker support in projects that you created with the [Angular CLI](cli). It then uses a simple example to show you a service worker in action, demonstrating loading and basic caching.
|
||||
|
||||
#### Prerequisites
|
||||
|
||||
A basic understanding of the following:
|
||||
* [Introduction to Angular service workers](guide/service-worker-intro).
|
||||
* Angular v6, including Angular CLI v6.
|
||||
|
||||
<hr />
|
||||
A basic understanding of the information in [Introduction to Angular service workers](guide/service-worker-intro).
|
||||
|
||||
|
||||
## Adding a service worker to your project
|
||||
|
@ -31,7 +31,7 @@ Installing the Angular service worker is as simple as including an `NgModule`. I
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Your application must run in a web browser that supports service workers. Currently, the latest versions of Chrome and Firefox are supported. To learn about other browsers that are service worker ready, see the [Can I Use](http://caniuse.com/#feat=serviceworkers) page.
|
||||
Your application must run in a web browser that supports service workers. Currently, service workers are supported in the latest versions of Chrome, Firefox, Edge, Safari, Opera, UC Browser (Android version) and Samsung Internet. Browsers like IE and Opera Mini do not provide the support. To learn more about other browsers that are service worker ready, see the [Can I Use](https://caniuse.com/#feat=serviceworkers) page and [MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API).
|
||||
|
||||
## Related resources
|
||||
|
||||
|
@ -43,7 +43,7 @@ for getting and setting the current HTML document title:
|
||||
You can inject the `Title` service into the root `AppComponent` and expose a bindable `setTitle` method that calls it:
|
||||
|
||||
|
||||
<code-example path="set-document-title/src/app/app.component.ts" region="class" title="src/app/app.component.ts (class)" linenums="false"></code-example>
|
||||
<code-example path="set-document-title/src/app/app.component.ts" region="class" header="src/app/app.component.ts (class)" linenums="false"></code-example>
|
||||
|
||||
Bind that method to three anchor tags and voilà!
|
||||
|
||||
@ -54,9 +54,9 @@ Bind that method to three anchor tags and voilà!
|
||||
Here's the complete solution:
|
||||
|
||||
<code-tabs>
|
||||
<code-pane title="src/main.ts" path="set-document-title/src/main.ts"></code-pane>
|
||||
<code-pane title="src/app/app.module.ts" path="set-document-title/src/app/app.module.ts"></code-pane>
|
||||
<code-pane title="src/app/app.component.ts" path="set-document-title/src/app/app.component.ts"></code-pane>
|
||||
<code-pane header="src/main.ts" path="set-document-title/src/main.ts"></code-pane>
|
||||
<code-pane header="src/app/app.module.ts" path="set-document-title/src/app/app.module.ts"></code-pane>
|
||||
<code-pane header="src/app/app.component.ts" path="set-document-title/src/app/app.component.ts"></code-pane>
|
||||
</code-tabs>
|
||||
|
||||
## Why provide the `Title` service in `bootstrap`
|
||||
|
@ -1,360 +0,0 @@
|
||||
# Anatomy of the Setup Project
|
||||
|
||||
The documentation [setup](guide/setup) procedures install a _lot_ of files.
|
||||
Most of them can be safely ignored.
|
||||
|
||||
Application files _inside the_ **`src/`** and **`e2e/`** folders matter most to developers.
|
||||
|
||||
Files _outside_ those folders condition the development environment.
|
||||
They rarely change and you may never view or modify them.
|
||||
If you do, this page can help you understand their purpose.
|
||||
|
||||
|
||||
<style>
|
||||
td, th {vertical-align: top}
|
||||
</style>
|
||||
|
||||
|
||||
|
||||
<table width="100%">
|
||||
|
||||
<col width="10%">
|
||||
|
||||
</col>
|
||||
|
||||
<col width="90%">
|
||||
|
||||
</col>
|
||||
|
||||
<tr>
|
||||
|
||||
<th>
|
||||
File
|
||||
</th>
|
||||
|
||||
<th>
|
||||
Purpose
|
||||
</th>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>src/app/</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Angular application files go here.
|
||||
|
||||
Ships with the "Hello Angular" sample's
|
||||
`AppComponent`, `AppModule`, a component unit test (`app.component.spec.ts`), and
|
||||
the bootstrap file, `main.ts`.
|
||||
|
||||
Try the <live-example name="setup">sample application</live-example>
|
||||
and the <live-example name="setup" stackblitz="quickstart-specs">unit test</live-example>
|
||||
as _live examples_.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>e2e/</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
_End-to-end_ (e2e) tests of the application,
|
||||
written in Jasmine and run by the
|
||||
<a href="http://www.protractortest.org/" title="Protractor: end-to-end testing for Angular">protractor</a>
|
||||
e2e test runner.
|
||||
|
||||
Initialized with an e2e test for the "Hello Angular" sample.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>node_modules/</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
The _npm_ packages installed with the `npm install` command.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>.editorconfig<br>
|
||||
.git/<br>
|
||||
.gitignore<br>
|
||||
.travis.yml</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Tooling configuration files and folders.
|
||||
Ignore them until you have a compelling reason to do otherwise.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>CHANGELOG.md</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
The history of changes to the _QuickStart_ repository.
|
||||
Delete or ignore.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>favicon.ico</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
The application icon that appears in the browser tab.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>index.html</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
The application host page.
|
||||
It loads a few essential scripts in a prescribed order.
|
||||
Then it boots the application, placing the root `AppComponent`
|
||||
in the custom `<my-app>` body tag.
|
||||
|
||||
The same `index.html` satisfies all documentation application samples.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>karma.conf.js</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Configuration for the <a href="https://karma-runner.github.io/1.0/index.html" title="Karma unit test runner">karma</a>
|
||||
test runner described in the [Testing](guide/testing) guide.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>karma-test-shim.js</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Script to run <a href="https://karma-runner.github.io/1.0/index.html" title="Karma unit test runner">karma</a>
|
||||
with SystemJS as described in the [Testing](guide/testing) guide.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>non-essential-files.txt</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
A list of files that you can delete if you want to purge your setup of the
|
||||
original QuickStart Seed testing and git maintenance artifacts.
|
||||
See instructions in the optional
|
||||
[_Deleting non-essential files_](guide/setup#non-essential "Setup: Deleting non-essential files") section.
|
||||
*Do this only in the beginning to avoid accidentally deleting your own tests and git setup!*
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>LICENSE</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
The open source MIT license to use this setup code in your application.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>package.json</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Identifies `npm `package dependencies for the project.
|
||||
|
||||
Contains command scripts for running the application,
|
||||
running tests, and more. Enter `npm run` for a listing.
|
||||
<a href="https://github.com/angular/quickstart/blob/master/README.md#npm-scripts"
|
||||
title="npm scripts for Angular documentation samples">Read more</a> about them.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>protractor.config.js</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Configuration for the
|
||||
<a href="http://www.protractortest.org/" title="Protractor: end-to-end testing for Angular">protractor</a>
|
||||
_end-to-end_ (e2e) test runner.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>README.md</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Instruction for using this git repository in your project.
|
||||
Worth reading before deleting.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>styles.css</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Global styles for the application. Initialized with an `<h1>` style for the QuickStart demo.
|
||||
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>systemjs<br>.config.js</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Tells the **SystemJS** module loader where to find modules
|
||||
referenced in JavaScript `import` statements. For example:
|
||||
<code-example language="ts">
|
||||
import { Component } from '@angular/core;
|
||||
</code-example>
|
||||
|
||||
|
||||
Don't touch this file unless you are fully versed in SystemJS configuration.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>systemjs<br>.config.extras.js</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Optional extra SystemJS configuration.
|
||||
A way to add SystemJS mappings, such as for application _barrels_,
|
||||
without changing the original `system.config.js`.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>tsconfig.json</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
Tells the TypeScript compiler how to transpile TypeScript source files
|
||||
into JavaScript files that run in all modern browsers.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
<td>
|
||||
<code>tslint.json</code>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
|
||||
|
||||
The `npm` installed TypeScript linter inspects your TypeScript code
|
||||
and complains when you violate one of its rules.
|
||||
|
||||
This file defines linting rules favored by the
|
||||
[Angular style guide](guide/styleguide) and by the authors of the documentation.
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
@ -125,7 +125,7 @@ Open a terminal window in the project folder and enter the following commands fo
|
||||
The **QuickStart seed** contains the same application as the QuickStart playground.
|
||||
But its true purpose is to provide a solid foundation for _local_ development.
|
||||
Consequently, there are _many more files_ in the project folder on your machine,
|
||||
most of which you can [learn about later](guide/setup-systemjs-anatomy "Setup Anatomy").
|
||||
most of which you can [learn about later](guide/file-structure).
|
||||
|
||||
|
||||
|
||||
@ -171,15 +171,15 @@ Focus on the following three TypeScript (`.ts`) files in the **`/src`** folder.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="src/app/app.component.ts" path="setup/src/app/app.component.ts">
|
||||
<code-pane header="src/app/app.component.ts" path="setup/src/app/app.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/app/app.module.ts" path="setup/src/app/app.module.ts">
|
||||
<code-pane header="src/app/app.module.ts" path="setup/src/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="src/main.ts" path="setup/src/main.ts">
|
||||
<code-pane header="src/main.ts" path="setup/src/main.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
|
@ -19,7 +19,7 @@ There are two ways to make a service a singleton in Angular:
|
||||
|
||||
Beginning with Angular 6.0, the preferred way to create a singleton services is to specify on the service that it should be provided in the application root. This is done by setting `providedIn` to `root` on the service's `@Injectable` decorator:
|
||||
|
||||
<code-example path="providers/src/app/user.service.0.ts" title="src/app/user.service.0.ts" linenums="false"> </code-example>
|
||||
<code-example path="providers/src/app/user.service.0.ts" header="src/app/user.service.0.ts" linenums="false"> </code-example>
|
||||
|
||||
|
||||
For more detailed information on services, see the [Services](tutorial/toh-pt4) chapter of the
|
||||
@ -69,19 +69,19 @@ the core `UserService`.
|
||||
In the following example, the optional, injected `UserServiceConfig`
|
||||
extends the core `UserService`. If a `UserServiceConfig` exists, the `UserService` sets the user name from that config.
|
||||
|
||||
<code-example path="ngmodules/src/app/core/user.service.ts" region="ctor" title="src/app/core/user.service.ts (constructor)" linenums="false">
|
||||
<code-example path="ngmodules/src/app/core/user.service.ts" region="ctor" header="src/app/core/user.service.ts (constructor)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
Here's `forRoot()` that takes a `UserServiceConfig` object:
|
||||
|
||||
<code-example path="ngmodules/src/app/core/core.module.ts" region="for-root" title="src/app/core/core.module.ts (forRoot)" linenums="false">
|
||||
<code-example path="ngmodules/src/app/core/core.module.ts" region="for-root" header="src/app/core/core.module.ts (forRoot)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
Lastly, call it within the `imports` list of the `AppModule`.
|
||||
|
||||
<code-example path="ngmodules/src/app/app.module.ts" region="import-for-root" title="src/app/app.module.ts (imports)" linenums="false">
|
||||
<code-example path="ngmodules/src/app/app.module.ts" region="import-for-root" header="src/app/app.module.ts (imports)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -99,7 +99,7 @@ lazy-loaded module imports it too, the app can generate
|
||||
|
||||
To guard against a lazy-loaded module re-importing `CoreModule`, add the following `CoreModule` constructor.
|
||||
|
||||
<code-example path="ngmodules/src/app/core/core.module.ts" region="ctor" title="src/app/core/core.module.ts" linenums="false">
|
||||
<code-example path="ngmodules/src/app/core/core.module.ts" region="ctor" header="src/app/core/core.module.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -130,11 +130,11 @@ Here are the two files in their entirety for reference:
|
||||
|
||||
<code-tabs linenums="false">
|
||||
<code-pane
|
||||
title="app.module.ts"
|
||||
header="app.module.ts"
|
||||
path="ngmodules/src/app/app.module.ts">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
title="core.module.ts"
|
||||
header="core.module.ts"
|
||||
region="whole-core-module"
|
||||
path="ngmodules/src/app/core/core.module.ts">
|
||||
</code-pane>
|
||||
|
@ -31,7 +31,7 @@ Structural directives are easy to recognize.
|
||||
An asterisk (*) precedes the directive attribute name as in this example.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngif)" region="ngif">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngif)" region="ngif">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -52,7 +52,7 @@ described in the [_Template Syntax_](guide/template-syntax) guide and seen in sa
|
||||
Here's an example of them in a template:
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (built-in)" region="built-in">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (built-in)" region="built-in">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -121,7 +121,7 @@ You can [only apply one](guide/structural-directives#one-per-element) _structura
|
||||
It takes a boolean expression and makes an entire chunk of the DOM appear or disappear.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngif-true)" region="ngif-true">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngif-true)" region="ngif-true">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -150,7 +150,7 @@ The component and DOM nodes can be garbage-collected and free up memory.
|
||||
A directive could hide the unwanted paragraph instead by setting its `display` style to `none`.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (display-none)" region="display-none">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (display-none)" region="display-none">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -201,7 +201,7 @@ and wondered why it is necessary and what it does.
|
||||
Here is `*ngIf` displaying the hero's name if `hero` exists.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (asterisk)" region="asterisk">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (asterisk)" region="asterisk">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -211,7 +211,7 @@ The asterisk is "syntactic sugar" for something a bit more complicated.
|
||||
Internally, Angular translates the `*ngIf` _attribute_ into a `<ng-template>` _element_, wrapped around the host element, like this.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngif-template)" region="ngif-template">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngif-template)" region="ngif-template">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -246,7 +246,7 @@ Angular transforms the `*ngFor` in similar fashion from asterisk (*) syntax to `
|
||||
Here's a full-featured application of `NgFor`, written both ways:
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (inside-ngfor)" region="inside-ngfor">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (inside-ngfor)" region="inside-ngfor">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -373,7 +373,7 @@ The Angular _NgSwitch_ is actually a set of cooperating directives: `NgSwitch`,
|
||||
Here's an example.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngswitch)" region="ngswitch">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngswitch)" region="ngswitch">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -409,7 +409,7 @@ As with other structural directives, the `NgSwitchCase` and `NgSwitchDefault`
|
||||
can be desugared into the `<ng-template>` element form.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngswitch-template)" region="ngswitch-template">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngswitch-template)" region="ngswitch-template">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -444,7 +444,7 @@ those elements disappear.
|
||||
That's the fate of the middle "Hip!" in the phrase "Hip! Hip! Hooray!".
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (template-tag)" region="template-tag">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (template-tag)" region="template-tag">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -476,7 +476,7 @@ There's often a _root_ element that can and should host the structural directive
|
||||
The list element (`<li>`) is a typical host element of an `NgFor` repeater.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngfor-li)" region="ngfor-li">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngfor-li)" region="ngfor-li">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -486,7 +486,7 @@ When there isn't a host element, you can usually wrap the content in a native HT
|
||||
such as a `<div>`, and attach the directive to that wrapper.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngif)" region="ngif">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngif)" region="ngif">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -501,7 +501,7 @@ neither expect nor accommodate the new layout.
|
||||
For example, suppose you have the following paragraph layout.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngif-span)" region="ngif-span">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngif-span)" region="ngif-span">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -510,7 +510,7 @@ For example, suppose you have the following paragraph layout.
|
||||
You also have a CSS style rule that happens to apply to a `<span>` within a `<p>`aragraph.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.css" linenums="false" title="src/app/app.component.css (p-span)" region="p-span">
|
||||
<code-example path="structural-directives/src/app/app.component.css" linenums="false" header="src/app/app.component.css (p-span)" region="p-span">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -534,7 +534,7 @@ You can't wrap the _options_ in a conditional `<div>` or a `<span>`.
|
||||
When you try this,
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (select-span)" region="select-span">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (select-span)" region="select-span">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -559,7 +559,7 @@ because Angular _doesn't put it in the DOM_.
|
||||
Here's the conditional paragraph again, this time using `<ng-container>`.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (ngif-ngcontainer)" region="ngif-ngcontainer">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (ngif-ngcontainer)" region="ngif-ngcontainer">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -577,7 +577,7 @@ It renders properly.
|
||||
Now conditionally exclude a _select_ `<option>` with `<ng-container>`.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (select-ngcontainer)" region="select-ngcontainer">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (select-ngcontainer)" region="select-ngcontainer">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -625,7 +625,7 @@ that does the opposite of `NgIf`.
|
||||
`UnlessDirective` displays the content when the condition is ***false***.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (appUnless-1)" region="appUnless-1">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (appUnless-1)" region="appUnless-1">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -644,7 +644,7 @@ Creating a directive is similar to creating a component.
|
||||
Here's how you might begin:
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" title="src/app/unless.directive.ts (skeleton)" region="skeleton">
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" header="src/app/unless.directive.ts (skeleton)" region="skeleton">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -679,7 +679,7 @@ and access the _view container_ through a
|
||||
You inject both in the directive constructor as private variables of the class.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" title="src/app/unless.directive.ts (ctor)" region="ctor">
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" header="src/app/unless.directive.ts (ctor)" region="ctor">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -702,7 +702,7 @@ Read about `@Input` in the [_Template Syntax_](guide/template-syntax#inputs-outp
|
||||
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" title="src/app/unless.directive.ts (set)" region="set">
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" header="src/app/unless.directive.ts (set)" region="set">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -722,7 +722,7 @@ Nobody reads the `appUnless` property so it doesn't need a getter.
|
||||
The completed directive code looks like this:
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" title="src/app/unless.directive.ts (excerpt)" region="no-docs">
|
||||
<code-example path="structural-directives/src/app/unless.directive.ts" linenums="false" header="src/app/unless.directive.ts (excerpt)" region="no-docs">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -733,7 +733,7 @@ Add this directive to the `declarations` array of the AppModule.
|
||||
Then create some HTML to try it.
|
||||
|
||||
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" title="src/app/app.component.html (appUnless)" region="appUnless">
|
||||
<code-example path="structural-directives/src/app/app.component.html" linenums="false" header="src/app/app.component.html (appUnless)" region="appUnless">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -762,31 +762,31 @@ Here is the source from the `src/app/` folder.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app.component.ts" path="structural-directives/src/app/app.component.ts">
|
||||
<code-pane header="app.component.ts" path="structural-directives/src/app/app.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.component.html" path="structural-directives/src/app/app.component.html">
|
||||
<code-pane header="app.component.html" path="structural-directives/src/app/app.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.component.css" path="structural-directives/src/app/app.component.css">
|
||||
<code-pane header="app.component.css" path="structural-directives/src/app/app.component.css">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app.module.ts" path="structural-directives/src/app/app.module.ts">
|
||||
<code-pane header="app.module.ts" path="structural-directives/src/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="hero.ts" path="structural-directives/src/app/hero.ts">
|
||||
<code-pane header="hero.ts" path="structural-directives/src/app/hero.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="hero-switch.components.ts" path="structural-directives/src/app/hero-switch.components.ts">
|
||||
<code-pane header="hero-switch.components.ts" path="structural-directives/src/app/hero-switch.components.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="unless.directive.ts" path="structural-directives/src/app/unless.directive.ts">
|
||||
<code-pane header="unless.directive.ts" path="structural-directives/src/app/unless.directive.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
|
@ -152,7 +152,7 @@ defines the `Hero` model object, and loads heroes from the server all in the sam
|
||||
*Don't do this*.
|
||||
|
||||
|
||||
<code-example path="styleguide/src/01-01/app/heroes/hero.component.avoid.ts" title="app/heroes/hero.component.ts">
|
||||
<code-example path="styleguide/src/01-01/app/heroes/hero.component.avoid.ts" header="app/heroes/hero.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -164,31 +164,31 @@ supporting classes into their own, dedicated files.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="main.ts" path="styleguide/src/01-01/main.ts">
|
||||
<code-pane header="main.ts" path="styleguide/src/01-01/main.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/app.module.ts" path="styleguide/src/01-01/app/app.module.ts">
|
||||
<code-pane header="app/app.module.ts" path="styleguide/src/01-01/app/app.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/app.component.ts" path="styleguide/src/01-01/app/app.component.ts">
|
||||
<code-pane header="app/app.component.ts" path="styleguide/src/01-01/app/app.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/heroes.component.ts" path="styleguide/src/01-01/app/heroes/heroes.component.ts">
|
||||
<code-pane header="app/heroes/heroes.component.ts" path="styleguide/src/01-01/app/heroes/heroes.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/shared/hero.service.ts" path="styleguide/src/01-01/app/heroes/shared/hero.service.ts">
|
||||
<code-pane header="app/heroes/shared/hero.service.ts" path="styleguide/src/01-01/app/heroes/shared/hero.service.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/shared/hero.model.ts" path="styleguide/src/01-01/app/heroes/shared/hero.model.ts">
|
||||
<code-pane header="app/heroes/shared/hero.model.ts" path="styleguide/src/01-01/app/heroes/shared/hero.model.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/shared/mock-heroes.ts" path="styleguide/src/01-01/app/heroes/shared/mock-heroes.ts">
|
||||
<code-pane header="app/heroes/shared/mock-heroes.ts" path="styleguide/src/01-01/app/heroes/shared/mock-heroes.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -925,7 +925,7 @@ As always, strive for consistency.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-05/main.ts" title="main.ts">
|
||||
<code-example path="styleguide/src/02-05/main.ts" header="main.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -962,7 +962,7 @@ As always, strive for consistency.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-02/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" title="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/05-02/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" header="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -972,11 +972,11 @@ As always, strive for consistency.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/heroes/shared/hero-button/hero-button.component.ts" path="styleguide/src/05-02/app/heroes/shared/hero-button/hero-button.component.ts" region="example">
|
||||
<code-pane header="app/heroes/shared/hero-button/hero-button.component.ts" path="styleguide/src/05-02/app/heroes/shared/hero-button/hero-button.component.ts" region="example">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/app.component.html" path="styleguide/src/05-02/app/app.component.html">
|
||||
<code-pane header="app/app.component.html" path="styleguide/src/05-02/app/app.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -1061,7 +1061,7 @@ For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-07/app/heroes/hero.component.avoid.ts" region="example" title="app/heroes/hero.component.ts">
|
||||
<code-example path="styleguide/src/02-07/app/heroes/hero.component.avoid.ts" region="example" header="app/heroes/hero.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1069,7 +1069,7 @@ For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-07/app/users/users.component.avoid.ts" region="example" title="app/users/users.component.ts">
|
||||
<code-example path="styleguide/src/02-07/app/users/users.component.avoid.ts" region="example" header="app/users/users.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1077,7 +1077,7 @@ For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-07/app/heroes/hero.component.ts" region="example" title="app/heroes/hero.component.ts">
|
||||
<code-example path="styleguide/src/02-07/app/heroes/hero.component.ts" region="example" header="app/heroes/hero.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1085,7 +1085,7 @@ For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-07/app/users/users.component.ts" region="example" title="app/users/users.component.ts">
|
||||
<code-example path="styleguide/src/02-07/app/users/users.component.ts" region="example" header="app/users/users.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1183,7 +1183,7 @@ For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-08/app/shared/validate.directive.avoid.ts" region="example" title="app/shared/validate.directive.ts">
|
||||
<code-example path="styleguide/src/02-08/app/shared/validate.directive.avoid.ts" region="example" header="app/shared/validate.directive.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1191,7 +1191,7 @@ For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/02-08/app/shared/validate.directive.ts" region="example" title="app/shared/validate.directive.ts">
|
||||
<code-example path="styleguide/src/02-08/app/shared/validate.directive.ts" region="example" header="app/shared/validate.directive.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1799,7 +1799,7 @@ By convention, upper camel case indicates a constructable asset.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-01/app/core/exception.service.avoid.ts" region="example" title="app/shared/exception.service.ts">
|
||||
<code-example path="styleguide/src/03-01/app/core/exception.service.avoid.ts" region="example" header="app/shared/exception.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1807,7 +1807,7 @@ By convention, upper camel case indicates a constructable asset.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-01/app/core/exception.service.ts" region="example" title="app/shared/exception.service.ts">
|
||||
<code-example path="styleguide/src/03-01/app/core/exception.service.ts" region="example" header="app/shared/exception.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -1916,7 +1916,7 @@ It is rarely worth the effort to change them at the risk of breaking existing co
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-02/app/core/data.service.ts" title="app/shared/data.service.ts">
|
||||
<code-example path="styleguide/src/03-02/app/core/data.service.ts" header="app/shared/data.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2020,7 +2020,7 @@ discourage the `I` prefix.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-03/app/core/hero-collector.service.avoid.ts" region="example" title="app/shared/hero-collector.service.ts">
|
||||
<code-example path="styleguide/src/03-03/app/core/hero-collector.service.avoid.ts" region="example" header="app/shared/hero-collector.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2028,7 +2028,7 @@ discourage the `I` prefix.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-03/app/core/hero-collector.service.ts" region="example" title="app/shared/hero-collector.service.ts">
|
||||
<code-example path="styleguide/src/03-03/app/core/hero-collector.service.ts" region="example" header="app/shared/hero-collector.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2098,7 +2098,7 @@ discourage the `I` prefix.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-04/app/core/toast.service.avoid.ts" region="example" title="app/shared/toast.service.ts">
|
||||
<code-example path="styleguide/src/03-04/app/core/toast.service.avoid.ts" region="example" header="app/shared/toast.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2106,7 +2106,7 @@ discourage the `I` prefix.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-04/app/core/toast.service.ts" region="example" title="app/shared/toast.service.ts">
|
||||
<code-example path="styleguide/src/03-04/app/core/toast.service.ts" region="example" header="app/shared/toast.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2176,7 +2176,7 @@ discourage the `I` prefix.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-06/app/heroes/shared/hero.service.avoid.ts" region="example" title="app/heroes/shared/hero.service.ts">
|
||||
<code-example path="styleguide/src/03-06/app/heroes/shared/hero.service.avoid.ts" region="example" header="app/heroes/shared/hero.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2184,7 +2184,7 @@ discourage the `I` prefix.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/03-06/app/heroes/shared/hero.service.ts" region="example" title="app/heroes/shared/hero.service.ts">
|
||||
<code-example path="styleguide/src/03-06/app/heroes/shared/hero.service.ts" region="example" header="app/heroes/shared/hero.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -2932,7 +2932,7 @@ for example, in `/src/app`.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/04-08/app/app.module.ts" region="example" title="app/app.module.ts">
|
||||
<code-example path="styleguide/src/04-08/app/app.module.ts" region="example" header="app/app.module.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -3284,27 +3284,27 @@ Yet there is a real danger of that happening if the `SharedModule` provides a se
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/shared/shared.module.ts" path="styleguide/src/04-10/app/shared/shared.module.ts">
|
||||
<code-pane header="app/shared/shared.module.ts" path="styleguide/src/04-10/app/shared/shared.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/shared/init-caps.pipe.ts" path="styleguide/src/04-10/app/shared/init-caps.pipe.ts">
|
||||
<code-pane header="app/shared/init-caps.pipe.ts" path="styleguide/src/04-10/app/shared/init-caps.pipe.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/shared/filter-text/filter-text.component.ts" path="styleguide/src/04-10/app/shared/filter-text/filter-text.component.ts">
|
||||
<code-pane header="app/shared/filter-text/filter-text.component.ts" path="styleguide/src/04-10/app/shared/filter-text/filter-text.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/shared/filter-text/filter-text.service.ts" path="styleguide/src/04-10/app/shared/filter-text/filter-text.service.ts">
|
||||
<code-pane header="app/shared/filter-text/filter-text.service.ts" path="styleguide/src/04-10/app/shared/filter-text/filter-text.service.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/heroes.component.ts" path="styleguide/src/04-10/app/heroes/heroes.component.ts">
|
||||
<code-pane header="app/heroes/heroes.component.ts" path="styleguide/src/04-10/app/heroes/heroes.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/heroes.component.html" path="styleguide/src/04-10/app/heroes/heroes.component.html">
|
||||
<code-pane header="app/heroes/heroes.component.html" path="styleguide/src/04-10/app/heroes/heroes.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -3589,35 +3589,35 @@ Yet there is a real danger of that happening accidentally if the `CoreModule` pr
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/app.module.ts" path="styleguide/src/04-11/app/app.module.ts" region="example">
|
||||
<code-pane header="app/app.module.ts" path="styleguide/src/04-11/app/app.module.ts" region="example">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/core.module.ts" path="styleguide/src/04-11/app/core/core.module.ts">
|
||||
<code-pane header="app/core/core.module.ts" path="styleguide/src/04-11/app/core/core.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/logger.service.ts" path="styleguide/src/04-11/app/core/logger.service.ts">
|
||||
<code-pane header="app/core/logger.service.ts" path="styleguide/src/04-11/app/core/logger.service.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/nav/nav.component.ts" path="styleguide/src/04-11/app/core/nav/nav.component.ts">
|
||||
<code-pane header="app/core/nav/nav.component.ts" path="styleguide/src/04-11/app/core/nav/nav.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/nav/nav.component.html" path="styleguide/src/04-11/app/core/nav/nav.component.html">
|
||||
<code-pane header="app/core/nav/nav.component.html" path="styleguide/src/04-11/app/core/nav/nav.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/spinner/spinner.component.ts" path="styleguide/src/04-11/app/core/spinner/spinner.component.ts">
|
||||
<code-pane header="app/core/spinner/spinner.component.ts" path="styleguide/src/04-11/app/core/spinner/spinner.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/spinner/spinner.component.html" path="styleguide/src/04-11/app/core/spinner/spinner.component.html">
|
||||
<code-pane header="app/core/spinner/spinner.component.html" path="styleguide/src/04-11/app/core/spinner/spinner.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/spinner/spinner.service.ts" path="styleguide/src/04-11/app/core/spinner/spinner.service.ts">
|
||||
<code-pane header="app/core/spinner/spinner.service.ts" path="styleguide/src/04-11/app/core/spinner/spinner.service.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -3685,11 +3685,11 @@ Only the root `AppModule` should import the `CoreModule`.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/core/module-import-guard.ts" path="styleguide/src/04-12/app/core/module-import-guard.ts">
|
||||
<code-pane header="app/core/module-import-guard.ts" path="styleguide/src/04-12/app/core/module-import-guard.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/core/core.module.ts" path="styleguide/src/04-12/app/core/core.module.ts">
|
||||
<code-pane header="app/core/core.module.ts" path="styleguide/src/04-12/app/core/core.module.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -3808,7 +3808,7 @@ There are a few cases where you give a component an attribute, such as when you
|
||||
|
||||
</div>
|
||||
|
||||
<code-example path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" title="app/heroes/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" header="app/heroes/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -3816,7 +3816,7 @@ There are a few cases where you give a component an attribute, such as when you
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-03/app/app.component.avoid.html" title="app/app.component.html">
|
||||
<code-example path="styleguide/src/05-03/app/app.component.avoid.html" header="app/app.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -3824,11 +3824,11 @@ There are a few cases where you give a component an attribute, such as when you
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/heroes/shared/hero-button/hero-button.component.ts" path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.ts" region="example">
|
||||
<code-pane header="app/heroes/shared/hero-button/hero-button.component.ts" path="styleguide/src/05-03/app/heroes/shared/hero-button/hero-button.component.ts" region="example">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/app.component.html" path="styleguide/src/05-03/app/app.component.html">
|
||||
<code-pane header="app/app.component.html" path="styleguide/src/05-03/app/app.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -3936,7 +3936,7 @@ in those editors that support it; it won't help with CSS styles.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-04/app/heroes/heroes.component.avoid.ts" region="example" title="app/heroes/heroes.component.ts">
|
||||
<code-example path="styleguide/src/05-04/app/heroes/heroes.component.avoid.ts" region="example" header="app/heroes/heroes.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -3946,15 +3946,15 @@ in those editors that support it; it won't help with CSS styles.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/heroes/heroes.component.ts" path="styleguide/src/05-04/app/heroes/heroes.component.ts" region="example">
|
||||
<code-pane header="app/heroes/heroes.component.ts" path="styleguide/src/05-04/app/heroes/heroes.component.ts" region="example">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/heroes.component.html" path="styleguide/src/05-04/app/heroes/heroes.component.html">
|
||||
<code-pane header="app/heroes/heroes.component.html" path="styleguide/src/05-04/app/heroes/heroes.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/heroes.component.css" path="styleguide/src/05-04/app/heroes/heroes.component.css">
|
||||
<code-pane header="app/heroes/heroes.component.css" path="styleguide/src/05-04/app/heroes/heroes.component.css">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -4040,7 +4040,7 @@ Put it on the line above when doing so is clearly more readable.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-12/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" title="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/05-12/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" header="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4048,7 +4048,7 @@ Put it on the line above when doing so is clearly more readable.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-12/app/heroes/shared/hero-button/hero-button.component.ts" region="example" title="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/05-12/app/heroes/shared/hero-button/hero-button.component.ts" region="example" header="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4098,7 +4098,7 @@ and the directive name doesn't describe the property.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-13/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" title="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/05-13/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" header="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4106,7 +4106,7 @@ and the directive name doesn't describe the property.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-13/app/app.component.avoid.html" title="app/app.component.html">
|
||||
<code-example path="styleguide/src/05-13/app/app.component.avoid.html" header="app/app.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4116,15 +4116,15 @@ and the directive name doesn't describe the property.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/heroes/shared/hero-button/hero-button.component.ts" path="styleguide/src/05-13/app/heroes/shared/hero-button/hero-button.component.ts" region="example">
|
||||
<code-pane header="app/heroes/shared/hero-button/hero-button.component.ts" path="styleguide/src/05-13/app/heroes/shared/hero-button/hero-button.component.ts" region="example">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/heroes/shared/hero-button/hero-highlight.directive.ts" path="styleguide/src/05-13/app/heroes/shared/hero-highlight.directive.ts">
|
||||
<code-pane header="app/heroes/shared/hero-button/hero-highlight.directive.ts" path="styleguide/src/05-13/app/heroes/shared/hero-highlight.directive.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/app.component.html" path="styleguide/src/05-13/app/app.component.html">
|
||||
<code-pane header="app/app.component.html" path="styleguide/src/05-13/app/app.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -4175,7 +4175,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-14/app/shared/toast/toast.component.avoid.ts" region="example" title="app/shared/toast/toast.component.ts">
|
||||
<code-example path="styleguide/src/05-14/app/shared/toast/toast.component.avoid.ts" region="example" header="app/shared/toast/toast.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4183,7 +4183,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-14/app/shared/toast/toast.component.ts" region="example" title="app/shared/toast/toast.component.ts">
|
||||
<code-example path="styleguide/src/05-14/app/shared/toast/toast.component.ts" region="example" header="app/shared/toast/toast.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4264,7 +4264,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-15/app/heroes/hero-list/hero-list.component.avoid.ts" title="app/heroes/hero-list/hero-list.component.ts">
|
||||
<code-example path="styleguide/src/05-15/app/heroes/hero-list/hero-list.component.avoid.ts" header="app/heroes/hero-list/hero-list.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4272,7 +4272,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-15/app/heroes/hero-list/hero-list.component.ts" region="example" title="app/heroes/hero-list/hero-list.component.ts">
|
||||
<code-example path="styleguide/src/05-15/app/heroes/hero-list/hero-list.component.ts" region="example" header="app/heroes/hero-list/hero-list.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4331,7 +4331,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-16/app/heroes/hero.component.avoid.ts" region="example" title="app/heroes/hero.component.ts">
|
||||
<code-example path="styleguide/src/05-16/app/heroes/hero.component.avoid.ts" region="example" header="app/heroes/hero.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4339,7 +4339,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-16/app/app.component.avoid.html" title="app/app.component.html">
|
||||
<code-example path="styleguide/src/05-16/app/app.component.avoid.html" header="app/app.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4349,11 +4349,11 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="app/heroes/hero.component.ts" path="styleguide/src/05-16/app/heroes/hero.component.ts" region="example">
|
||||
<code-pane header="app/heroes/hero.component.ts" path="styleguide/src/05-16/app/heroes/hero.component.ts" region="example">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="app/app.component.html" path="styleguide/src/05-16/app/app.component.html">
|
||||
<code-pane header="app/app.component.html" path="styleguide/src/05-16/app/app.component.html">
|
||||
|
||||
</code-pane>
|
||||
|
||||
@ -4403,7 +4403,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-17/app/heroes/hero-list/hero-list.component.avoid.ts" region="example" title="app/heroes/hero-list/hero-list.component.ts">
|
||||
<code-example path="styleguide/src/05-17/app/heroes/hero-list/hero-list.component.avoid.ts" region="example" header="app/heroes/hero-list/hero-list.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4411,7 +4411,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/05-17/app/heroes/hero-list/hero-list.component.ts" region="example" title="app/heroes/hero-list/hero-list.component.ts">
|
||||
<code-example path="styleguide/src/05-17/app/heroes/hero-list/hero-list.component.ts" region="example" header="app/heroes/hero-list/hero-list.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4462,7 +4462,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/06-01/app/shared/highlight.directive.ts" region="example" title="app/shared/highlight.directive.ts">
|
||||
<code-example path="styleguide/src/06-01/app/shared/highlight.directive.ts" region="example" header="app/shared/highlight.directive.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4470,7 +4470,7 @@ helps instantly identify which members of the component serve which purpose.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/06-01/app/app.component.html" title="app/app.component.html">
|
||||
<code-example path="styleguide/src/06-01/app/app.component.html" header="app/app.component.html">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4522,7 +4522,7 @@ directive's class and the metadata in the decorator associated with the directiv
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/06-03/app/shared/validator.directive.ts" title="app/shared/validator.directive.ts">
|
||||
<code-example path="styleguide/src/06-03/app/shared/validator.directive.ts" header="app/shared/validator.directive.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4542,7 +4542,7 @@ Compare with the less preferred `host` metadata alternative.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/06-03/app/shared/validator2.directive.ts" title="app/shared/validator2.directive.ts">
|
||||
<code-example path="styleguide/src/06-03/app/shared/validator2.directive.ts" header="app/shared/validator2.directive.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4593,7 +4593,7 @@ Compare with the less preferred `host` metadata alternative.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/07-01/app/heroes/shared/hero.service.ts" region="example" title="app/heroes/shared/hero.service.ts">
|
||||
<code-example path="styleguide/src/07-01/app/heroes/shared/hero.service.ts" region="example" header="app/heroes/shared/hero.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4697,7 +4697,7 @@ Compare with the less preferred `host` metadata alternative.
|
||||
|
||||
|
||||
|
||||
**Why?** When you register a service in the `@Injectable` decorator of the service, optimization tools such as those used by the CLI's production builds can perform tree shaking and remove services that aren't used by your app.
|
||||
**Why?** When you register a service in the `@Injectable` decorator of the service, optimization tools such as those used by the [Angular CLI's](cli) production builds can perform tree shaking and remove services that aren't used by your app.
|
||||
|
||||
</div>
|
||||
|
||||
@ -4712,7 +4712,7 @@ Compare with the less preferred `host` metadata alternative.
|
||||
|
||||
</div>
|
||||
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service.ts" title="src/app/treeshaking/service.ts" linenums="false"> </code-example>
|
||||
<code-example path="dependency-injection/src/app/tree-shaking/service.ts" header="src/app/treeshaking/service.ts" linenums="false"> </code-example>
|
||||
|
||||
|
||||
|
||||
@ -4760,7 +4760,7 @@ dependencies based on the declared types of that service's constructor parameter
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/07-04/app/heroes/shared/hero-arena.service.avoid.ts" region="example" title="app/heroes/shared/hero-arena.service.ts">
|
||||
<code-example path="styleguide/src/07-04/app/heroes/shared/hero-arena.service.avoid.ts" region="example" header="app/heroes/shared/hero-arena.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4768,7 +4768,7 @@ dependencies based on the declared types of that service's constructor parameter
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/07-04/app/heroes/shared/hero-arena.service.ts" region="example" title="app/heroes/shared/hero-arena.service.ts">
|
||||
<code-example path="styleguide/src/07-04/app/heroes/shared/hero-arena.service.ts" region="example" header="app/heroes/shared/hero-arena.service.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4884,7 +4884,7 @@ signatures. use those signatures to flag spelling and syntax mistakes.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/09-01/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" title="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/09-01/app/heroes/shared/hero-button/hero-button.component.avoid.ts" region="example" header="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -4892,7 +4892,7 @@ signatures. use those signatures to flag spelling and syntax mistakes.
|
||||
|
||||
|
||||
|
||||
<code-example path="styleguide/src/09-01/app/heroes/shared/hero-button/hero-button.component.ts" region="example" title="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
<code-example path="styleguide/src/09-01/app/heroes/shared/hero-button/hero-button.component.ts" region="example" header="app/heroes/shared/hero-button/hero-button.component.ts">
|
||||
|
||||
</code-example>
|
||||
|
||||
|
@ -46,12 +46,12 @@ Begin with the first form of data binding—interpolation—to see how m
|
||||
|
||||
You met the double-curly braces of interpolation, `{{` and `}}`, early in your Angular education.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="first-interpolation" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="first-interpolation" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You use interpolation to weave calculated strings into the text between HTML element tags and within attribute assignments.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="title+image" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="title+image" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The text between the braces is often the name of a component property. Angular replaces that name with the
|
||||
@ -61,12 +61,12 @@ and "fills in the blanks", first displaying a bold application title and then a
|
||||
More generally, the text between the braces is a **template expression** that Angular first **evaluates**
|
||||
and then **converts to a string**. The following interpolation illustrates the point by adding the two numbers:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="sum-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="sum-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The expression can invoke methods of the host component such as `getVal()`, seen here:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="sum-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="sum-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Angular evaluates all expressions in double curly braces,
|
||||
@ -120,14 +120,14 @@ The *expression context* is typically the _component_ instance.
|
||||
In the following snippets, the `title` within double-curly braces and the
|
||||
`isUnchanged` in quotes refer to properties of the `AppComponent`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-component-expression" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-component-expression" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
An expression may also refer to properties of the _template's_ context
|
||||
such as a [template input variable](guide/template-syntax#template-input-variable) (`let hero`)
|
||||
or a [template reference variable](guide/template-syntax#ref-vars) (`#heroInput`).
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-var" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-var" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The context for terms in an expression is a blend of the _template variables_,
|
||||
@ -215,7 +215,7 @@ such as an element, component, or directive.
|
||||
You'll see template statements in the [event binding](guide/template-syntax#event-binding) section,
|
||||
appearing in quotes to the right of the `=` symbol as in `(event)="statement"`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-component-statement" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-component-statement" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
A template statement *has a side effect*.
|
||||
@ -246,7 +246,7 @@ such as an event handling method of the component instance.
|
||||
The *statement context* is typically the component instance.
|
||||
The *deleteHero* in `(click)="deleteHero()"` is a method of the data-bound component.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-component-statement" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-component-statement" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The statement context may also refer to properties of the template's own context.
|
||||
@ -255,7 +255,7 @@ a [template input variable](guide/template-syntax#template-input-variable) (`let
|
||||
and a [template reference variable](guide/template-syntax#ref-vars) (`#heroForm`)
|
||||
are passed to an event handling method of the component.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-var-statement" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="context-var-statement" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Template context names take precedence over component context names.
|
||||
@ -384,7 +384,7 @@ It requires a new mental model.
|
||||
In the normal course of HTML development, you create a visual structure with HTML elements, and
|
||||
you modify those elements by setting element attributes with string constants.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="img+button" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="img+button" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You still create a structure and initialize attribute values this way in Angular templates.
|
||||
@ -392,14 +392,14 @@ You still create a structure and initialize attribute values this way in Angular
|
||||
Then you learn to create new elements with components that encapsulate HTML
|
||||
and drop them into templates as if they were native HTML elements.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="hero-detail-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="hero-detail-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
That's HTML Plus.
|
||||
|
||||
Then you learn about data binding. The first binding you meet might look like this:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="disabled-button-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="disabled-button-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You'll get to that peculiar bracket notation in a moment. Looking beyond it,
|
||||
@ -512,7 +512,7 @@ The following table summarizes:
|
||||
Directive property
|
||||
</td>
|
||||
<td>
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-syntax-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-syntax-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
</td>
|
||||
</tr>
|
||||
@ -526,7 +526,7 @@ The following table summarizes:
|
||||
Directive event
|
||||
</td>
|
||||
<td>
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-syntax-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-syntax-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
</td>
|
||||
</tr>
|
||||
@ -538,7 +538,7 @@ The following table summarizes:
|
||||
Event and property
|
||||
</td>
|
||||
<td>
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="2-way-binding-syntax-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="2-way-binding-syntax-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
</td>
|
||||
</tr>
|
||||
@ -551,7 +551,7 @@ The following table summarizes:
|
||||
(the exception)
|
||||
</td>
|
||||
<td>
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="attribute-binding-syntax-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="attribute-binding-syntax-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
</td>
|
||||
</tr>
|
||||
@ -563,7 +563,7 @@ The following table summarizes:
|
||||
<code>class</code> property
|
||||
</td>
|
||||
<td>
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-syntax-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-syntax-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
</td>
|
||||
</tr>
|
||||
@ -575,7 +575,7 @@ The following table summarizes:
|
||||
<code>style</code> property
|
||||
</td>
|
||||
<td>
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="style-binding-syntax-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="style-binding-syntax-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
</td>
|
||||
</tr>
|
||||
@ -595,23 +595,23 @@ The binding sets the property to the value of a [template expression](guide/temp
|
||||
The most common property binding sets an element property to a component property value. An example is
|
||||
binding the `src` property of an image element to a component's `heroImageUrl` property:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Another example is disabling a button when the component says that it `isUnchanged`:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Another is setting a property of a directive:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Yet another is setting the model property of a custom component (a great way
|
||||
for parent and child components to communicate):
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-4" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-4" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### One-way *in*
|
||||
@ -641,12 +641,12 @@ See the API reference for
|
||||
An element property between enclosing square brackets identifies the target property.
|
||||
The target property in the following code is the image element's `src` property.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Some people prefer the `bind-` prefix alternative, known as the *canonical form*:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-5" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-5" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The target name is always the name of a property, even when it appears to be the name of something else.
|
||||
@ -656,7 +656,7 @@ Element properties may be the more common targets,
|
||||
but Angular looks first to see if the name is a property of a known directive,
|
||||
as it is in the following example:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -692,7 +692,7 @@ Return an object if the target property expects an object.
|
||||
|
||||
The `hero` property of the `HeroDetail` component expects a `Hero` object, which is exactly what you're sending in the property binding:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-4" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-4" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Remember the brackets
|
||||
@ -704,7 +704,7 @@ It does *not* evaluate the string!
|
||||
|
||||
Don't make the following mistake:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-6" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-6" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a one-time-initialization}
|
||||
@ -722,7 +722,7 @@ just as well for directive and component property initialization.
|
||||
The following example initializes the `prefix` property of the `HeroDetailComponent` to a fixed string,
|
||||
not a template expression. Angular sets it and forgets about it.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-7" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-7" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `[hero]` binding, on the other hand, remains a live binding to the component's `currentHero` property.
|
||||
@ -734,7 +734,7 @@ The `[hero]` binding, on the other hand, remains a live binding to the component
|
||||
You often have a choice between interpolation and property binding.
|
||||
The following binding pairs do the same thing:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-vs-interpolation" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-vs-interpolation" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
_Interpolation_ is a convenient alternative to _property binding_ in many cases.
|
||||
@ -750,7 +750,7 @@ When setting an element property to a non-string data value, you must use _prope
|
||||
|
||||
Imagine the following *malicious content*.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="evil-title" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="evil-title" header="src/app/app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Fortunately, Angular data binding is on alert for dangerous HTML.
|
||||
@ -758,7 +758,7 @@ It [*sanitizes*](guide/security#sanitization-and-security-contexts) the values b
|
||||
It **will not** allow HTML with script tags to leak into the browser, neither with interpolation
|
||||
nor property binding.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-vs-interpolation-sanitization" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="property-binding-vs-interpolation-sanitization" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Interpolation handles the script tags differently than property binding but both approaches render the
|
||||
@ -826,7 +826,7 @@ You then set the attribute value, using an expression that resolves to a string.
|
||||
|
||||
Bind `[attr.colspan]` to a calculated value:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="attrib-binding-colspan" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="attrib-binding-colspan" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here's how the table renders:
|
||||
@ -839,7 +839,7 @@ Here's how the table renders:
|
||||
One of the primary use cases for attribute binding
|
||||
is to set ARIA attributes, as in this example:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="attrib-binding-aria" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="attrib-binding-aria" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -857,19 +857,19 @@ optionally followed by a dot (`.`) and the name of a CSS class: `[class.class-na
|
||||
The following examples show how to add and remove the application's "special" class
|
||||
with class bindings. Here's how to set the attribute without binding:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You can replace that with a binding to a string of the desired class names; this is an all-or-nothing, replacement binding.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Finally, you can bind to a specific class name.
|
||||
Angular adds the class when the template expression evaluates to truthy.
|
||||
It removes the class when the expression is falsy.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -890,13 +890,13 @@ Style binding syntax resembles property binding.
|
||||
Instead of an element property between brackets, start with the prefix `style`,
|
||||
followed by a dot (`.`) and the name of a CSS style property: `[style.style-property]`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="style-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="style-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Some style binding styles have a unit extension.
|
||||
The following example conditionally sets the font size in “em” and “%” units .
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="style-binding-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="style-binding-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -936,7 +936,7 @@ within parentheses on the left of an equal sign, and a quoted
|
||||
The following event binding listens for the button's click events, calling
|
||||
the component's `onSave()` method whenever a click occurs:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Target event
|
||||
@ -944,18 +944,18 @@ the component's `onSave()` method whenever a click occurs:
|
||||
A **name between parentheses** — for example, `(click)` —
|
||||
identifies the target event. In the following example, the target is the button's click event.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Some people prefer the `on-` prefix alternative, known as the **canonical form**:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Element events may be the more common targets, but Angular looks first to see if the name matches an event property
|
||||
of a known directive, as it does in the following example:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -987,7 +987,7 @@ with properties such as `target` and `target.value`.
|
||||
|
||||
Consider this example:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="without-NgModel" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="without-NgModel" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
This code sets the input box `value` property by binding to the `name` property.
|
||||
@ -1017,10 +1017,10 @@ The best it can do is raise an event reporting the user's delete request.
|
||||
|
||||
Here are the pertinent excerpts from that `HeroDetailComponent`:
|
||||
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" linenums="false" title="src/app/hero-detail.component.ts (template)" region="template-1">
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" linenums="false" header="src/app/hero-detail.component.ts (template)" region="template-1">
|
||||
</code-example>
|
||||
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" linenums="false" title="src/app/hero-detail.component.ts (deleteRequest)" region="deleteRequest">
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" linenums="false" header="src/app/hero-detail.component.ts (deleteRequest)" region="deleteRequest">
|
||||
</code-example>
|
||||
|
||||
The component defines a `deleteRequest` property that returns an `EventEmitter`.
|
||||
@ -1029,7 +1029,7 @@ telling the `EventEmitter` to emit a `Hero` object.
|
||||
|
||||
Now imagine a hosting parent component that binds to the `HeroDetailComponent`'s `deleteRequest` event.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" title="src/app/app.component.html (event-binding-to-component)" region="event-binding-to-component">
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" header="src/app/app.component.html (event-binding-to-component)" region="event-binding-to-component">
|
||||
</code-example>
|
||||
|
||||
When the `deleteRequest` event fires, Angular calls the parent component's `deleteHero` method,
|
||||
@ -1075,7 +1075,7 @@ and a corresponding event named `xChange`.
|
||||
Here's a `SizerComponent` that fits the pattern.
|
||||
It has a `size` value property and a companion `sizeChange` event:
|
||||
|
||||
<code-example path="template-syntax/src/app/sizer.component.ts" title="src/app/sizer.component.ts">
|
||||
<code-example path="template-syntax/src/app/sizer.component.ts" header="src/app/sizer.component.ts">
|
||||
</code-example>
|
||||
|
||||
The initial `size` is an input value from a property binding.
|
||||
@ -1084,7 +1084,7 @@ and then raises (_emits_) the `sizeChange` event with the adjusted size.
|
||||
|
||||
Here's an example in which the `AppComponent.fontSizePx` is two-way bound to the `SizerComponent`:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" title="src/app/app.component.html (two-way-1)" region="two-way-1">
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" header="src/app/app.component.html (two-way-1)" region="two-way-1">
|
||||
</code-example>
|
||||
|
||||
The `AppComponent.fontSizePx` establishes the initial `SizerComponent.size` value.
|
||||
@ -1095,7 +1095,7 @@ making the displayed text bigger or smaller.
|
||||
The two-way binding syntax is really just syntactic sugar for a _property_ binding and an _event_ binding.
|
||||
Angular _desugars_ the `SizerComponent` binding into this:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" title="src/app/app.component.html (two-way-2)" region="two-way-2">
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" header="src/app/app.component.html (two-way-2)" region="two-way-2">
|
||||
</code-example>
|
||||
|
||||
The `$event` variable contains the payload of the `SizerComponent.sizeChange` event.
|
||||
@ -1123,7 +1123,7 @@ You don't need many of those directives in Angular.
|
||||
You can often achieve the same results with the more capable and expressive Angular binding system.
|
||||
Why create a directive to handle a click when you can write a simple binding such as this?
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="event-binding-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You still benefit from directives that simplify complex tasks.
|
||||
@ -1165,7 +1165,7 @@ You can bind to the `ngClass` to add or remove several classes simultaneously.
|
||||
|
||||
A [class binding](guide/template-syntax#class-binding) is a good way to add or remove a *single* class.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-3a" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="class-binding-3a" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
To add or remove *many* CSS classes at the same time, the `NgClass` directive may be the better choice.
|
||||
@ -1178,12 +1178,12 @@ Consider a `setCurrentClasses` component method that sets a component property,
|
||||
`currentClasses` with an object that adds or removes three classes based on the
|
||||
`true`/`false` state of three other component properties:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="setClasses" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="setClasses" header="src/app/app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Adding an `ngClass` property binding to `currentClasses` sets the element's classes accordingly:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgClass-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgClass-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1203,7 +1203,7 @@ With `NgStyle` you can set many inline styles simultaneously.
|
||||
|
||||
A [style binding](guide/template-syntax#style-binding) is an easy way to set a *single* style value.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgStyle-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgStyle-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
To set *many* inline styles at the same time, the `NgStyle` directive may be the better choice.
|
||||
@ -1214,12 +1214,12 @@ Each key of the object is a style name; its value is whatever is appropriate for
|
||||
Consider a `setCurrentStyles` component method that sets a component property, `currentStyles`
|
||||
with an object that defines three styles, based on the state of three other component properties:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="setStyles" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="setStyles" header="src/app/app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Adding an `ngStyle` property binding to `currentStyles` sets the element's styles accordingly:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgStyle-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgStyle-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1240,7 +1240,7 @@ update that property when the user makes changes.
|
||||
|
||||
Two-way data binding with the `NgModel` directive makes that easy. Here's an example:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" title="src/app/app.component.html (NgModel-1)" region="NgModel-1">
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" header="src/app/app.component.html (NgModel-1)" region="NgModel-1">
|
||||
</code-example>
|
||||
|
||||
#### _FormsModule_ is required to use _ngModel_
|
||||
@ -1252,7 +1252,7 @@ Learn more about the `FormsModule` and `ngModel` in the
|
||||
|
||||
Here's how to import the `FormsModule` to make `[(ngModel)]` available.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.module.1.ts" linenums="false" title="src/app/app.module.ts (FormsModule import)">
|
||||
<code-example path="template-syntax/src/app/app.module.1.ts" linenums="false" header="src/app/app.module.ts (FormsModule import)">
|
||||
</code-example>
|
||||
|
||||
#### Inside <span class="syntax">[(ngModel)]</span>
|
||||
@ -1261,7 +1261,7 @@ Looking back at the `name` binding, note that
|
||||
you could have achieved the same result with separate bindings to
|
||||
the `<input>` element's `value` property and `input` event.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="without-NgModel" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="without-NgModel" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
That's cumbersome. Who can remember which element property to set and which element event emits user changes?
|
||||
@ -1270,7 +1270,7 @@ Who wants to look that up each time?
|
||||
|
||||
That `ngModel` directive hides these onerous details behind its own `ngModel` input and `ngModelChange` output properties.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgModel-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgModel-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1302,7 +1302,7 @@ You shouldn't have to mention the data property twice. Angular should be able to
|
||||
the component's data property and set it
|
||||
with a single declaration, which it can with the `[(ngModel)]` syntax:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgModel-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgModel-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Is `[(ngModel)]` all you need? Is there ever a reason to fall back to its expanded form?
|
||||
@ -1312,7 +1312,7 @@ If you need to do something more or something different, you can write the expan
|
||||
|
||||
The following contrived example forces the input value to uppercase:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgModel-4" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgModel-4" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here are all variations in action, including the uppercase version:
|
||||
@ -1358,7 +1358,7 @@ You can add or remove an element from the DOM by applying an `NgIf` directive to
|
||||
that element (called the _host element_).
|
||||
Bind the directive to a condition expression like `isActive` in this example.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgIf-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgIf-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-critical">
|
||||
@ -1376,7 +1376,7 @@ from the DOM, destroying that component and all of its sub-components.
|
||||
You can control the visibility of an element with a
|
||||
[class](guide/template-syntax#class-binding) or [style](guide/template-syntax#style-binding) binding:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgIf-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgIf-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Hiding an element is quite different from removing an element with `NgIf`.
|
||||
@ -1404,7 +1404,7 @@ Here we see `NgIf` guarding two `<div>`s.
|
||||
The `currentHero` name will appear only when there is a `currentHero`.
|
||||
The `nullHero` will never be displayed.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgIf-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgIf-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1428,12 +1428,12 @@ You tell Angular to use that block as a template for rendering each item in the
|
||||
|
||||
Here is an example of `NgForOf` applied to a simple `<div>`:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You can also apply an `NgForOf` to a component element, as in this example:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-critical">
|
||||
@ -1476,7 +1476,7 @@ You reference the `hero` input variable within the `NgForOf` host element
|
||||
Here it is referenced first in an interpolation
|
||||
and then passed in a binding to the `hero` property of the `<hero-detail>` component.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-1-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-1-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Learn more about _template input variables_ in the
|
||||
@ -1489,7 +1489,7 @@ You can capture the `index` in a template input variable and use it in the templ
|
||||
|
||||
The next example captures the `index` in a variable named `i` and displays it with the hero name like this.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgFor-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1517,12 +1517,12 @@ Angular can avoid this churn with `trackBy`.
|
||||
Add a method to the component that returns the value `NgForOf` _should_ track.
|
||||
In this case, that value is the hero's `id`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="trackByHeroes" title="src/app/app.component.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.ts" region="trackByHeroes" header="src/app/app.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
In the microsyntax expression, set `trackBy` to this method.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="trackBy" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="trackBy" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here is an illustration of the _trackBy_ effect.
|
||||
@ -1550,7 +1550,7 @@ Angular puts only the *selected* element into the DOM.
|
||||
*NgSwitch* is actually a set of three, cooperating directives:
|
||||
`NgSwitch`, `NgSwitchCase`, and `NgSwitchDefault` as seen in this example.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgSwitch" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgSwitch" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<figure>
|
||||
@ -1580,7 +1580,7 @@ which is bound to the `currentHero` of the parent component.
|
||||
Switch directives work as well with native elements and web components too.
|
||||
For example, you could replace the `<confused-hero>` switch case with the following.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgSwitch-div" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="NgSwitch-div" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<hr/>
|
||||
@ -1600,14 +1600,14 @@ It can also be a reference to an Angular component or directive or a
|
||||
Use the hash symbol (#) to declare a reference variable.
|
||||
The `#phone` declares a `phone` variable on an `<input>` element.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="ref-var" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="ref-var" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You can refer to a template reference variable _anywhere_ in the template.
|
||||
The `phone` variable declared on this `<input>` is
|
||||
consumed in a `<button>` on the other side of the template
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="ref-phone" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="ref-phone" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<h3 class="no-toc">How a reference variable gets its value</h3>
|
||||
@ -1620,7 +1620,7 @@ The `NgForm` directive does that.
|
||||
|
||||
The following is a *simplified* version of the form example in the [Forms](guide/forms) guide.
|
||||
|
||||
<code-example path="template-syntax/src/app/hero-form.component.html" title="src/app/hero-form.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/hero-form.component.html" header="src/app/hero-form.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
A template reference variable, `heroForm`, appears three times in this example, separated
|
||||
@ -1650,7 +1650,7 @@ The runtime value will be unpredictable.
|
||||
You can use the `ref-` prefix alternative to `#`.
|
||||
This example declares the `fax` variable as `ref-fax` instead of `#fax`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="ref-fax" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="ref-fax" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
@ -1682,7 +1682,7 @@ because this topic is mostly a concern for component authors.
|
||||
You are usually binding a template to its _own component class_.
|
||||
In such binding expressions, the component's property or method is to the _right_ of the (`=`).
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="io-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="io-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `iconUrl` and `onSave` are members of the `AppComponent` class.
|
||||
@ -1704,7 +1704,7 @@ In such bindings, the _other_ component's property is to the _left_ of the (`=`)
|
||||
|
||||
In the following example, the `AppComponent` template binds `AppComponent` class members to properties of the `HeroDetailComponent` whose selector is `'app-hero-detail'`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="io-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="io-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The Angular compiler _may_ reject these bindings with errors like this one:
|
||||
@ -1753,7 +1753,7 @@ That _other way_ is the `@Input()` and `@Output()` decorators.
|
||||
In the sample for this guide, the bindings to `HeroDetailComponent` do not fail
|
||||
because the data bound properties are annotated with `@Input()` and `@Output()` decorators.
|
||||
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" region="input-output-1" title="src/app/hero-detail.component.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" region="input-output-1" header="src/app/hero-detail.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1761,7 +1761,7 @@ because the data bound properties are annotated with `@Input()` and `@Output()`
|
||||
Alternatively, you can identify members in the `inputs` and `outputs` arrays
|
||||
of the directive metadata, as in this example:
|
||||
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" region="input-output-2" title="src/app/hero-detail.component.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/hero-detail.component.ts" region="input-output-2" header="src/app/hero-detail.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
</div>
|
||||
@ -1794,7 +1794,7 @@ Directive consumers expect to bind to the name of the directive.
|
||||
For example, when you apply a directive with a `myClick` selector to a `<div>` tag,
|
||||
you expect to bind to an event property that is also called `myClick`.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="myClick" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="myClick" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
However, the directive name is often a poor choice for the name of a property within the directive class.
|
||||
@ -1808,7 +1808,7 @@ the directive's own `clicks` property.
|
||||
|
||||
You can specify the alias for the property name by passing it into the input/output decorator like this:
|
||||
|
||||
<code-example path="template-syntax/src/app/click.directive.ts" region="output-myClick" title="src/app/click.directive.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/click.directive.ts" region="output-myClick" header="src/app/click.directive.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1817,7 +1817,7 @@ You can also alias property names in the `inputs` and `outputs` arrays.
|
||||
You write a colon-delimited (`:`) string with
|
||||
the directive property name on the *left* and the public alias on the *right*:
|
||||
|
||||
<code-example path="template-syntax/src/app/click.directive.ts" region="output-myClick2" title="src/app/click.directive.ts" linenums="false">
|
||||
<code-example path="template-syntax/src/app/click.directive.ts" region="output-myClick2" header="src/app/click.directive.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
</div>
|
||||
@ -1843,24 +1843,24 @@ Angular [pipes](guide/pipes) are a good choice for small transformations such as
|
||||
Pipes are simple functions that accept an input value and return a transformed value.
|
||||
They're easy to apply within template expressions, using the **pipe operator (`|`)**:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="pipes-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="pipes-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The pipe operator passes the result of an expression on the left to a pipe function on the right.
|
||||
|
||||
You can chain expressions through multiple pipes:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="pipes-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="pipes-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
And you can also [apply parameters](guide/pipes#parameterizing-a-pipe) to a pipe:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="pipes-3" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="pipes-3" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `json` pipe is particularly helpful for debugging bindings:
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" title="src/app/app.component.html (pipes-json)" region="pipes-json">
|
||||
<code-example path="template-syntax/src/app/app.component.html" linenums="false" header="src/app/app.component.html (pipes-json)" region="pipes-json">
|
||||
</code-example>
|
||||
|
||||
The generated output would look something like this
|
||||
@ -1883,12 +1883,12 @@ The Angular **safe navigation operator (`?.`)** is a fluent and convenient way t
|
||||
guard against null and undefined values in property paths.
|
||||
Here it is, protecting against a view render failure if the `currentHero` is null.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
What happens when the following data bound `title` property is null?
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The view still renders but the displayed value is blank; you see only "The title is" with nothing after it.
|
||||
@ -1924,13 +1924,13 @@ Unfortunately, the app crashes when the `currentHero` is null.
|
||||
|
||||
You could code around that problem with [*ngIf](guide/template-syntax#ngIf).
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-4" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-4" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You could try to chain parts of the property path with `&&`, knowing that the expression bails out
|
||||
when it encounters the first null.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-5" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-5" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
These approaches have merit but can be cumbersome, especially if the property path is long.
|
||||
@ -1940,7 +1940,7 @@ The Angular safe navigation operator (`?.`) is a more fluent and convenient way
|
||||
The expression bails out when it hits the first null value.
|
||||
The display is blank, but the app keeps rolling without errors.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-6" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="safe-6" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
It works perfectly with long property paths such as `a?.b?.c?.d`.
|
||||
@ -1966,7 +1966,7 @@ The _Angular_ **non-null assertion operator (`!`)** serves the same purpose in a
|
||||
For example, after you use [*ngIf](guide/template-syntax#ngIf) to check that `hero` is defined, you can assert that
|
||||
`hero` properties are also defined.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="non-null-assertion-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="non-null-assertion-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
When the Angular compiler turns your template into TypeScript code,
|
||||
@ -1991,7 +1991,7 @@ Sometimes a binding expression will be reported as a type error and it is not po
|
||||
to fully specify the type. To silence the error, you can use the `$any` cast function to cast
|
||||
the expression to [the `any` type](http://www.typescriptlang.org/docs/handbook/basic-types.html#any).
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="any-type-cast-function-1" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="any-type-cast-function-1" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
In this example, when the Angular compiler turns your template into TypeScript code,
|
||||
@ -2001,7 +2001,7 @@ interface.
|
||||
The `$any` cast function can be used in conjunction with `this` to allow access to undeclared members of
|
||||
the component.
|
||||
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="any-type-cast-function-2" title="src/app/app.component.html" linenums="false">
|
||||
<code-example path="template-syntax/src/app/app.component.html" region="any-type-cast-function-2" header="src/app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `$any` cast function can be used anywhere in a binding expression where a method call is valid.
|
||||
|
@ -3,7 +3,7 @@
|
||||
|
||||
This guide offers tips and techniques for unit and integration testing Angular applications.
|
||||
|
||||
The guide presents tests of a sample CLI application that is much like the [_Tour of Heroes_ tutorial](tutorial).
|
||||
The guide presents tests of a sample application created with the [Angular CLI](cli). This sample application is much like the one created in the [_Tour of Heroes_ tutorial](tutorial).
|
||||
The sample application and all tests in this guide are available for inspection and experimentation:
|
||||
|
||||
- <live-example embedded-style>Sample app</live-example>
|
||||
@ -16,14 +16,14 @@ The sample application and all tests in this guide are available for inspection
|
||||
The Angular CLI downloads and install everything you need to test an Angular application with the [Jasmine test framework](https://jasmine.github.io/).
|
||||
|
||||
The project you create with the CLI is immediately ready to test.
|
||||
Just run this one CLI command:
|
||||
Just run the [`ng test`](cli/test) CLI command:
|
||||
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng test
|
||||
</code-example>
|
||||
|
||||
The `ng test` command builds the app in _watch mode_,
|
||||
and launches the [karma test runner](https://karma-runner.github.io/1.0/index.html).
|
||||
and launches the [karma test runner](https://karma-runner.github.io).
|
||||
|
||||
The console output looks a bit like this:
|
||||
|
||||
@ -120,21 +120,19 @@ jobs:
|
||||
steps:
|
||||
- checkout
|
||||
- restore_cache:
|
||||
key: my-project-{{ .Branch }}-{{ checksum "package.json" }}
|
||||
key: my-project-{{ .Branch }}-{{ checksum "package-lock.json" }}
|
||||
- run: npm install
|
||||
- save_cache:
|
||||
key: my-project-{{ .Branch }}-{{ checksum "package.json" }}
|
||||
key: my-project-{{ .Branch }}-{{ checksum "package-lock.json" }}
|
||||
paths:
|
||||
- "node_modules"
|
||||
- run: xvfb-run -a npm run test -- --single-run --no-progress --browser=ChromeNoSandbox
|
||||
- run: xvfb-run -a npm run e2e -- --no-progress --config=protractor-ci.conf.js
|
||||
- run: npm run test -- --single-run --no-progress --browser=ChromeHeadlessCI
|
||||
- run: npm run e2e -- --no-progress --config=protractor-ci.conf.js
|
||||
```
|
||||
|
||||
This configuration caches `node_modules/` and uses [`npm run`](https://docs.npmjs.com/cli/run-script) to run CLI commands, because `@angular/cli` is not installed globally.
|
||||
The double dash (`--`) is needed to pass arguments into the `npm` script.
|
||||
|
||||
For Chrome, it uses `xvfb-run` to run the `npm run` command using a virtual screen.
|
||||
|
||||
Step 3: Commit your changes and push them to your repository.
|
||||
|
||||
Step 4: [Sign up for Circle CI](https://circleci.com/docs/2.0/first-steps/) and [add your project](https://circleci.com/add-projects).
|
||||
@ -169,10 +167,8 @@ install:
|
||||
- npm install
|
||||
|
||||
script:
|
||||
# Use Chromium instead of Chrome.
|
||||
- export CHROME_BIN=chromium-browser
|
||||
- xvfb-run -a npm run test -- --single-run --no-progress --browser=ChromeNoSandbox
|
||||
- xvfb-run -a npm run e2e -- --no-progress --config=protractor-ci.conf.js
|
||||
- npm run test -- --single-run --no-progress --browser=ChromeHeadlessCI
|
||||
- npm run e2e -- --no-progress --config=protractor-ci.conf.js
|
||||
```
|
||||
|
||||
This does the same things as the Circle CI configuration, except that Travis doesn't come with Chrome, so we use Chromium instead.
|
||||
@ -188,16 +184,18 @@ You'll need to push a new commit to trigger a build.
|
||||
|
||||
When the CLI commands `ng test` and `ng e2e` are generally running the CI tests in your environment, you might still need to adjust your configuration to run the Chrome browser tests.
|
||||
|
||||
There are configuration files for both the [Karma JavaScript test runner](http://karma-runner.github.io/2.0/config/configuration-file.html)
|
||||
There are configuration files for both the [Karma JavaScript test runner](https://karma-runner.github.io/latest/config/configuration-file.html)
|
||||
and [Protractor](https://www.protractortest.org/#/api-overview) end-to-end testing tool,
|
||||
which you must adjust to start Chrome without sandboxing.
|
||||
|
||||
We'll be using [Headless Chrome](https://developers.google.com/web/updates/2017/04/headless-chrome#cli) in these examples.
|
||||
|
||||
* In the Karma configuration file, `karma.conf.js`, add a custom launcher called ChromeNoSandbox below browsers:
|
||||
```
|
||||
browsers: ['Chrome'],
|
||||
customLaunchers: {
|
||||
ChromeNoSandbox: {
|
||||
base: 'Chrome',
|
||||
ChromeHeadlessCI: {
|
||||
base: 'ChromeHeadless',
|
||||
flags: ['--no-sandbox']
|
||||
}
|
||||
},
|
||||
@ -210,7 +208,7 @@ const config = require('./protractor.conf').config;
|
||||
config.capabilities = {
|
||||
browserName: 'chrome',
|
||||
chromeOptions: {
|
||||
args: ['--no-sandbox']
|
||||
args: ['--headless', '--no-sandbox']
|
||||
}
|
||||
};
|
||||
|
||||
@ -219,10 +217,16 @@ exports.config = config;
|
||||
|
||||
Now you can run the following commands to use the `--no-sandbox` flag:
|
||||
|
||||
```
|
||||
ng test --single-run --no-progress --browser=ChromeNoSandbox
|
||||
ng e2e --no-progress --config=protractor-ci.conf.js
|
||||
```
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng test --single-run --no-progress --browser=ChromeHeadlessCI
|
||||
ng e2e --no-progress --config=protractor-ci.conf.js
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
**Note:** Right now, you'll also want to include the `--disable-gpu` flag if you're running on Windows. See [crbug.com/737678](https://crbug.com/737678).
|
||||
|
||||
</div>
|
||||
|
||||
{@a code-coverage}
|
||||
|
||||
@ -233,9 +237,9 @@ Code coverage reports show you any parts of our code base that may not be prope
|
||||
|
||||
To generate a coverage report run the following command in the root of your project.
|
||||
|
||||
```
|
||||
ng test --watch=false --code-coverage
|
||||
```
|
||||
<code-example language="sh" class="code-shell">
|
||||
ng test --watch=false --code-coverage
|
||||
</code-example>
|
||||
|
||||
When the tests are complete, the command creates a new `/coverage` folder in the project. Open the `index.html` file to see a report with your source code and code coverage values.
|
||||
|
||||
@ -255,7 +259,7 @@ The code coverage percentages let you estimate how much of your code is tested.
|
||||
If your team decides on a set minimum amount to be unit tested, you can enforce this minimum with the Angular CLI.
|
||||
|
||||
For example, suppose you want the code base to have a minimum of 80% code coverage.
|
||||
To enable this, open the [Karma](http://karma-runner.github.io/0.13/index.html) test platform configuration file, `karma.conf.js`, and add the following in the `coverageIstanbulReporter:` key.
|
||||
To enable this, open the [Karma](https://karma-runner.github.io) test platform configuration file, `karma.conf.js`, and add the following in the `coverageIstanbulReporter:` key.
|
||||
|
||||
```
|
||||
coverageIstanbulReporter: {
|
||||
@ -278,7 +282,7 @@ Services are often the easiest files to unit test.
|
||||
Here are some synchronous and asynchronous unit tests of the `ValueService`
|
||||
written without assistance from Angular testing utilities.
|
||||
|
||||
<code-example path="testing/src/app/demo/demo.spec.ts" region="ValueService" title="app/demo/demo.spec.ts"></code-example>
|
||||
<code-example path="testing/src/app/demo/demo.spec.ts" region="ValueService" header="app/demo/demo.spec.ts"></code-example>
|
||||
|
||||
{@a services-with-dependencies}
|
||||
|
||||
@ -290,13 +294,13 @@ calling the service's constructor.
|
||||
|
||||
The `MasterService` is a simple example:
|
||||
|
||||
<code-example path="testing/src/app/demo/demo.ts" region="MasterService" title="app/demo/demo.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/demo/demo.ts" region="MasterService" header="app/demo/demo.ts" linenums="false"></code-example>
|
||||
|
||||
`MasterService` delegates its only method, `getValue`, to the injected `ValueService`.
|
||||
|
||||
Here are several ways to test it.
|
||||
|
||||
<code-example path="testing/src/app/demo/demo.spec.ts" region="MasterService" title="app/demo/demo.spec.ts"></code-example>
|
||||
<code-example path="testing/src/app/demo/demo.spec.ts" region="MasterService" header="app/demo/demo.spec.ts"></code-example>
|
||||
|
||||
The first test creates a `ValueService` with `new` and passes it to the `MasterService` constructor.
|
||||
|
||||
@ -348,7 +352,7 @@ array of the services that you'll test or mock.
|
||||
<code-example
|
||||
path="testing/src/app/demo/demo.testbed.spec.ts"
|
||||
region="value-service-before-each"
|
||||
title="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach">
|
||||
header="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach">
|
||||
</code-example>
|
||||
|
||||
Then inject it inside a test by calling `TestBed.get()` with the service class as the argument.
|
||||
@ -396,7 +400,7 @@ Begin by putting re-usable, preparatory code in a _setup_ function instead of `b
|
||||
<code-example
|
||||
path="testing/src/app/demo/demo.spec.ts"
|
||||
region="no-before-each-setup"
|
||||
title="app/demo/demo.spec.ts (setup)" linenums="false">
|
||||
header="app/demo/demo.spec.ts (setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `setup()` function returns an object literal
|
||||
@ -425,7 +429,7 @@ Many developers feel this approach is cleaner and more explicit than the
|
||||
traditional `beforeEach()` style.
|
||||
|
||||
Although this testing guide follows the tradition style and
|
||||
the default [CLI schematics](https://github.com/angular/devkit)
|
||||
the default [CLI schematics](https://github.com/angular/angular-cli)
|
||||
generate test files with `beforeEach()` and `TestBed`,
|
||||
feel free to adopt _this alternative approach_ in your own projects.
|
||||
|
||||
@ -439,7 +443,7 @@ test any service with a dependency.
|
||||
<code-example
|
||||
path="testing/src/app/model/hero.service.spec.ts"
|
||||
region="test-with-spies"
|
||||
title="app/model/hero.service.spec.ts (tests with spies)">
|
||||
header="app/model/hero.service.spec.ts (tests with spies)">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-important">
|
||||
@ -500,7 +504,7 @@ Consider this `LightswitchComponent` which toggles a light on and off
|
||||
<code-example
|
||||
path="testing/src/app/demo/demo.ts"
|
||||
region="LightswitchComp"
|
||||
title="app/demo/demo.ts (LightswitchComp)" linenums="false">
|
||||
header="app/demo/demo.ts (LightswitchComp)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You might decide only to test that the `clicked()` method
|
||||
@ -514,7 +518,7 @@ Do the same with the component class.
|
||||
<code-example
|
||||
path="testing/src/app/demo/demo.spec.ts"
|
||||
region="Lightswitch"
|
||||
title="app/demo/demo.spec.ts (Lightswitch tests)" linenums="false">
|
||||
header="app/demo/demo.spec.ts (Lightswitch tests)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here is the `DashboardHeroComponent` from the _Tour of Heroes_ tutorial.
|
||||
@ -522,7 +526,7 @@ Here is the `DashboardHeroComponent` from the _Tour of Heroes_ tutorial.
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.ts"
|
||||
region="class"
|
||||
title="app/dashboard/dashboard-hero.component.ts (component)" linenums="false">
|
||||
header="app/dashboard/dashboard-hero.component.ts (component)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
It appears within the template of a parent component,
|
||||
@ -535,7 +539,7 @@ or its parent component.
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
|
||||
region="class-only"
|
||||
title="app/dashboard/dashboard-hero.component.spec.ts (class tests)" linenums="false">
|
||||
header="app/dashboard/dashboard-hero.component.spec.ts (class tests)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
When a component has dependencies, you may wish to use the `TestBed` to both
|
||||
@ -546,7 +550,7 @@ The following `WelcomeComponent` depends on the `UserService` to know the name o
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.ts"
|
||||
region="class"
|
||||
title="app/welcome/welcome.component.ts" linenums="false">
|
||||
header="app/welcome/welcome.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You might start by creating a mock of the `UserService` that meets the minimum needs of this component.
|
||||
@ -554,7 +558,7 @@ You might start by creating a mock of the `UserService` that meets the minimum n
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.spec.ts"
|
||||
region="mock-user-service"
|
||||
title="app/welcome/welcome.component.spec.ts (MockUserService)" linenums="false">
|
||||
header="app/welcome/welcome.component.spec.ts (MockUserService)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Then provide and inject _both the_ **component** _and the service_ in the `TestBed` configuration.
|
||||
@ -562,7 +566,7 @@ Then provide and inject _both the_ **component** _and the service_ in the `TestB
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.spec.ts"
|
||||
region="class-only-before-each"
|
||||
title="app/welcome/welcome.component.spec.ts (class-only setup)" linenums="false">
|
||||
header="app/welcome/welcome.component.spec.ts (class-only setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Then exercise the component class, remembering to call the [lifecycle hook methods](guide/lifecycle-hooks) as Angular does when running the app.
|
||||
@ -570,7 +574,7 @@ Then exercise the component class, remembering to call the [lifecycle hook metho
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.spec.ts"
|
||||
region="class-only-tests"
|
||||
title="app/welcome/welcome.component.spec.ts (class-only tests)" linenums="false">
|
||||
header="app/welcome/welcome.component.spec.ts (class-only tests)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Component DOM testing
|
||||
@ -622,7 +626,7 @@ It also generates an initial test file for the component, `banner-external.compo
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-initial.component.spec.ts"
|
||||
region="v1"
|
||||
title="app/banner/banner-external.component.spec.ts (initial)" linenums="false">
|
||||
header="app/banner/banner-external.component.spec.ts (initial)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
#### Reduce the setup
|
||||
@ -638,7 +642,7 @@ For now, you can radically reduce this test file to a more manageable size:
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-initial.component.spec.ts"
|
||||
region="v2"
|
||||
title="app/banner/banner-initial.component.spec.ts (minimal)" linenums="false">
|
||||
header="app/banner/banner-initial.component.spec.ts (minimal)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
In this example, the metadata object passed to `TestBed.configureTestingModule`
|
||||
@ -856,7 +860,7 @@ the component's `title` property like this.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner.component.ts"
|
||||
region="component"
|
||||
title="app/banner/banner.component.ts" linenums="false">
|
||||
header="app/banner/banner.component.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Simple as this is, you decide to add a test to confirm that component
|
||||
@ -873,7 +877,7 @@ and assign it to the `h1` variable.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner.component.spec.ts"
|
||||
region="setup"
|
||||
title="app/banner/banner.component.spec.ts (setup)" linenums="false">
|
||||
header="app/banner/banner.component.spec.ts (setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a detect-changes}
|
||||
@ -938,15 +942,15 @@ Some testers prefer that the Angular test environment run change detection autom
|
||||
That's possible by configuring the `TestBed` with the `ComponentFixtureAutoDetect` provider.
|
||||
First import it from the testing utility library:
|
||||
|
||||
<code-example path="testing/src/app/banner/banner.component.detect-changes.spec.ts" region="import-ComponentFixtureAutoDetect" title="app/banner/banner.component.detect-changes.spec.ts (import)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/banner/banner.component.detect-changes.spec.ts" region="import-ComponentFixtureAutoDetect" header="app/banner/banner.component.detect-changes.spec.ts (import)" linenums="false"></code-example>
|
||||
|
||||
Then add it to the `providers` array of the testing module configuration:
|
||||
|
||||
<code-example path="testing/src/app/banner/banner.component.detect-changes.spec.ts" region="auto-detect" title="app/banner/banner.component.detect-changes.spec.ts (AutoDetect)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/banner/banner.component.detect-changes.spec.ts" region="auto-detect" header="app/banner/banner.component.detect-changes.spec.ts (AutoDetect)" linenums="false"></code-example>
|
||||
|
||||
Here are three tests that illustrate how automatic change detection works.
|
||||
|
||||
<code-example path="testing/src/app/banner/banner.component.detect-changes.spec.ts" region="auto-detect-tests" title="app/banner/banner.component.detect-changes.spec.ts (AutoDetect Tests)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/banner/banner.component.detect-changes.spec.ts" region="auto-detect-tests" header="app/banner/banner.component.detect-changes.spec.ts (AutoDetect Tests)" linenums="false"></code-example>
|
||||
|
||||
The first test shows the benefit of automatic change detection.
|
||||
|
||||
@ -981,7 +985,7 @@ _Then_ you call `detectChanges()`.
|
||||
|
||||
The following example demonstrates the proper sequence.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="title-case-pipe" title="app/hero/hero-detail.component.spec.ts (pipe test)"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="title-case-pipe" header="app/hero/hero-detail.component.spec.ts (pipe test)"></code-example>
|
||||
|
||||
<hr>
|
||||
|
||||
@ -996,7 +1000,7 @@ as the following variant of `BannerComponent` does.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-external.component.ts"
|
||||
region="metadata"
|
||||
title="app/banner/banner-external.component.ts (metadata)" linenums="false">
|
||||
header="app/banner/banner-external.component.ts (metadata)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
This syntax tells the Angular compiler to read the external files during component compilation.
|
||||
@ -1006,7 +1010,7 @@ _compiles the app before running the tests_.
|
||||
|
||||
However, if you run the tests in a **non-CLI environment**,
|
||||
tests of this component may fail.
|
||||
For example, if you run the `BannerComponent` tests in a web coding environment such as [plunker](http://plnkr.co/), you'll see a message like this one:
|
||||
For example, if you run the `BannerComponent` tests in a web coding environment such as [plunker](https://plnkr.co/), you'll see a message like this one:
|
||||
|
||||
<code-example language="sh" class="code-shell" hideCopy>
|
||||
Error: This test module uses the component BannerComponent
|
||||
@ -1028,12 +1032,12 @@ Components often have service dependencies.
|
||||
The `WelcomeComponent` displays a welcome message to the logged in user.
|
||||
It knows who the user is based on a property of the injected `UserService`:
|
||||
|
||||
<code-example path="testing/src/app/welcome/welcome.component.ts" title="app/welcome/welcome.component.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/welcome/welcome.component.ts" header="app/welcome/welcome.component.ts" linenums="false"></code-example>
|
||||
|
||||
The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
|
||||
Here's the testing module configuration for the spec file, `app/welcome/welcome.component.spec.ts`:
|
||||
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="config-test-module" title="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="config-test-module" header="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
|
||||
This time, in addition to declaring the _component-under-test_,
|
||||
the configuration adds a `UserService` provider to the `providers` list.
|
||||
@ -1060,7 +1064,7 @@ and its tests:
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.spec.ts"
|
||||
region="user-service-stub"
|
||||
title="app/welcome/welcome.component.spec.ts" linenums="false">
|
||||
header="app/welcome/welcome.component.spec.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a get-injected-service}
|
||||
@ -1080,7 +1084,7 @@ The component injector is a property of the fixture's `DebugElement`.
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.spec.ts"
|
||||
region="injected-service"
|
||||
title="WelcomeComponent's injector">
|
||||
header="WelcomeComponent's injector">
|
||||
</code-example>
|
||||
|
||||
{@a testbed-get}
|
||||
@ -1097,7 +1101,7 @@ so it is safe to call `TestBed.get()` as follows:
|
||||
<code-example
|
||||
path="testing/src/app/welcome/welcome.component.spec.ts"
|
||||
region="inject-from-testbed"
|
||||
title="TestBed injector">
|
||||
header="TestBed injector">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1118,7 +1122,7 @@ that's provided to the testing module in the body of your test.
|
||||
The `userService` instance injected into the component is a completely _different_ object,
|
||||
a clone of the provided `userServiceStub`.
|
||||
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="stub-not-injected" title="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="stub-not-injected" header="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
|
||||
{@a welcome-spec-setup}
|
||||
|
||||
@ -1126,11 +1130,11 @@ a clone of the provided `userServiceStub`.
|
||||
|
||||
Here's the complete `beforeEach()`, using `TestBed.get()`:
|
||||
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="setup" title="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="setup" header="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
|
||||
And here are some tests:
|
||||
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="tests" title="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/welcome/welcome.component.spec.ts" region="tests" header="app/welcome/welcome.component.spec.ts" linenums="false"></code-example>
|
||||
|
||||
The first is a sanity test; it confirms that the stubbed `UserService` is called and working.
|
||||
|
||||
@ -1158,7 +1162,7 @@ The `TwainComponent` displays Mark Twain quotes.
|
||||
<code-example
|
||||
path="testing/src/app/twain/twain.component.ts"
|
||||
region="template"
|
||||
title="app/twain/twain.component.ts (template)" linenums="false">
|
||||
header="app/twain/twain.component.ts (template)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Note that value of the component's `quote` property passes through an `AsyncPipe`.
|
||||
@ -1170,7 +1174,7 @@ the `quote` property returns an `Observable`.
|
||||
<code-example
|
||||
path="testing/src/app/twain/twain.component.ts"
|
||||
region="get-quote"
|
||||
title="app/twain/twain.component.ts (getQuote)" linenums="false">
|
||||
header="app/twain/twain.component.ts (getQuote)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `TwainComponent` gets quotes from an injected `TwainService`.
|
||||
@ -1193,7 +1197,7 @@ They should emulate such calls. The setup in this `app/twain/twain.component.spe
|
||||
<code-example
|
||||
path="testing/src/app/twain/twain.component.spec.ts"
|
||||
region="setup"
|
||||
title="app/twain/twain.component.spec.ts (setup)" linenums="false">
|
||||
header="app/twain/twain.component.spec.ts (setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a service-spy}
|
||||
@ -1326,11 +1330,11 @@ If you run other `macroTask` such as `HTMLCanvasElement.toBlob()`, `Unknown macr
|
||||
<code-tabs>
|
||||
<code-pane
|
||||
path="testing/src/app/shared/canvas.component.spec.ts"
|
||||
title="src/app/shared/canvas.component.spec.ts" linenums="false">
|
||||
header="src/app/shared/canvas.component.spec.ts" linenums="false">
|
||||
</code-pane>
|
||||
<code-pane
|
||||
path="testing/src/app/shared/canvas.component.ts"
|
||||
title="src/app/shared/canvas.component.ts" linenums="false">
|
||||
header="src/app/shared/canvas.component.ts" linenums="false">
|
||||
</code-pane>
|
||||
</code-tabs>
|
||||
|
||||
@ -1385,7 +1389,7 @@ Or you can copy this one from the sample code.
|
||||
<code-example
|
||||
path="testing/src/testing/async-observable-helpers.ts"
|
||||
region="async-data"
|
||||
title="testing/async-observable-helpers.ts">
|
||||
header="testing/async-observable-helpers.ts">
|
||||
</code-example>
|
||||
|
||||
This helper's observable emits the `data` value in the next turn of the JavaScript engine.
|
||||
@ -1485,7 +1489,7 @@ While the `async()` and `fakeAsync()` functions greatly
|
||||
simplify Angular asynchronous testing,
|
||||
you can still fall back to the traditional technique
|
||||
and pass `it` a function that takes a
|
||||
[`done` callback](http://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support).
|
||||
[`done` callback](https://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support).
|
||||
|
||||
You can't call `done()` in `async()` or `fakeAsync()` functions, because the `done parameter`
|
||||
is `undefined`.
|
||||
@ -1548,7 +1552,7 @@ Then import the symbols you need.
|
||||
<code-example
|
||||
path="testing/src/app/twain/twain.component.marbles.spec.ts"
|
||||
region="import-marbles"
|
||||
title="app/twain/twain.component.marbles.spec.ts (import marbles)" linenums="false">
|
||||
header="app/twain/twain.component.marbles.spec.ts (import marbles)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here's the complete test for getting a quote:
|
||||
@ -1652,7 +1656,7 @@ The `DashboardHeroComponent` is embedded in the `DashboardComponent` template li
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard.component.html"
|
||||
region="dashboard-hero"
|
||||
title="app/dashboard/dashboard.component.html (excerpt)" linenums="false">
|
||||
header="app/dashboard/dashboard.component.html (excerpt)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `DashboardHeroComponent` appears in an `*ngFor` repeater, which sets each component's `hero` input property
|
||||
@ -1665,7 +1669,7 @@ Here's the component's full definition:
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.ts"
|
||||
region="component"
|
||||
title="app/dashboard/dashboard-hero.component.ts (component)" linenums="false">
|
||||
header="app/dashboard/dashboard-hero.component.ts (component)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
While testing a component this simple has little intrinsic value, it's worth knowing how.
|
||||
@ -1680,7 +1684,7 @@ A quick look at the `DashboardComponent` constructor discourages the first appro
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard.component.ts"
|
||||
region="ctor"
|
||||
title="app/dashboard/dashboard.component.ts (constructor)" linenums="false">
|
||||
header="app/dashboard/dashboard.component.ts (constructor)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `DashboardComponent` depends on the Angular router and the `HeroService`.
|
||||
@ -1705,7 +1709,7 @@ Here's the meat of the spec file setup.
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
|
||||
region="setup"
|
||||
title="app/dashboard/dashboard-hero.component.spec.ts (setup)" linenums="false">
|
||||
header="app/dashboard/dashboard-hero.component.spec.ts (setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Note how the setup code assigns a test hero (`expectedHero`) to the component's `hero` property,
|
||||
@ -1804,7 +1808,7 @@ in a helper such as the `click()` function below:
|
||||
<code-example
|
||||
path="testing/src/testing/index.ts"
|
||||
region="click-event"
|
||||
title="testing/index.ts (click helper)" linenums="false">
|
||||
header="testing/index.ts (click helper)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The first parameter is the _element-to-click_. If you wish, you can pass a
|
||||
@ -1826,7 +1830,7 @@ Here's the previous test, rewritten using the click helper.
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
|
||||
region="click-test-3"
|
||||
title="app/dashboard/dashboard-hero.component.spec.ts (test with click helper)">
|
||||
header="app/dashboard/dashboard-hero.component.spec.ts (test with click helper)">
|
||||
</code-example>
|
||||
|
||||
<hr>
|
||||
@ -1851,7 +1855,7 @@ that can be made satisfactorily with a _test host_ like this one:
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
|
||||
region="test-host"
|
||||
title="app/dashboard/dashboard-hero.component.spec.ts (test host)"
|
||||
header="app/dashboard/dashboard-hero.component.spec.ts (test host)"
|
||||
linenums="false">
|
||||
</code-example>
|
||||
|
||||
@ -1867,7 +1871,7 @@ Later, the tests will be able to easily check `selectedHero` to verify that the
|
||||
|
||||
The setup for the _test-host_ tests is similar to the setup for the stand-alone tests:
|
||||
|
||||
<code-example path="testing/src/app/dashboard/dashboard-hero.component.spec.ts" region="test-host-setup" title="app/dashboard/dashboard-hero.component.spec.ts (test host setup)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/dashboard/dashboard-hero.component.spec.ts" region="test-host-setup" header="app/dashboard/dashboard-hero.component.spec.ts (test host setup)" linenums="false"></code-example>
|
||||
|
||||
This testing module configuration shows three important differences:
|
||||
|
||||
@ -1887,7 +1891,7 @@ The tests themselves are almost identical to the stand-alone version:
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
|
||||
region="test-host-tests"
|
||||
title="app/dashboard/dashboard-hero.component.spec.ts (test-host)" linenums="false">
|
||||
header="app/dashboard/dashboard-hero.component.spec.ts (test-host)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Only the selected event test differs. It confirms that the selected `DashboardHeroComponent` hero
|
||||
@ -1910,7 +1914,7 @@ which it injects together with the `HeroService`.
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard.component.ts"
|
||||
region="ctor"
|
||||
title="app/dashboard/dashboard.component.ts (constructor)" linenums="false">
|
||||
header="app/dashboard/dashboard.component.ts (constructor)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Mocking the `HeroService` with a spy is a [familiar story](#component-with-async-service).
|
||||
@ -1921,7 +1925,7 @@ Fortunately, not in this case because the `DashboardComponent` isn't doing much
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard.component.ts"
|
||||
region="goto-detail"
|
||||
title="app/dashboard/dashboard.component.ts (goToDetail)">
|
||||
header="app/dashboard/dashboard.component.ts (goToDetail)">
|
||||
</code-example>
|
||||
|
||||
This is often the case with _routing components_.
|
||||
@ -1934,7 +1938,7 @@ as providing a `HeroService` spy.
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard.component.spec.ts"
|
||||
region="router-spy"
|
||||
title="app/dashboard/dashboard.component.spec.ts (spies)" linenums="false">
|
||||
header="app/dashboard/dashboard.component.spec.ts (spies)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The following test clicks the displayed hero and confirms that
|
||||
@ -1943,7 +1947,7 @@ The following test clicks the displayed hero and confirms that
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard.component.spec.ts"
|
||||
region="navigate-test"
|
||||
title="app/dashboard/dashboard.component.spec.ts (navigate test)" linenums="false">
|
||||
header="app/dashboard/dashboard.component.spec.ts (navigate test)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a routed-component-w-param}
|
||||
@ -1964,7 +1968,7 @@ injects it into a new instance of the `HeroDetailComponent`.
|
||||
|
||||
Here's the `HeroDetailComponent` constructor:
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.ts" region="ctor" title="app/hero/hero-detail.component.ts (constructor)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.ts" region="ctor" header="app/hero/hero-detail.component.ts (constructor)" linenums="false"></code-example>
|
||||
|
||||
The `HeroDetail` component needs the `id` parameter so it can fetch
|
||||
the corresponding hero via the `HeroDetailService`.
|
||||
@ -1975,7 +1979,7 @@ It can't just reference the `id` property of the `ActivatedRoute.paramMap`.
|
||||
The component has to _subscribe_ to the `ActivatedRoute.paramMap` observable and be prepared
|
||||
for the `id` to change during its lifetime.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.ts" region="ng-on-init" title="app/hero/hero-detail.component.ts (ngOnInit)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.ts" region="ng-on-init" header="app/hero/hero-detail.component.ts (ngOnInit)" linenums="false"></code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
@ -2004,7 +2008,7 @@ The following `ActivatedRouteStub` class serves as a test double for `ActivatedR
|
||||
<code-example
|
||||
path="testing/src/testing/activated-route-stub.ts"
|
||||
region="activated-route-stub"
|
||||
title="testing/activated-route-stub.ts (ActivatedRouteStub)" linenums="false">
|
||||
header="testing/activated-route-stub.ts (ActivatedRouteStub)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Consider placing such helpers in a `testing` folder sibling to the `app` folder.
|
||||
@ -2023,7 +2027,7 @@ the [_marble testing library_](#marble-testing).
|
||||
|
||||
Here's a test demonstrating the component's behavior when the observed `id` refers to an existing hero:
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="route-good-id" title="app/hero/hero-detail.component.spec.ts (existing id)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="route-good-id" header="app/hero/hero-detail.component.spec.ts (existing id)" linenums="false"></code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
@ -2038,7 +2042,7 @@ The test suite setup provided the same router spy [described above](#routing-com
|
||||
|
||||
This test expects the component to try to navigate to the `HeroListComponent`.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="route-bad-id" title="app/hero/hero-detail.component.spec.ts (bad id)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="route-bad-id" header="app/hero/hero-detail.component.spec.ts (bad id)" linenums="false"></code-example>
|
||||
|
||||
While this app doesn't have a route to the `HeroDetailComponent` that omits the `id` parameter, it might add such a route someday.
|
||||
The component should do something reasonable when there is no `id`.
|
||||
@ -2049,7 +2053,7 @@ New heroes have `id=0` and a blank `name`. This test confirms that the component
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.spec.ts"
|
||||
region="route-no-id"
|
||||
title="app/hero/hero-detail.component.spec.ts (no id)" linenums="false">
|
||||
header="app/hero/hero-detail.component.spec.ts (no id)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<hr>
|
||||
@ -2066,7 +2070,7 @@ The `AppComponent`, for example, displays a navigation bar with anchors and thei
|
||||
|
||||
<code-example
|
||||
path="testing/src/app/app.component.html"
|
||||
title="app/app.component.html" linenums="false">
|
||||
header="app/app.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
While the `AppComponent` _class_ is empty,
|
||||
@ -2105,7 +2109,7 @@ and directive that play little or no role in the tests.
|
||||
<code-example
|
||||
path="testing/src/app/app.component.spec.ts"
|
||||
region="component-stubs"
|
||||
title="app/app.component.spec.ts (stub declaration)" linenums="false">
|
||||
header="app/app.component.spec.ts (stub declaration)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The stub selectors match the selectors for the corresponding real components.
|
||||
@ -2117,7 +2121,7 @@ components, directives, and pipes that need to be real.
|
||||
<code-example
|
||||
path="testing/src/app/app.component.spec.ts"
|
||||
region="testbed-stubs"
|
||||
title="app/app.component.spec.ts (TestBed stubs)" linenums="false">
|
||||
header="app/app.component.spec.ts (TestBed stubs)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `AppComponent` is the test subject, so of course you declare the real version.
|
||||
@ -2136,7 +2140,7 @@ In the second approach, add `NO_ERRORS_SCHEMA` to the `TestBed.schemas` metadata
|
||||
<code-example
|
||||
path="testing/src/app/app.component.spec.ts"
|
||||
region="no-errors-schema"
|
||||
title="app/app.component.spec.ts (NO_ERRORS_SCHEMA)" linenums="false">
|
||||
header="app/app.component.spec.ts (NO_ERRORS_SCHEMA)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `NO_ERRORS_SCHEMA` tells the Angular compiler to ignore unrecognized elements and attributes.
|
||||
@ -2173,7 +2177,7 @@ as seen in this example.
|
||||
<code-example
|
||||
path="testing/src/app/app.component.spec.ts"
|
||||
region="mixed-setup"
|
||||
title="app/app.component.spec.ts (mixed setup)" linenums="false">
|
||||
header="app/app.component.spec.ts (mixed setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The Angular compiler creates the `BannerComponentStub` for the `<app-banner>` element
|
||||
@ -2196,7 +2200,7 @@ seen in the `AppComponent` template.
|
||||
<code-example
|
||||
path="testing/src/testing/router-link-directive-stub.ts"
|
||||
region="router-link"
|
||||
title="testing/router-link-directive-stub.ts (RouterLinkDirectiveStub)" linenums="false">
|
||||
header="testing/router-link-directive-stub.ts (RouterLinkDirectiveStub)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The URL bound to the `[routerLink]` attribute flows in to the directive's `linkParams` property.
|
||||
@ -2226,7 +2230,7 @@ A little more setup triggers the initial data binding and gets references to the
|
||||
<code-example
|
||||
path="testing/src/app/app.component.spec.ts"
|
||||
region="test-setup"
|
||||
title="app/app.component.spec.ts (test setup)" linenums="false">
|
||||
header="app/app.component.spec.ts (test setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Three points of special interest:
|
||||
@ -2243,7 +2247,7 @@ The `AppComponent` links to validate are as follows:
|
||||
<code-example
|
||||
path="testing/src/app/app.component.html"
|
||||
region="links"
|
||||
title="app/app.component.html (navigation links)" linenums="false">
|
||||
header="app/app.component.html (navigation links)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a app-component-tests}
|
||||
@ -2251,7 +2255,7 @@ The `AppComponent` links to validate are as follows:
|
||||
Here are some tests that confirm those links are wired to the `routerLink` directives
|
||||
as expected:
|
||||
|
||||
<code-example path="testing/src/app/app.component.spec.ts" region="tests" title="app/app.component.spec.ts (selected tests)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/app.component.spec.ts" region="tests" header="app/app.component.spec.ts (selected tests)" linenums="false"></code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
@ -2306,7 +2310,7 @@ The `HeroDetailComponent` is a simple view with a title, two hero fields, and tw
|
||||
But there's plenty of template complexity even in this simple form.
|
||||
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.html" title="app/hero/hero-detail.component.html" linenums="false">
|
||||
path="testing/src/app/hero/hero-detail.component.html" header="app/hero/hero-detail.component.html" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Tests that exercise the component need ...
|
||||
@ -2327,7 +2331,7 @@ Here is such a `Page` class for the `hero-detail.component.spec.ts`
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.spec.ts"
|
||||
region="page"
|
||||
title="app/hero/hero-detail.component.spec.ts (Page)" linenums="false">
|
||||
header="app/hero/hero-detail.component.spec.ts (Page)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Now the important hooks for component manipulation and inspection are neatly organized and accessible from an instance of `Page`.
|
||||
@ -2337,7 +2341,7 @@ A `createComponent` method creates a `page` object and fills in the blanks once
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.spec.ts"
|
||||
region="create-component"
|
||||
title="app/hero/hero-detail.component.spec.ts (createComponent)" linenums="false">
|
||||
header="app/hero/hero-detail.component.spec.ts (createComponent)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The [_HeroDetailComponent_ tests](#tests-w-test-double) in an earlier section demonstrate how `createComponent` and `page`
|
||||
@ -2349,7 +2353,7 @@ Here are a few more `HeroDetailComponent` tests to reinforce the point.
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.spec.ts"
|
||||
region="selected-tests"
|
||||
title="app/hero/hero-detail.component.spec.ts (selected tests)" linenums="false">
|
||||
header="app/hero/hero-detail.component.spec.ts (selected tests)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<hr>
|
||||
@ -2377,7 +2381,7 @@ the following version of the `BannerComponent` does.
|
||||
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-external.component.ts"
|
||||
title="app/banner/banner-external.component.ts (external template & css)" linenums="false">
|
||||
header="app/banner/banner-external.component.ts (external template & css)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The test fails when the `TestBed` tries to create the component.
|
||||
@ -2385,7 +2389,7 @@ The test fails when the `TestBed` tries to create the component.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner.component.spec.ts"
|
||||
region="configure-and-create"
|
||||
title="app/banner/banner.component.spec.ts (setup that fails)"
|
||||
header="app/banner/banner.component.spec.ts (setup that fails)"
|
||||
avoid linenums="false">
|
||||
</code-example>
|
||||
|
||||
@ -2437,7 +2441,7 @@ Write the first async `beforeEach` like this.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-external.component.spec.ts"
|
||||
region="async-before-each"
|
||||
title="app/banner/banner-external.component.spec.ts (async beforeEach)" linenums="false">
|
||||
header="app/banner/banner-external.component.spec.ts (async beforeEach)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `async()` helper function takes a parameterless function with the body of the setup.
|
||||
@ -2473,7 +2477,7 @@ which include creating the component and querying for elements to inspect.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-external.component.spec.ts"
|
||||
region="sync-before-each"
|
||||
title="app/banner/banner-external.component.spec.ts (synchronous beforeEach)" linenums="false">
|
||||
header="app/banner/banner-external.component.spec.ts (synchronous beforeEach)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
You can count on the test runner to wait for the first asynchronous `beforeEach` to finish before calling the second.
|
||||
@ -2489,7 +2493,7 @@ into a `then(...)` callback.
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-external.component.spec.ts"
|
||||
region="one-before-each"
|
||||
title="app/banner/banner-external.component.spec.ts (one beforeEach)" linenums="false">
|
||||
header="app/banner/banner-external.component.spec.ts (one beforeEach)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
#### _compileComponents()_ is harmless
|
||||
@ -2512,7 +2516,7 @@ Earlier component tests configured the testing module with a few `declarations`
|
||||
<code-example
|
||||
path="testing/src/app/dashboard/dashboard-hero.component.spec.ts"
|
||||
region="config-testbed"
|
||||
title="app/dashboard/dashboard-hero.component.spec.ts (configure TestBed)">
|
||||
header="app/dashboard/dashboard-hero.component.spec.ts (configure TestBed)">
|
||||
</code-example>
|
||||
|
||||
The `DashboardComponent` is simple. It needs no help.
|
||||
@ -2536,7 +2540,7 @@ One approach is to configure the testing module from the individual pieces as in
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.spec.ts"
|
||||
region="setup-forms-module"
|
||||
title="app/hero/hero-detail.component.spec.ts (FormsModule setup)" linenums="false">
|
||||
header="app/hero/hero-detail.component.spec.ts (FormsModule setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -2560,7 +2564,7 @@ The test configuration can use the `SharedModule` too as seen in this alternativ
|
||||
<code-example
|
||||
path="testing/src/app/hero/hero-detail.component.spec.ts"
|
||||
region="setup-shared-module"
|
||||
title="app/hero/hero-detail.component.spec.ts (SharedModule setup)" linenums="false">
|
||||
header="app/hero/hero-detail.component.spec.ts (SharedModule setup)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
It's a bit tighter and smaller, with fewer import statements (not shown).
|
||||
@ -2573,7 +2577,7 @@ The `HeroDetailComponent` is part of the `HeroModule` [Feature Module](guide/fea
|
||||
including the `SharedModule`.
|
||||
Try a test configuration that imports the `HeroModule` like this one:
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="setup-hero-module" title="app/hero/hero-detail.component.spec.ts (HeroModule setup)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="setup-hero-module" header="app/hero/hero-detail.component.spec.ts (HeroModule setup)" linenums="false"></code-example>
|
||||
|
||||
That's _really_ crisp. Only the _test doubles_ in the `providers` remain. Even the `HeroDetailComponent` declaration is gone.
|
||||
|
||||
@ -2597,7 +2601,7 @@ the module is small, as feature modules tend to be.
|
||||
|
||||
The `HeroDetailComponent` provides its own `HeroDetailService`.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.ts" region="prototype" title="app/hero/hero-detail.component.ts (prototype)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.ts" region="prototype" header="app/hero/hero-detail.component.ts (prototype)" linenums="false"></code-example>
|
||||
|
||||
It's not possible to stub the component's `HeroDetailService` in the `providers` of the `TestBed.configureTestingModule`.
|
||||
Those are providers for the _testing module_, not the component. They prepare the dependency injector at the _fixture level_.
|
||||
@ -2617,7 +2621,7 @@ There might not be a remote server to call.
|
||||
|
||||
Fortunately, the `HeroDetailService` delegates responsibility for remote data access to an injected `HeroService`.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.service.ts" region="prototype" title="app/hero/hero-detail.service.ts (prototype)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.service.ts" region="prototype" header="app/hero/hero-detail.service.ts (prototype)" linenums="false"></code-example>
|
||||
|
||||
The [previous test configuration](#feature-module-import) replaces the real `HeroService` with a `TestHeroService`
|
||||
that intercepts server requests and fakes their responses.
|
||||
@ -2630,7 +2634,7 @@ What if `HeroDetailService` makes its own server requests?
|
||||
The `TestBed.overrideComponent` method can replace the component's `providers` with easy-to-manage _test doubles_
|
||||
as seen in the following setup variation:
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="setup-override" title="app/hero/hero-detail.component.spec.ts (Override setup)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="setup-override" header="app/hero/hero-detail.component.spec.ts (Override setup)" linenums="false"></code-example>
|
||||
|
||||
Notice that `TestBed.configureTestingModule` no longer provides a (fake) `HeroService` because it's [not needed](#spy-stub).
|
||||
|
||||
@ -2640,7 +2644,7 @@ Notice that `TestBed.configureTestingModule` no longer provides a (fake) `HeroSe
|
||||
|
||||
Focus on the `overrideComponent` method.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="override-component-method" title="app/hero/hero-detail.component.spec.ts (overrideComponent)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="override-component-method" header="app/hero/hero-detail.component.spec.ts (overrideComponent)" linenums="false"></code-example>
|
||||
|
||||
It takes two arguments: the component type to override (`HeroDetailComponent`) and an override metadata object.
|
||||
The [override metadata object](#metadata-override-object) is a generic defined as follows:
|
||||
@ -2681,7 +2685,7 @@ The related `HeroDetailComponent` tests will assert that methods of the `HeroDet
|
||||
were called by spying on the service methods.
|
||||
Accordingly, the stub implements its methods as spies:
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="hds-spy" title="app/hero/hero-detail.component.spec.ts (HeroDetailServiceSpy)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="hds-spy" header="app/hero/hero-detail.component.spec.ts (HeroDetailServiceSpy)" linenums="false"></code-example>
|
||||
|
||||
{@a override-tests}
|
||||
|
||||
@ -2690,7 +2694,7 @@ Accordingly, the stub implements its methods as spies:
|
||||
Now the tests can control the component's hero directly by manipulating the spy-stub's `testHero`
|
||||
and confirm that service methods were called.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="override-tests" title="app/hero/hero-detail.component.spec.ts (override tests)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="override-tests" header="app/hero/hero-detail.component.spec.ts (override tests)" linenums="false"></code-example>
|
||||
|
||||
{@a more-overrides}
|
||||
|
||||
@ -2716,16 +2720,16 @@ based on either a data bound color or a default color (lightgray).
|
||||
It also sets a custom property of the element (`customProperty`) to `true`
|
||||
for no reason other than to show that it can.
|
||||
|
||||
<code-example path="testing/src/app/shared/highlight.directive.ts" title="app/shared/highlight.directive.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/shared/highlight.directive.ts" header="app/shared/highlight.directive.ts" linenums="false"></code-example>
|
||||
|
||||
It's used throughout the application, perhaps most simply in the `AboutComponent`:
|
||||
|
||||
<code-example path="testing/src/app/about/about.component.ts" title="app/about/about.component.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/about/about.component.ts" header="app/about/about.component.ts" linenums="false"></code-example>
|
||||
|
||||
Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the
|
||||
techniques explored above (in particular the ["Shallow test"](#nested-component-tests) approach).
|
||||
|
||||
<code-example path="testing/src/app/about/about.component.spec.ts" region="tests" title="app/about/about.component.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/about/about.component.spec.ts" region="tests" header="app/about/about.component.spec.ts" linenums="false"></code-example>
|
||||
|
||||
However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
|
||||
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.
|
||||
@ -2737,7 +2741,7 @@ do not inspire confidence in the directive's efficacy.
|
||||
|
||||
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
|
||||
|
||||
<code-example path="testing/src/app/shared/highlight.directive.spec.ts" region="test-component" title="app/shared/highlight.directive.spec.ts (TestComponent)" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/shared/highlight.directive.spec.ts" region="test-component" header="app/shared/highlight.directive.spec.ts (TestComponent)" linenums="false"></code-example>
|
||||
|
||||
<figure>
|
||||
<img src='generated/images/guide/testing/highlight-directive-spec.png' alt="HighlightDirective spec in action">
|
||||
@ -2752,7 +2756,7 @@ The initial value is the word "cyan" which should be the background color of the
|
||||
|
||||
Here are some tests of this component:
|
||||
|
||||
<code-example path="testing/src/app/shared/highlight.directive.spec.ts" region="selected-tests" title="app/shared/highlight.directive.spec.ts (selected tests)"></code-example>
|
||||
<code-example path="testing/src/app/shared/highlight.directive.spec.ts" region="selected-tests" header="app/shared/highlight.directive.spec.ts (selected tests)"></code-example>
|
||||
|
||||
A few techniques are noteworthy:
|
||||
|
||||
@ -2786,12 +2790,12 @@ metadata and an interface.
|
||||
Consider a `TitleCasePipe` that capitalizes the first letter of each word.
|
||||
Here's a naive implementation with a regular expression.
|
||||
|
||||
<code-example path="testing/src/app/shared/title-case.pipe.ts" title="app/shared/title-case.pipe.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/shared/title-case.pipe.ts" header="app/shared/title-case.pipe.ts" linenums="false"></code-example>
|
||||
|
||||
Anything that uses a regular expression is worth testing thoroughly.
|
||||
Use simple Jasmine to explore the expected cases and the edge cases.
|
||||
|
||||
<code-example path="testing/src/app/shared/title-case.pipe.spec.ts" region="excerpt" title="app/shared/title-case.pipe.spec.ts"></code-example>
|
||||
<code-example path="testing/src/app/shared/title-case.pipe.spec.ts" region="excerpt" header="app/shared/title-case.pipe.spec.ts"></code-example>
|
||||
|
||||
{@a write-tests}
|
||||
|
||||
@ -2802,7 +2806,7 @@ They can't tell if the `TitleCasePipe` is working properly as applied in the app
|
||||
|
||||
Consider adding component tests such as this one:
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="title-case-pipe" title="app/hero/hero-detail.component.spec.ts (pipe test)"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-detail.component.spec.ts" region="title-case-pipe" header="app/hero/hero-detail.component.spec.ts (pipe test)"></code-example>
|
||||
|
||||
<hr>
|
||||
|
||||
@ -3150,7 +3154,7 @@ Here are the most important static methods, in order of likely utility.
|
||||
the object to return if Angular can't find the provider
|
||||
(`null` in this example):
|
||||
|
||||
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="testbed-get-w-null" title="app/demo/demo.testbed.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="testbed-get-w-null" header="app/demo/demo.testbed.spec.ts" linenums="false"></code-example>
|
||||
|
||||
After calling `get`, the `TestBed` configuration is frozen for the duration of the current spec.
|
||||
|
||||
@ -3610,7 +3614,7 @@ predicate that filters the source element's subtree for matching `DebugElement`.
|
||||
The predicate is any method that takes a `DebugElement` and returns a _truthy_ value.
|
||||
The following example finds all `DebugElements` with a reference to a template local variable named "content":
|
||||
|
||||
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="custom-predicate" title="app/demo/demo.testbed.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/demo/demo.testbed.spec.ts" region="custom-predicate" header="app/demo/demo.testbed.spec.ts" linenums="false"></code-example>
|
||||
|
||||
The Angular `By` class has three static methods for common predicates:
|
||||
|
||||
@ -3618,7 +3622,7 @@ The Angular `By` class has three static methods for common predicates:
|
||||
- `By.css(selector)` - return elements with matching CSS selectors.
|
||||
- `By.directive(directive)` - return elements that Angular matched to an instance of the directive class.
|
||||
|
||||
<code-example path="testing/src/app/hero/hero-list.component.spec.ts" region="by" title="app/hero/hero-list.component.spec.ts" linenums="false"></code-example>
|
||||
<code-example path="testing/src/app/hero/hero-list.component.spec.ts" region="by" header="app/hero/hero-list.component.spec.ts" linenums="false"></code-example>
|
||||
|
||||
<hr>
|
||||
|
||||
|
@ -22,12 +22,12 @@ Here's another code sample using the wildcard state together with our previous e
|
||||
|
||||
This allows us to add new states without having to include separate transitions for each one.
|
||||
|
||||
<code-example title="src/app/open-close.component.ts" path="animations/src/app/open-close.component.ts" region="trigger-wildcard1" language="typescript" linenums="false">
|
||||
<code-example header="src/app/open-close.component.ts" path="animations/src/app/open-close.component.ts" region="trigger-wildcard1" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Use a double arrow syntax to specify state-to-state transitions in both directions.
|
||||
|
||||
<code-example title="src/app/open-close.component.ts" path="animations/src/app/open-close.component.ts" region="trigger-wildcard2" language="typescript" linenums="false">
|
||||
<code-example header="src/app/open-close.component.ts" path="animations/src/app/open-close.component.ts" region="trigger-wildcard2" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Using wildcard state with multiple transition states
|
||||
@ -39,7 +39,7 @@ In our two-state button example, the wildcard isn't that useful because there ar
|
||||
</figure>
|
||||
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" linenums="false"
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" linenums="false"
|
||||
region="trigger-transition" language="typescript">
|
||||
</code-example>
|
||||
|
||||
@ -54,7 +54,7 @@ To do this, list the more specific transitions *before* `* => *`.
|
||||
|
||||
Use the wildcard `*` with a style to tell the animation to use whatever the current style value is, and animate with that. Wildcard is a fallback value that's used if the state being animated isn't declared within the trigger.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" linenums="false"
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" linenums="false"
|
||||
region="transition4" language="typescript">
|
||||
</code-example>
|
||||
|
||||
@ -88,7 +88,7 @@ Now we'll add a new behavior:
|
||||
* When you add a hero to the list of heroes, it appears to fly onto the page from the left.
|
||||
* When you remove a hero from the list, it appears to fly out to the right.
|
||||
|
||||
<code-example path="animations/src/app/hero-list-enter-leave.component.ts" title="src/app/hero-list-enter-leave.component.ts" region="animationdef" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/hero-list-enter-leave.component.ts" header="src/app/hero-list-enter-leave.component.ts" region="animationdef" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
In the above code, we applied the `void` state when the HTML element isn't attached to a view.
|
||||
@ -114,12 +114,12 @@ The `:enter` transition runs when any `*ngIf` or `*ngFor` views are placed on th
|
||||
|
||||
In this example, we have a special trigger for the enter and leave animation called `myInsertRemoveTrigger`. The HTML template contains the following code.
|
||||
|
||||
<code-example path="animations/src/app/insert-remove.component.html" title="src/app/insert-remove.component.html" region="insert-remove" language="typescript">
|
||||
<code-example path="animations/src/app/insert-remove.component.html" header="src/app/insert-remove.component.html" region="insert-remove" language="typescript">
|
||||
</code-example>
|
||||
|
||||
In the component file, the `:enter` transition sets an initial opacity of 0, and then animates it to change that opacity to 1 as the element is inserted into the view.
|
||||
|
||||
<code-example path="animations/src/app/insert-remove.component.ts" title="src/app/insert-remove.component.ts" region="enter-leave-trigger" language="typescript">
|
||||
<code-example path="animations/src/app/insert-remove.component.ts" header="src/app/insert-remove.component.ts" region="enter-leave-trigger" language="typescript">
|
||||
</code-example>
|
||||
|
||||
Note that this example doesn't need to use `state()`.
|
||||
@ -134,20 +134,20 @@ The `transition()` function takes additional selector values, `:increment` and `
|
||||
|
||||
</div>
|
||||
|
||||
<code-example path="animations/src/app/hero-list-page.component.ts" title="src/app/hero-list-page.component.ts" region="increment" language="typescript" linenums="false"></code-example>
|
||||
<code-example path="animations/src/app/hero-list-page.component.ts" header="src/app/hero-list-page.component.ts" region="increment" language="typescript" linenums="false"></code-example>
|
||||
|
||||
## Boolean values in transitions
|
||||
|
||||
If a trigger contains a boolean value as a binding value, then this value can be matched using a `transition()` expression that compares `true` and `false`, or `1` and `0`.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.2.html" title="src/app/open-close.component.html" region="trigger-boolean">
|
||||
<code-example path="animations/src/app/open-close.component.2.html" header="src/app/open-close.component.html" region="trigger-boolean">
|
||||
</code-example>
|
||||
|
||||
In the code snippet above, the HTML template binds a `<div>` element to a trigger named `openClose` with a status expression of `isOpen`, and with possible values of `true` and `false`. This is an alternative to the practice of creating two named states of `open` and `close`.
|
||||
|
||||
In the component code, in the `@Component` metadata under the `animations:` property, when the state evaluates to `true` (meaning "open" here), the associated HTML element's height is a wildcard style or default. In this case, use whatever height the element already had before the animation started. When the element is "closed," the element animates to a height of 0, which makes it invisible.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.2.ts" title="src/app/open-close.component.ts" region="trigger-boolean" language="typescript">
|
||||
<code-example path="animations/src/app/open-close.component.2.ts" header="src/app/open-close.component.ts" region="trigger-boolean" language="typescript">
|
||||
</code-example>
|
||||
|
||||
## Multiple animation triggers
|
||||
@ -166,10 +166,10 @@ The code sample below shows how to use this feature.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane path="animations/src/app/open-close.component.4.html" title="src/app/open-close.component.html" region="toggle-animation">
|
||||
<code-pane path="animations/src/app/open-close.component.4.html" header="src/app/open-close.component.html" region="toggle-animation">
|
||||
</code-pane>
|
||||
|
||||
<code-pane path="animations/src/app/open-close.component.4.ts" title="src/app/open-close.component.ts" region="toggle-animation" language="typescript">
|
||||
<code-pane path="animations/src/app/open-close.component.4.ts" header="src/app/open-close.component.ts" region="toggle-animation" language="typescript">
|
||||
</code-pane>
|
||||
|
||||
</code-tabs>
|
||||
@ -188,7 +188,7 @@ However, selective child animations can still be run on a disabled parent in one
|
||||
|
||||
To disable all animations for an Angular app, place the `@.disabled` host binding on the topmost Angular component.
|
||||
|
||||
<code-example path="animations/src/app/app.component.ts" title="src/app/app.component.ts" region="toggle-app-animations" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/app.component.ts" header="src/app/app.component.ts" region="toggle-app-animations" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -200,12 +200,12 @@ To disable all animations for an Angular app, place the `@.disabled` host bindin
|
||||
|
||||
The animation `trigger()` function emits *callbacks* when it starts and when it finishes. In the example below we have a component that contains an `openClose` trigger.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" region="events1" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" region="events1" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
In the HTML template, the animation event is passed back via `$event`, as `@trigger.start` and `@trigger.done`, where `trigger` is the name of the trigger being used. In our example, the trigger `openClose` appears as follows.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.3.html" title="src/app/open-close.component.html" region="callbacks">
|
||||
<code-example path="animations/src/app/open-close.component.3.html" header="src/app/open-close.component.html" region="callbacks">
|
||||
</code-example>
|
||||
|
||||
A potential use for animation callbacks could be to cover for a slow API call, such as a database lookup. For example, you could set up the **InProgress** button to have its own looping animation where it pulsates or does some other visual motion while the backend system operation finishes.
|
||||
@ -216,7 +216,7 @@ An animation can influence an end user to *perceive* the operation as faster, ev
|
||||
|
||||
Callbacks can serve as a debugging tool, for example in conjunction with `console.warn()` to view the application's progress in a browser's Developer JavaScript Console. The following code snippet creates console log output for our original example, a button with the two states of `open` and `closed`.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.ts" title="src/app/open-close.component.ts" region="events" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/open-close.component.ts" header="src/app/open-close.component.ts" region="events" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
{@a keyframes}
|
||||
@ -233,7 +233,7 @@ Angular's `keyframe()` function is similar to keyframes in CSS. Keyframes allow
|
||||
|
||||
The code for this color change might look like this.
|
||||
|
||||
<code-example path="animations/src/app/status-slider.component.ts" title="src/app/status-slider.component.ts" region="keyframes" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/status-slider.component.ts" header="src/app/status-slider.component.ts" region="keyframes" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Offset
|
||||
@ -248,7 +248,7 @@ Defining offsets for keyframes is optional. If you omit them, evenly spaced offs
|
||||
|
||||
The code with offsets specified would be as follows.
|
||||
|
||||
<code-example path="animations/src/app/status-slider.component.ts" title="src/app/status-slider.component.ts" region="keyframesWithOffsets" language="typescript">
|
||||
<code-example path="animations/src/app/status-slider.component.ts" header="src/app/status-slider.component.ts" region="keyframesWithOffsets" language="typescript">
|
||||
</code-example>
|
||||
|
||||
You can combine keyframes with `duration`, `delay`, and `easing` within a single animation.
|
||||
@ -269,7 +269,7 @@ Here's an example of using keyframes to create a pulse effect:
|
||||
|
||||
The code snippet for this animation might look like this.
|
||||
|
||||
<code-example path="animations/src/app/open-close.component.1.ts" title="src/app/open-close.component.ts" region="trigger" language="typescript" linenums="false">
|
||||
<code-example path="animations/src/app/open-close.component.1.ts" header="src/app/open-close.component.ts" region="trigger" language="typescript" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Animatable properties and units
|
||||
@ -292,7 +292,7 @@ In these cases, you can use a special wildcard `*` property value under `style()
|
||||
|
||||
In this example, we have a trigger called `shrinkOut`, used when an HTML element leaves the page. The animation takes whatever height the element has before it leaves, and animates from that height to zero.
|
||||
|
||||
<code-example path="animations/src/app/hero-list-auto.component.ts" title="src/app/hero-list-auto.component.ts" region="auto-calc" language="typescript" linenums="false"></code-example>
|
||||
<code-example path="animations/src/app/hero-list-auto.component.ts" header="src/app/hero-list-auto.component.ts" region="auto-calc" language="typescript" linenums="false"></code-example>
|
||||
|
||||
### Keyframes summary
|
||||
|
||||
|
@ -34,7 +34,7 @@ For details about `tsconfig.json`, see the official
|
||||
|
||||
The [Setup](guide/setup) guide uses the following `tsconfig.json`:
|
||||
|
||||
<code-example path="quickstart/src/tsconfig.1.json" title="tsconfig.json" linenums="false"></code-example>
|
||||
<code-example path="quickstart/src/tsconfig.1.json" header="tsconfig.json" linenums="false"></code-example>
|
||||
|
||||
This file contains options and flags that are essential for Angular applications.
|
||||
|
||||
|
@ -538,7 +538,7 @@ inject it into the service, and prepend the origin to the request URL.
|
||||
|
||||
Start by changing the `HeroService` constructor to take a second `origin` parameter that is optionally injected via the `APP_BASE_HREF` token.
|
||||
|
||||
<code-example path="universal/src/app/hero.service.ts" region="ctor" title="src/app/hero.service.ts (constructor with optional origin)">
|
||||
<code-example path="universal/src/app/hero.service.ts" region="ctor" header="src/app/hero.service.ts (constructor with optional origin)">
|
||||
</code-example>
|
||||
|
||||
The constructor uses the `@Optional()` directive to prepend the origin to `heroesUrl` _if it exists_.
|
||||
@ -555,7 +555,7 @@ You don't provide `APP_BASE_HREF` in the browser version, so `heroesUrl` remains
|
||||
|
||||
The important bit in the `server.ts` file is the `ngExpressEngine()` function.
|
||||
|
||||
<code-example path="universal/server.ts" title="server.ts" region="ngExpressEngine">
|
||||
<code-example path="universal/server.ts" header="server.ts" region="ngExpressEngine">
|
||||
</code-example>
|
||||
|
||||
The `ngExpressEngine()` function is a wrapper around Universal's `renderModuleFactory()` function which turns a client's requests into server-rendered HTML pages.
|
||||
@ -602,7 +602,7 @@ Because we use routing, we can easily recognize the three types of requests and
|
||||
A Node Express server is a pipeline of middleware that filters and processes URL requests one after the other.
|
||||
You configure the Node Express server pipeline with calls to `app.get()` like this one for data requests.
|
||||
|
||||
<code-example path="universal/server.ts" title="server.ts (data URL)" region="data-request" linenums="false">
|
||||
<code-example path="universal/server.ts" header="server.ts (data URL)" region="data-request" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -617,7 +617,7 @@ You configure the Node Express server pipeline with calls to `app.get()` like th
|
||||
|
||||
The following code filters for request URLs with no extensions and treats them as navigation requests.
|
||||
|
||||
<code-example path="universal/server.ts" title="server.ts (navigation)" region="navigation-request" linenums="false">
|
||||
<code-example path="universal/server.ts" header="server.ts (navigation)" region="navigation-request" linenums="false">
|
||||
</code-example>
|
||||
|
||||
### Serving static files safely
|
||||
@ -629,7 +629,7 @@ To ensure that clients can only download the files that they are permitted to se
|
||||
|
||||
The following Node Express code routes all remaining requests to `/dist`, and returns a `404 - NOT FOUND` error if the file isn't found.
|
||||
|
||||
<code-example path="universal/server.ts" title="server.ts (static files)" region="static" linenums="false">
|
||||
<code-example path="universal/server.ts" header="server.ts (static files)" region="static" linenums="false">
|
||||
</code-example>
|
||||
|
||||
|
||||
|
@ -39,7 +39,7 @@ To check your app's version of Angular: From within your project directory, use
|
||||
|
||||
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`](https://github.com/angular/angular-cli/wiki/update "Angular CLI update documentation"). By default, `ng 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` (without additional arguments) lists the updates that are available to you.
|
||||
|
||||
|
||||
{@a updating}
|
||||
@ -49,7 +49,7 @@ To make updating easy, we provide complete instructions in the interactive [Angu
|
||||
|
||||
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`](https://github.com/angular/angular-cli/wiki/update "Angular CLI update documentation") is all you need. Without additional arguments, `ng 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` lists the updates that are available to you and provides recommended steps to update your application to the most current version.
|
||||
|
||||
{@a resources}
|
||||
## Resource summary
|
||||
@ -62,7 +62,7 @@ For simple updates, the [CLI command `ng update`](https://github.com/angular/ang
|
||||
|
||||
* Update instructions: [Angular Update Guide](https://update.angular.io/ "Angular Update Guide")
|
||||
|
||||
* Update command reference: [Angular CLI update documentation](https://github.com/angular/angular-cli/wiki/update "Angular CLI update documentation")
|
||||
* Update command reference: [Angular CLI `ng update` command reference](cli/update)
|
||||
|
||||
* Versioning, release, support, and deprecation practices: [Angular versioning and releases](guide/releases "Angular versioning and releases")
|
||||
|
||||
|
@ -222,13 +222,13 @@ instructions in the [Setup](guide/setup) guide, selectively copying code from th
|
||||
You also need to install the `@angular/upgrade` package via `npm install @angular/upgrade --save`
|
||||
and add a mapping for the `@angular/upgrade/static` package:
|
||||
|
||||
<code-example title="system.config.js">
|
||||
<code-example header="system.config.js">
|
||||
'@angular/upgrade/static': 'npm:@angular/upgrade/bundles/upgrade-static.umd.js',
|
||||
</code-example>
|
||||
|
||||
Next, create an `app.module.ts` file and add the following `NgModule` class:
|
||||
|
||||
<code-example title="app.module.ts">
|
||||
<code-example header="app.module.ts">
|
||||
import { NgModule } from '@angular/core';
|
||||
import { BrowserModule } from '@angular/platform-browser';
|
||||
|
||||
@ -257,7 +257,7 @@ declaration on its `NgModule` decorator.
|
||||
|
||||
You can now link the AngularJS and Angular modules together using `downgradeModule()`.
|
||||
|
||||
<code-example title="app.module.ts">
|
||||
<code-example header="app.module.ts">
|
||||
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
|
||||
import { downgradeModule } from '@angular/upgrade/static';
|
||||
|
||||
@ -314,7 +314,7 @@ An easy way to copy them is to add each to the `copy-dist-files.js`file.
|
||||
You also need to pass the generated `MainAngularModuleFactory` to `downgradeModule()` instead of the
|
||||
custom bootstrap function:
|
||||
|
||||
<code-example title="app/main-aot.ts">
|
||||
<code-example header="app/main-aot.ts">
|
||||
import { downgradeModule } from '@angular/upgrade/static';
|
||||
import { MainAngularModuleNgFactory } from '../aot/app/app.module.ngfactory';
|
||||
|
||||
|
@ -162,7 +162,7 @@ Component directives **should not** use the following attributes:
|
||||
An AngularJS component directive that is fully aligned with the Angular
|
||||
architecture may look something like this:
|
||||
|
||||
<code-example path="upgrade-module/src/app/hero-detail.directive.ts" title="hero-detail.directive.ts">
|
||||
<code-example path="upgrade-module/src/app/hero-detail.directive.ts" header="hero-detail.directive.ts">
|
||||
</code-example>
|
||||
|
||||
AngularJS 1.5 introduces the [component API](https://docs.angularjs.org/api/ng/type/angular.Module#component)
|
||||
@ -176,7 +176,7 @@ this API for component directives for several reasons:
|
||||
The component directive example from above looks like this when expressed
|
||||
using the component API:
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/hero-detail.component.ts" region="hero-detail-io" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/hero-detail.component.ts" region="hero-detail-io" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
Controller lifecycle hook methods `$onInit()`, `$onDestroy()`, and `$onChanges()`
|
||||
@ -400,7 +400,7 @@ then ask the `UpgradeModule` to bootstrap the AngularJS bits next.
|
||||
In an AngularJS application you have a root AngularJS module, which will also
|
||||
be used to bootstrap the AngularJS application.
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-bootstrap/app.module.ts" region="ng1module" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-bootstrap/app.module.ts" region="ng1module" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Pure AngularJS applications can be automatically bootstrapped by using an `ng-app`
|
||||
@ -418,7 +418,7 @@ You can remove the `ng-app` and `ng-strict-di` directives from the HTML
|
||||
and instead switch to calling `angular.bootstrap` from JavaScript, which
|
||||
will result in the same thing:
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-bootstrap/app.module.ts" region="bootstrap" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-bootstrap/app.module.ts" region="bootstrap" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
To begin converting your AngularJS application to a hybrid, you need to load the Angular framework.
|
||||
@ -428,12 +428,12 @@ selectively copying code from the [QuickStart github repository](https://github.
|
||||
You also need to install the `@angular/upgrade` package via `npm install @angular/upgrade --save`
|
||||
and add a mapping for the `@angular/upgrade/static` package:
|
||||
|
||||
<code-example path="upgrade-module/src/systemjs.config.1.js" region="upgrade-static-umd" title="systemjs.config.js (map)">
|
||||
<code-example path="upgrade-module/src/systemjs.config.1.js" region="upgrade-static-umd" header="systemjs.config.js (map)">
|
||||
</code-example>
|
||||
|
||||
Next, create an `app.module.ts` file and add the following `NgModule` class:
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-a-hybrid-bootstrap/app.module.ts" region="ngmodule" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-a-hybrid-bootstrap/app.module.ts" region="ngmodule" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
This bare minimum `NgModule` imports `BrowserModule`, the module every Angular browser-based app must have.
|
||||
@ -453,7 +453,7 @@ AngularJS will own the root template of the application.
|
||||
|
||||
Now you can bootstrap `AppModule` using the `platformBrowserDynamic.bootstrapModule` method.
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-a-hybrid-bootstrap/app.module.ts" region="bootstrap" title="app.module.ts'">
|
||||
<code-example path="upgrade-module/src/app/ajs-a-hybrid-bootstrap/app.module.ts" region="bootstrap" header="app.module.ts'">
|
||||
</code-example>
|
||||
|
||||
Congratulations! You're running a hybrid application! The
|
||||
@ -470,14 +470,14 @@ previously AngularJS but has been rewritten for Angular.
|
||||
|
||||
Say you have a simple Angular component that shows information about a hero:
|
||||
|
||||
<code-example path="upgrade-module/src/app/downgrade-static/hero-detail.component.ts" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/downgrade-static/hero-detail.component.ts" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
If you want to use this component from AngularJS, you need to *downgrade* it
|
||||
using the `downgradeComponent()` method. The result is an AngularJS
|
||||
*directive*, which you can then register in the AngularJS module:
|
||||
|
||||
<code-example path="upgrade-module/src/app/downgrade-static/app.module.ts" region="downgradecomponent" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/downgrade-static/app.module.ts" region="downgradecomponent" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Because `HeroDetailComponent` is an Angular component, you must also add it to the
|
||||
@ -487,7 +487,7 @@ And because this component is being used from the AngularJS module, and is an en
|
||||
the Angular application, you must add it to the `entryComponents` for the
|
||||
NgModule.
|
||||
|
||||
<code-example path="upgrade-module/src/app/downgrade-static/app.module.ts" region="ngmodule" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/downgrade-static/app.module.ts" region="ngmodule" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -515,7 +515,7 @@ have *inputs and outputs* that connect them to the outside world. An
|
||||
Angular hero detail component with inputs and outputs might look
|
||||
like this:
|
||||
|
||||
<code-example path="upgrade-module/src/app/downgrade-io/hero-detail.component.ts" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/downgrade-io/hero-detail.component.ts" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
These inputs and outputs can be supplied from the AngularJS template, and the
|
||||
@ -583,7 +583,7 @@ introduced in AngularJS 1.5.
|
||||
A simple example of an upgradable component is one that just has a template
|
||||
and a controller:
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-static/hero-detail.component.ts" region="hero-detail" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-static/hero-detail.component.ts" region="hero-detail" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
You can *upgrade* this component to Angular using the `UpgradeComponent` class.
|
||||
@ -591,10 +591,10 @@ By creating a new Angular **directive** that extends `UpgradeComponent` and doin
|
||||
inside its constructor, you have a fully upgraded AngularJS component to be used inside Angular.
|
||||
All that is left is to add it to `AppModule`'s `declarations` array.
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-static/hero-detail.component.ts" region="hero-detail-upgrade" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-static/hero-detail.component.ts" region="hero-detail-upgrade" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-static/app.module.ts" region="hero-detail-upgrade" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-static/app.module.ts" region="hero-detail-upgrade" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -691,16 +691,16 @@ observing the following rules:
|
||||
For example, imagine a hero detail AngularJS component directive
|
||||
with one input and one output:
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/hero-detail.component.ts" region="hero-detail-io" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/hero-detail.component.ts" region="hero-detail-io" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
You can upgrade this component to Angular, annotate inputs and outputs in the upgrade directive,
|
||||
and then provide the input and output using Angular template syntax:
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/hero-detail.component.ts" region="hero-detail-io-upgrade" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/hero-detail.component.ts" region="hero-detail-io-upgrade" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/container.component.ts" title="container.component.ts">
|
||||
<code-example path="upgrade-module/src/app/upgrade-io/container.component.ts" header="container.component.ts">
|
||||
</code-example>
|
||||
|
||||
### Projecting AngularJS Content into Angular Components
|
||||
@ -716,7 +716,7 @@ is able to make these two features interoperate.
|
||||
Angular components that support content projection make use of an `<ng-content>`
|
||||
tag within them. Here's an example of such a component:
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-projection/hero-detail.component.ts" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-projection/hero-detail.component.ts" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
When using the component from AngularJS, you can supply contents for it. Just
|
||||
@ -745,13 +745,13 @@ When an AngularJS component directive supports transclusion, it may use
|
||||
the `ng-transclude` directive in its template to mark the transclusion
|
||||
point:
|
||||
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-transclusion/hero-detail.component.ts" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-transclusion/hero-detail.component.ts" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
If you upgrade this component and use it from Angular, you can populate
|
||||
the component tag with contents that will then get transcluded:
|
||||
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-transclusion/container.component.ts" title="container.component.ts">
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-transclusion/container.component.ts" header="container.component.ts">
|
||||
</code-example>
|
||||
|
||||
### Making AngularJS Dependencies Injectable to Angular
|
||||
@ -765,7 +765,7 @@ In these situations, it is possible to *upgrade* an AngularJS provider to
|
||||
Angular. This makes it possible to then inject it somewhere in Angular
|
||||
code. For example, you might have a service called `HeroesService` in AngularJS:
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/heroes.service.ts" title="heroes.service.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/heroes.service.ts" header="heroes.service.ts">
|
||||
</code-example>
|
||||
|
||||
You can upgrade the service using a Angular [factory provider](guide/dependency-injection-providers#factory-providers)
|
||||
@ -786,17 +786,17 @@ and append the "Service" suffix to create the class name.
|
||||
|
||||
</div>
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/ajs-upgraded-providers.ts" title="ajs-upgraded-providers.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/ajs-upgraded-providers.ts" header="ajs-upgraded-providers.ts">
|
||||
</code-example>
|
||||
|
||||
You can then provide the service to Angular by adding it to the `@NgModule`:
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/app.module.ts" region="register" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/app.module.ts" region="register" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Then use the service inside your component by injecting it in the component constructor using its class as a type annotation:
|
||||
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/hero-detail.component.ts" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/ajs-to-a-providers/hero-detail.component.ts" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -818,24 +818,24 @@ in Angular while retaining components written in AngularJS.
|
||||
|
||||
For example, you might have an Angular service called `Heroes`:
|
||||
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/heroes.ts" title="heroes.ts">
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/heroes.ts" header="heroes.ts">
|
||||
</code-example>
|
||||
|
||||
Again, as with Angular components, register the provider with the `NgModule` by adding it to the module's `providers` list.
|
||||
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/app.module.ts" region="ngmodule" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/app.module.ts" region="ngmodule" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Now wrap the Angular `Heroes` in an *AngularJS factory function* using `downgradeInjectable()`
|
||||
and plug the factory into an AngularJS module.
|
||||
The name of the AngularJS dependency is up to you:
|
||||
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/app.module.ts" region="register" title="app.module.ts">
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/app.module.ts" region="register" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
After this, the service is injectable anywhere in AngularJS code:
|
||||
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/hero-detail.component.ts" title="hero-detail.component.ts">
|
||||
<code-example path="upgrade-module/src/app/a-to-ajs-providers/hero-detail.component.ts" header="hero-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
## Using Ahead-of-time compilation with hybrid apps
|
||||
@ -853,7 +853,7 @@ An easy way to copy them is by adding each to the `copy-dist-files.js` file.
|
||||
You'll need to use the generated `AppModuleFactory`, instead of the original `AppModule` to
|
||||
bootstrap the hybrid app:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/main-aot.ts" title="app/main-aot.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/main-aot.ts" header="app/main-aot.ts">
|
||||
</code-example>
|
||||
|
||||
And that's all you need do to get the full benefit of AOT for Angular apps!
|
||||
@ -1100,20 +1100,20 @@ out of TypeScript's type system. For instance, you can annotate the checkmark
|
||||
filter so that it explicitly expects booleans as arguments. This makes it clearer
|
||||
what the filter is supposed to do.
|
||||
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/core/checkmark/checkmark.filter.ts" title="app/core/checkmark/checkmark.filter.ts">
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/core/checkmark/checkmark.filter.ts" header="app/core/checkmark/checkmark.filter.ts">
|
||||
</code-example>
|
||||
|
||||
In the `Phone` service, you can explicitly annotate the `$resource` service dependency
|
||||
as an `angular.resource.IResourceService` - a type defined by the AngularJS typings.
|
||||
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/core/phone/phone.service.ts" title="app/core/phone/phone.service.ts">
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/core/phone/phone.service.ts" header="app/core/phone/phone.service.ts">
|
||||
</code-example>
|
||||
|
||||
You can apply the same trick to the application's route configuration file in `app.config.ts`,
|
||||
where you are using the location and route services. By annotating them accordingly TypeScript
|
||||
can verify you're calling their APIs with the correct kinds of arguments.
|
||||
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/app.config.ts" title="app/app.config.ts">
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/app.config.ts" header="app/app.config.ts">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1142,7 +1142,7 @@ class as a component controller and AngularJS will happily use it.
|
||||
|
||||
Here's what the new class for the phone list component controller looks like:
|
||||
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/phone-list/phone-list.component.ts" title="app/phone-list/phone-list.component.ts">
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/phone-list/phone-list.component.ts" header="app/phone-list/phone-list.component.ts">
|
||||
</code-example>
|
||||
|
||||
What was previously done in the controller function is now done in the class
|
||||
@ -1160,7 +1160,7 @@ controller members.
|
||||
In the Phone detail controller, you'll have two members: One for the phone
|
||||
that the user is looking at and another for the URL of the currently displayed image:
|
||||
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/phone-detail/phone-detail.component.ts" title="app/phone-detail/phone-detail.component.ts">
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/phone-detail/phone-detail.component.ts" header="app/phone-detail/phone-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
This makes the controller code look a lot more like Angular already. You're
|
||||
@ -1220,14 +1220,14 @@ want to have to change all the image and data paths used in the application code
|
||||
the development setup. For that reason, you'll add a `<base>` tag to `index.html`, which will
|
||||
cause relative URLs to be resolved back to the `/app` directory:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/index.html" region="base" title="index.html">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/index.html" region="base" header="index.html">
|
||||
</code-example>
|
||||
|
||||
Now you can load Angular via SystemJS. You'll add the Angular polyfills and the
|
||||
SystemJS config to the end of the `<head>` section, and then you'll use `System.import`
|
||||
to load the actual application:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/index.html" region="angular" title="index.html">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/index.html" region="angular" header="index.html">
|
||||
</code-example>
|
||||
|
||||
You also need to make a couple of adjustments
|
||||
@ -1239,7 +1239,7 @@ instead of using the `<base>` URL.
|
||||
Install the `upgrade` package via `npm install @angular/upgrade --save`
|
||||
and add a mapping for the `@angular/upgrade/static` package.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/systemjs.config.1.js" region="paths" title="systemjs.config.js">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/systemjs.config.1.js" region="paths" header="systemjs.config.js">
|
||||
</code-example>
|
||||
|
||||
### Creating the _AppModule_
|
||||
@ -1249,12 +1249,12 @@ There is already a file named `app.module.ts` that holds the AngularJS module.
|
||||
Rename it to `app.module.ajs.ts` and update the corresponding script name in the `index.html` as well.
|
||||
The file contents remain:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ajs.ts" title="app.module.ajs.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ajs.ts" header="app.module.ajs.ts">
|
||||
</code-example>
|
||||
|
||||
Now create a new `app.module.ts` with the minimum `NgModule` class:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="bare" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="bare" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
### Bootstrapping a hybrid PhoneCat
|
||||
@ -1271,7 +1271,7 @@ instead.
|
||||
First, remove the `ng-app` attribute from `index.html`.
|
||||
Then import `UpgradeModule` in the `AppModule`, and override its `ngDoBootstrap` method:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="upgrademodule" title="app/app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="upgrademodule" header="app/app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Note that you are bootstrapping the AngularJS module from inside `ngDoBootstrap`.
|
||||
@ -1283,7 +1283,7 @@ Finally, bootstrap the `AppModule` in `app/main.ts`.
|
||||
This file has been configured as the application entrypoint in `systemjs.config.js`,
|
||||
so it is already being loaded by the browser.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/main.ts" region="bootstrap" title="app/main.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/main.ts" region="bootstrap" header="app/main.ts">
|
||||
</code-example>
|
||||
|
||||
Now you're running both AngularJS and Angular at the same time. That's pretty
|
||||
@ -1328,13 +1328,13 @@ In the new version, you import the Angular HTTP module and call its `Http` servi
|
||||
|
||||
Re-open the `app.module.ts` file, import and add `HttpModule` to the `imports` array of the `AppModule`:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="httpmodule" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="httpmodule" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Now you're ready to upgrade the Phone service itself. Replace the ngResource-based
|
||||
service in `phone.service.ts` with a TypeScript class decorated as `@Injectable`:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="classdef" title="app/core/phone/phone.service.ts (skeleton)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="classdef" header="app/core/phone/phone.service.ts (skeleton)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
The `@Injectable` decorator will attach some dependency injection metadata
|
||||
@ -1348,24 +1348,24 @@ be injected to it and it is stored as a private field. The service is then
|
||||
used in the two instance methods, one of which loads the list of all phones,
|
||||
and the other loads the details of a specified phone:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="fullclass" title="app/core/phone/phone.service.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="fullclass" header="app/core/phone/phone.service.ts">
|
||||
</code-example>
|
||||
|
||||
The methods now return observables of type `PhoneData` and `PhoneData[]`. This is
|
||||
a type you don't have yet. Add a simple interface for it:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="phonedata-interface" title="app/core/phone/phone.service.ts (interface)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="phonedata-interface" header="app/core/phone/phone.service.ts (interface)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
`@angular/upgrade/static` has a `downgradeInjectable` method for the purpose of making
|
||||
Angular services available to AngularJS code. Use it to plug in the `Phone` service:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="downgrade-injectable" title="app/core/phone/phone.service.ts (downgrade)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" region="downgrade-injectable" header="app/core/phone/phone.service.ts (downgrade)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Here's the full, final code for the service:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" title="app/core/phone/phone.service.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.ts" header="app/core/phone/phone.service.ts">
|
||||
</code-example>
|
||||
|
||||
Notice that you're importing the `map` operator of the RxJS `Observable` separately.
|
||||
@ -1374,7 +1374,7 @@ Do this for every RxJS operator.
|
||||
The new `Phone` service has the same features as the original, `ngResource`-based service.
|
||||
Because it's an Angular service, you register it with the `NgModule` providers:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="phone" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="phone" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Now that you are loading `phone.service.ts` through an import that is resolved
|
||||
@ -1386,10 +1386,10 @@ At this point, you can switch the two components to use the new service
|
||||
instead of the old one. While you `$inject` it as the downgraded `phone` factory,
|
||||
it's really an instance of the `Phone` class and you annotate its type accordingly:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ajs.ts" title="app/phone-list/phone-list.component.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ajs.ts" header="app/phone-list/phone-list.component.ts">
|
||||
</code-example>
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.component.ajs.ts" title="app/phone-detail/phone-detail.component.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.component.ajs.ts" header="app/phone-detail/phone-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
Now there are two AngularJS components using an Angular service!
|
||||
@ -1418,7 +1418,7 @@ an Angular component by just renaming the controller class and turning the
|
||||
AngularJS component definition object into an Angular `@Component` decorator.
|
||||
You can then also remove the static `$inject` property from the class:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ts" region="initialclass" title="app/phone-list/phone-list.component.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ts" region="initialclass" header="app/phone-list/phone-list.component.ts">
|
||||
</code-example>
|
||||
|
||||
The `selector` attribute is a CSS selector that defines where on the page the component
|
||||
@ -1430,14 +1430,14 @@ Now convert the template of this component into Angular syntax.
|
||||
The search controls replace the AngularJS `$ctrl` expressions
|
||||
with Angular's two-way `[(ngModel)]` binding syntax:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.template.html" region="controls" title="app/phone-list/phone-list.template.html (search controls)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.template.html" region="controls" header="app/phone-list/phone-list.template.html (search controls)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Replace the list's `ng-repeat` with an `*ngFor` as
|
||||
[described in the Template Syntax page](guide/template-syntax#directives).
|
||||
Replace the image tag's `ng-src` with a binding to the native `src` property.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.template.html" region="list" title="app/phone-list/phone-list.template.html (phones)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.template.html" region="list" header="app/phone-list/phone-list.template.html (phones)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
#### No Angular _filter_ or _orderBy_ filters
|
||||
@ -1448,7 +1448,7 @@ so you need to do the filtering and sorting yourself.
|
||||
You replaced the `filter` and `orderBy` filters with bindings to the `getPhones()` controller method,
|
||||
which implements the filtering and ordering logic inside the component itself.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ts" region="getphones" title="app/phone-list/phone-list.component.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ts" region="getphones" header="app/phone-list/phone-list.component.ts">
|
||||
</code-example>
|
||||
|
||||
Now you need to downgrade the Angular component so you can use it in AngularJS.
|
||||
@ -1458,21 +1458,21 @@ a downgraded version of the Angular component.
|
||||
The `as angular.IDirectiveFactory` cast tells the TypeScript compiler
|
||||
that the return value of the `downgradeComponent` method is a directive factory.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ts" region="downgrade-component" title="app/phone-list/phone-list.component.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.ts" region="downgrade-component" header="app/phone-list/phone-list.component.ts">
|
||||
</code-example>
|
||||
|
||||
The new `PhoneListComponent` uses the Angular `ngModel` directive, located in the `FormsModule`.
|
||||
Add the `FormsModule` to `NgModule` imports, declare the new `PhoneListComponent` and
|
||||
finally add it to `entryComponents` since you downgraded it:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="phonelist" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="phonelist" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
Remove the <script> tag for the phone list component from `index.html`.
|
||||
|
||||
Now set the remaining `phone-detail.component.ts` as follows:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.component.ts" title="app/phone-detail/phone-detail.component.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.component.ts" header="app/phone-detail/phone-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
This is similar to the phone list component.
|
||||
@ -1487,15 +1487,15 @@ You must upgrade this service via a [factory provider](guide/upgrade#making-angu
|
||||
to make `$routeParams` an Angular injectable.
|
||||
Do that in a new file called `ajs-upgraded-providers.ts` and import it in `app.module.ts`:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/ajs-upgraded-providers.ts" title="app/ajs-upgraded-providers.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/ajs-upgraded-providers.ts" header="app/ajs-upgraded-providers.ts">
|
||||
</code-example>
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="routeparams" title="app/app.module.ts ($routeParams)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="routeparams" header="app/app.module.ts ($routeParams)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Convert the phone detail component template into Angular syntax as follows:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.template.html" title="app/phone-detail/phone-detail.template.html">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.template.html" header="app/phone-detail/phone-detail.template.html">
|
||||
</code-example>
|
||||
|
||||
There are several notable changes here:
|
||||
@ -1524,7 +1524,7 @@ There are several notable changes here:
|
||||
|
||||
Add `PhoneDetailComponent` component to the `NgModule` _declarations_ and _entryComponents_:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="phonedetail" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="phonedetail" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
You should now also remove the phone detail component <script> tag from `index.html`.
|
||||
@ -1540,13 +1540,13 @@ It's easy to turn the filter function into an equivalent Pipe class.
|
||||
The implementation is the same as before, repackaged in the `transform` method.
|
||||
Rename the file to `checkmark.pipe.ts` to conform with Angular conventions:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/checkmark/checkmark.pipe.ts" title="app/core/checkmark/checkmark.pipe.ts" linenums="false">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/checkmark/checkmark.pipe.ts" header="app/core/checkmark/checkmark.pipe.ts" linenums="false">
|
||||
</code-example>
|
||||
|
||||
Now import and declare the newly created pipe and
|
||||
remove the filter <script> tag from `index.html`:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="checkmarkpipe" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/app.module.ts" region="checkmarkpipe" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
### AOT compile the hybrid app
|
||||
@ -1557,13 +1557,13 @@ as shown in [the Ahead-of-time Compilation chapter](guide/aot-compiler).
|
||||
Then change `main-aot.ts` to bootstrap the `AppComponentFactory` that was generated
|
||||
by the AOT compiler:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/main-aot.ts" title="app/main-aot.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/main-aot.ts" header="app/main-aot.ts">
|
||||
</code-example>
|
||||
|
||||
You need to load all the AngularJS files you already use in `index.html` in `aot/index.html`
|
||||
as well:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/aot/index.html" title="aot/index.html">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/aot/index.html" header="aot/index.html">
|
||||
</code-example>
|
||||
|
||||
These files need to be copied together with the polyfills. The files the application
|
||||
@ -1572,7 +1572,7 @@ needs at runtime, like the `.json` phone lists and images, also need to be copie
|
||||
Install `fs-extra` via `npm install fs-extra --save-dev` for better file copying, and change
|
||||
`copy-dist-files.js` to the following:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/copy-dist-files.js" title="copy-dist-files.js">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/copy-dist-files.js" header="copy-dist-files.js">
|
||||
</code-example>
|
||||
|
||||
And that's all you need to use AOT while upgrading your app!
|
||||
@ -1593,7 +1593,7 @@ at the top of the applications component tree.
|
||||
You don't yet have such a root component, because the app is still managed as an AngularJS app.
|
||||
Create a new `app.component.ts` file with the following `AppComponent` class:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/app.component.ts" title="app/app.component.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/app.component.ts" header="app/app.component.ts">
|
||||
</code-example>
|
||||
|
||||
It has a simple template that only includes the `<router-outlet>.
|
||||
@ -1605,7 +1605,7 @@ element on the host web page when the application launches.
|
||||
Add this `<phonecat-app>` element to the `index.html`.
|
||||
It replaces the old AngularJS `ng-view` directive:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/index.html" region="appcomponent" title="index.html (body)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-3-final/index.html" region="appcomponent" header="index.html (body)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
#### Create the _Routing Module_
|
||||
@ -1615,7 +1615,7 @@ The details of Angular router configuration are best left to the [Routing docume
|
||||
which recommends that you create a `NgModule` dedicated to router configuration
|
||||
(called a _Routing Module_).
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/app-routing.module.ts" title="app/app-routing.module.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/app-routing.module.ts" header="app/app-routing.module.ts">
|
||||
</code-example>
|
||||
|
||||
This module defines a `routes` object with two routes to the two phone components
|
||||
@ -1633,7 +1633,7 @@ insert its view into the host web page.
|
||||
You must also remove the bootstrap of the AngularJS module from `ngDoBootstrap()` in `app.module.ts`
|
||||
and the `UpgradeModule` import.
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/app.module.ts" title="app/app.module.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/app.module.ts" header="app/app.module.ts">
|
||||
</code-example>
|
||||
|
||||
And since you are routing to `PhoneListComponent` and `PhoneDetailComponent` directly rather than
|
||||
@ -1646,7 +1646,7 @@ You no longer have to hardcode the links to phone details in the phone list.
|
||||
You can generate data bindings for each phone's `id` to the `routerLink` directive
|
||||
and let that directive construct the appropriate URL to the `PhoneDetailComponent`:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-list/phone-list.template.html" region="list" title="app/phone-list/phone-list.template.html (list with links)" linenums="false">
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-list/phone-list.template.html" region="list" header="app/phone-list/phone-list.template.html (list with links)" linenums="false">
|
||||
</code-example>
|
||||
|
||||
<div class="alert is-helpful">
|
||||
@ -1661,7 +1661,7 @@ The Angular router passes route parameters differently.
|
||||
Correct the `PhoneDetail` component constructor to expect an injected `ActivatedRoute` object.
|
||||
Extract the `phoneId` from the `ActivatedRoute.snapshot.params` and fetch the phone data as before:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-detail/phone-detail.component.ts" title="app/phone-detail/phone-detail.component.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-detail/phone-detail.component.ts" header="app/phone-detail/phone-detail.component.ts">
|
||||
</code-example>
|
||||
|
||||
You are now running a pure Angular application!
|
||||
@ -1677,7 +1677,7 @@ There's no need for that anymore.
|
||||
|
||||
Switch the bootstrap method of the application from the `UpgradeModule` to the Angular way.
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/main.ts" title="main.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/main.ts" header="main.ts">
|
||||
</code-example>
|
||||
|
||||
If you haven't already, remove all references to the `UpgradeModule` from `app.module.ts`,
|
||||
@ -1689,7 +1689,7 @@ together with the associated AngularJS factory or directive declarations.
|
||||
Since you no longer have downgraded components, you no longer list them
|
||||
in `entryComponents`.
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/app.module.ts" title="app.module.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/app.module.ts" header="app.module.ts">
|
||||
</code-example>
|
||||
|
||||
You may also completely remove the following files. They are AngularJS
|
||||
@ -1714,7 +1714,7 @@ The `@angular/upgrade` package and its mapping in `systemjs.config.js` can also
|
||||
Finally, from `index.html`, remove all references to AngularJS scripts and jQuery.
|
||||
When you're done, this is what it should look like:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/index.html" region="full" title="index.html">
|
||||
<code-example path="upgrade-phonecat-3-final/index.html" region="full" header="index.html">
|
||||
</code-example>
|
||||
|
||||
That is the last you'll see of AngularJS! It has served us well but now
|
||||
@ -1869,12 +1869,12 @@ service is no longer present after the upgrade, replace those calls with ones
|
||||
that use WebDriver's generic URL APIs instead. The first of these is
|
||||
the redirection spec:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/e2e-spec.ts" region="redirect" title="e2e-tests/scenarios.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/e2e-spec.ts" region="redirect" header="e2e-tests/scenarios.ts">
|
||||
</code-example>
|
||||
|
||||
And the second is the phone links spec:
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/e2e-spec.ts" region="links" title="e2e-tests/scenarios.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/e2e-spec.ts" region="links" header="e2e-tests/scenarios.ts">
|
||||
</code-example>
|
||||
|
||||
### Unit Tests
|
||||
@ -1889,14 +1889,14 @@ For instance, in the phone detail component spec, you can use ES2015
|
||||
features like arrow functions and block-scoped variables and benefit from the type
|
||||
definitions of the AngularJS services you're consuming:
|
||||
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/phone-detail/phone-detail.component.spec.ts" title="app/phone-detail/phone-detail.component.spec.ts">
|
||||
<code-example path="upgrade-phonecat-1-typescript/app/phone-detail/phone-detail.component.spec.ts" header="app/phone-detail/phone-detail.component.spec.ts">
|
||||
</code-example>
|
||||
|
||||
Once you start the upgrade process and bring in SystemJS, configuration changes
|
||||
are needed for Karma. You need to let SystemJS load all the new Angular code,
|
||||
which can be done with the following kind of shim file:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma-test-shim.1.js" title="karma-test-shim.js">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma-test-shim.1.js" header="karma-test-shim.js">
|
||||
</code-example>
|
||||
|
||||
The shim first loads the SystemJS configuration, then Angular's test support libraries,
|
||||
@ -1905,53 +1905,53 @@ and then the application's spec files themselves.
|
||||
Karma configuration should then be changed so that it uses the application root dir
|
||||
as the base directory, instead of `app`.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma.conf.ajs.js" region="basepath" title="karma.conf.js">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma.conf.ajs.js" region="basepath" header="karma.conf.js">
|
||||
</code-example>
|
||||
|
||||
Once done, you can load SystemJS and other dependencies, and also switch the configuration
|
||||
for loading application files so that they are *not* included to the page by Karma. You'll let
|
||||
the shim and SystemJS load them.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma.conf.ajs.js" region="files" title="karma.conf.js">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma.conf.ajs.js" region="files" header="karma.conf.js">
|
||||
</code-example>
|
||||
|
||||
Since the HTML templates of Angular components will be loaded as well, you must help
|
||||
Karma out a bit so that it can route them to the right paths:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma.conf.ajs.js" region="html" title="karma.conf.js">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/karma.conf.ajs.js" region="html" header="karma.conf.js">
|
||||
</code-example>
|
||||
|
||||
The unit test files themselves also need to be switched to Angular when their production
|
||||
counterparts are switched. The specs for the checkmark pipe are probably the most straightforward,
|
||||
as the pipe has no dependencies:
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/checkmark/checkmark.pipe.spec.ts" title="app/core/checkmark/checkmark.pipe.spec.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/checkmark/checkmark.pipe.spec.ts" header="app/core/checkmark/checkmark.pipe.spec.ts">
|
||||
</code-example>
|
||||
|
||||
The unit test for the phone service is a bit more involved. You need to switch from the mocked-out
|
||||
AngularJS `$httpBackend` to a mocked-out Angular Http backend.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.spec.ts" title="app/core/phone/phone.service.spec.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/core/phone/phone.service.spec.ts" header="app/core/phone/phone.service.spec.ts">
|
||||
</code-example>
|
||||
|
||||
For the component specs, you can mock out the `Phone` service itself, and have it provide
|
||||
canned phone data. You use Angular's component unit testing APIs for both components.
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.component.spec.ts" title="app/phone-detail/phone-detail.component.spec.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-detail/phone-detail.component.spec.ts" header="app/phone-detail/phone-detail.component.spec.ts">
|
||||
</code-example>
|
||||
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.spec.ts" title="app/phone-list/phone-list.component.spec.ts">
|
||||
<code-example path="upgrade-phonecat-2-hybrid/app/phone-list/phone-list.component.spec.ts" header="app/phone-list/phone-list.component.spec.ts">
|
||||
</code-example>
|
||||
|
||||
Finally, revisit both of the component tests when you switch to the Angular
|
||||
router. For the details component, provide a mock of Angular `ActivatedRoute` object
|
||||
instead of using the AngularJS `$routeParams`.
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-detail/phone-detail.component.spec.ts" region="activatedroute" title="app/phone-detail/phone-detail.component.spec.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-detail/phone-detail.component.spec.ts" region="activatedroute" header="app/phone-detail/phone-detail.component.spec.ts">
|
||||
</code-example>
|
||||
|
||||
And for the phone list component, a few adjustments to the router make
|
||||
the `RouteLink` directives work.
|
||||
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-list/phone-list.component.spec.ts" region="routestuff" title="app/phone-list/phone-list.component.spec.ts">
|
||||
<code-example path="upgrade-phonecat-3-final/app/phone-list/phone-list.component.spec.ts" region="routestuff" header="app/phone-list/phone-list.component.spec.ts">
|
||||
</code-example>
|
||||
|
@ -20,7 +20,7 @@ To bind to a DOM event, surround the DOM event name in parentheses and assign a
|
||||
|
||||
The following example shows an event binding that implements a click handler:
|
||||
|
||||
<code-example path="user-input/src/app/click-me.component.ts" region="click-me-button" title="src/app/click-me.component.ts" linenums="false">
|
||||
<code-example path="user-input/src/app/click-me.component.ts" region="click-me-button" header="src/app/click-me.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -37,7 +37,7 @@ usually the Angular component controlling the template.
|
||||
The example above shows a single line of HTML, but that HTML belongs to a larger component:
|
||||
|
||||
|
||||
<code-example path="user-input/src/app/click-me.component.ts" region="click-me-component" title="src/app/click-me.component.ts" linenums="false">
|
||||
<code-example path="user-input/src/app/click-me.component.ts" region="click-me-component" header="src/app/click-me.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -53,7 +53,7 @@ This section shows how to bind to the `keyup` event of an input box to get the u
|
||||
|
||||
The following code listens to the `keyup` event and passes the entire event payload (`$event`) to the component event handler.
|
||||
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-1-template" title="src/app/keyup.components.ts (template v.1)" linenums="false">
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-1-template" header="src/app/keyup.components.ts (template v.1)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -62,7 +62,7 @@ The following code listens to the `keyup` event and passes the entire event payl
|
||||
When a user presses and releases a key, the `keyup` event occurs, and Angular provides a corresponding
|
||||
DOM event object in the `$event` variable which this code passes as a parameter to the component's `onKey()` method.
|
||||
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-1-class-no-type" title="src/app/keyup.components.ts (class v.1)" linenums="false">
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-1-class-no-type" header="src/app/keyup.components.ts (class v.1)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -126,7 +126,7 @@ that could reveal properties of the event object and prevent silly mistakes.
|
||||
|
||||
The following example rewrites the method with types:
|
||||
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-1-class" title="src/app/keyup.components.ts (class v.1 - typed )" linenums="false">
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-1-class" header="src/app/keyup.components.ts (class v.1 - typed )" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -156,7 +156,7 @@ To declare a template reference variable, precede an identifier with a hash (or
|
||||
The following example uses a template reference variable
|
||||
to implement a keystroke loopback in a simple template.
|
||||
|
||||
<code-example path="user-input/src/app/loop-back.component.ts" region="loop-back-component" title="src/app/loop-back.component.ts" linenums="false">
|
||||
<code-example path="user-input/src/app/loop-back.component.ts" region="loop-back-component" header="src/app/loop-back.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -200,7 +200,7 @@ It's easier to get to the input box with the template reference
|
||||
variable than to go through the `$event` object. Here's a rewrite of the previous
|
||||
`keyup` example that uses a template reference variable to get the user's input.
|
||||
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-2" title="src/app/keyup.components.ts (v2)" linenums="false">
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-2" header="src/app/keyup.components.ts (v2)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -219,7 +219,7 @@ One way to reduce the noise would be to examine every `$event.keyCode` and take
|
||||
There's an easier way: bind to Angular's `keyup.enter` pseudo-event.
|
||||
Then Angular calls the event handler only when the user presses _Enter_.
|
||||
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-3" title="src/app/keyup.components.ts (v3)" linenums="false">
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-3" header="src/app/keyup.components.ts (v3)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -244,7 +244,7 @@ The component's `value` property is updated only when the user presses _Enter_.
|
||||
To fix this issue, listen to both the _Enter_ key and the _blur_ event.
|
||||
|
||||
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-4" title="src/app/keyup.components.ts (v4)" linenums="false">
|
||||
<code-example path="user-input/src/app/keyup.components.ts" region="key-up-component-4" header="src/app/keyup.components.ts (v4)" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -270,7 +270,7 @@ clicking **Add**.
|
||||
Below is the "Little Tour of Heroes" component.
|
||||
|
||||
|
||||
<code-example path="user-input/src/app/little-tour.component.ts" region="little-tour" title="src/app/little-tour.component.ts" linenums="false">
|
||||
<code-example path="user-input/src/app/little-tour.component.ts" region="little-tour" header="src/app/little-tour.component.ts" linenums="false">
|
||||
|
||||
</code-example>
|
||||
|
||||
@ -299,19 +299,19 @@ Following is all the code discussed in this page.
|
||||
|
||||
<code-tabs>
|
||||
|
||||
<code-pane title="click-me.component.ts" path="user-input/src/app/click-me.component.ts">
|
||||
<code-pane header="click-me.component.ts" path="user-input/src/app/click-me.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="keyup.components.ts" path="user-input/src/app/keyup.components.ts">
|
||||
<code-pane header="keyup.components.ts" path="user-input/src/app/keyup.components.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="loop-back.component.ts" path="user-input/src/app/loop-back.component.ts">
|
||||
<code-pane header="loop-back.component.ts" path="user-input/src/app/loop-back.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
<code-pane title="little-tour.component.ts" path="user-input/src/app/little-tour.component.ts">
|
||||
<code-pane header="little-tour.component.ts" path="user-input/src/app/little-tour.component.ts">
|
||||
|
||||
</code-pane>
|
||||
|
||||
|
BIN
aio/content/images/bios/brian-love.jpg
Normal file
BIN
aio/content/images/bios/brian-love.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 162 KiB |
BIN
aio/content/images/bios/katerina.jpg
Normal file
BIN
aio/content/images/bios/katerina.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 59 KiB |
@ -17,6 +17,17 @@
|
||||
<a href="https://github.com/angular/angular/blob/master/CONTRIBUTING.md" class="button button-blue" md-button>Contribute</a>
|
||||
</div>
|
||||
|
||||
<div class="card-section">
|
||||
<div>
|
||||
<h3 class="no-anchor">Angular CLI</h3>
|
||||
|
||||
Angular CLI makes it easy to create an application that already works, right out of the box. It already follows our best practices.
|
||||
|
||||
</div>
|
||||
|
||||
<a href="https://github.com/angular/angular-cli/blob/master/CONTRIBUTING.md" class="button button-blue" md-button>Contribute</a>
|
||||
</div>
|
||||
|
||||
<div class="card-section">
|
||||
<div>
|
||||
<h3 class="no-anchor">Angular Material</h3>
|
||||
@ -37,7 +48,7 @@
|
||||
to build your Angular app.
|
||||
|
||||
</div>
|
||||
<a href="https://github.com/angular/angularfire2" class="button button-blue" md-button> Contribute</a>
|
||||
<a href="https://github.com/angular/angularfire2/blob/master/CONTRIBUTING.md" class="button button-blue" md-button> Contribute</a>
|
||||
</div>
|
||||
|
||||
</article>
|
||||
|
@ -680,5 +680,23 @@
|
||||
"website": "https://lacolaco.net",
|
||||
"bio": "Suguru is a community-loving Frontend developer and a lead of Angular Japan User Group. He organizes the largest Angular event in Japan (ng-japan). And he is a contributor to Angular by sending patches, writing, speaking, and localizing resources in Japanese.",
|
||||
"group": "GDE"
|
||||
},
|
||||
|
||||
"katerina": {
|
||||
"name": "Katerina Skroumpelou",
|
||||
"picture": "katerina.jpg",
|
||||
"twitter": "psybercity",
|
||||
"website": "https://mandarini.github.io/",
|
||||
"bio": "Katerina is a front end software engineer, a conference speaker and AngularAthens meetup organizer. She is obsessed with sharing knowledge about things she loves. She is also trying to support diversity in the community. She lives with her cat in Athens.",
|
||||
"group": "GDE"
|
||||
},
|
||||
|
||||
"blove": {
|
||||
"name": "Brian Love",
|
||||
"picture": "brian-love.jpg",
|
||||
"twitter": "brian_love",
|
||||
"website": "https://brianflove.com",
|
||||
"bio": "Brian is a software engineer and GDE in Angular with a passion for learning, writing, speaking, teaching and mentoring. Brian has been building web applications for over 20 years and has long been a fanboy of JavaScript. When not in front of his Macbook Pro Brian is in the Rocky Mountains skiing or hiking.",
|
||||
"group": "GDE"
|
||||
}
|
||||
}
|
||||
|
@ -13,12 +13,6 @@
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<!-- AngularMix -->
|
||||
<tr>
|
||||
<th><a href="https://angularmix.com/" title="AngularMix">AngularMix</a></th>
|
||||
<td>Orlando, Florida</td>
|
||||
<td>October 10-12, 2018</td>
|
||||
</tr>
|
||||
<!-- ReactiveConf -->
|
||||
<tr>
|
||||
<th><a href="https://reactiveconf.com/" title="ReactiveConf">ReactiveConf</a></th>
|
||||
@ -44,41 +38,11 @@
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<!-- AngularConnect-->
|
||||
<tr>
|
||||
<th><a href="http://angularconnect.com" title="AngularConnect">AngularConnect</a></th>
|
||||
<td>London, United Kingdom</td>
|
||||
<td>November 7-8, 2017</td>
|
||||
</tr>
|
||||
<!-- ngAtlanta-->
|
||||
<tr>
|
||||
<th><a href="http://ng-atl.org/" title="ngAtlanta">ngAtlanta</a></th>
|
||||
<td>Atlanta, Georgia</td>
|
||||
<td>January 30, 2018</td>
|
||||
</tr>
|
||||
<!-- ngVikings-->
|
||||
<tr>
|
||||
<th><a href="https://ngvikings.org/" title="ngVikings">ngVikings</a></th>
|
||||
<td>Helsinki, Finland</td>
|
||||
<td>March 1-2, 2018</td>
|
||||
</tr>
|
||||
<!-- ngconf 2018-->
|
||||
<tr>
|
||||
<th><a href="https://www.ng-conf.org/" title="ng-conf">ng-conf</a></th>
|
||||
<td>Salt Lake City, Utah</td>
|
||||
<td>April 18-20, 2018</td>
|
||||
</tr>
|
||||
<!-- WeRDevs-->
|
||||
<tr>
|
||||
<th><a href="https://www.wearedevelopers.com/" title="WeAreDevs">WeAreDevelopers</a></th>
|
||||
<td>Vienna, Austria</td>
|
||||
<td>May 16-18, 2018</td>
|
||||
</tr>
|
||||
<!-- ngJapan-->
|
||||
<tr>
|
||||
<th><a href="https://ngjapan.org/en.html" title="ng-japan">ng-japan</a></th>
|
||||
<td>Tokyo, Japan</td>
|
||||
<td>Jun 16, 2018</td>
|
||||
<!-- AngularMix -->
|
||||
<tr>
|
||||
<th><a href="https://angularmix.com/" title="AngularMix">AngularMix</a></th>
|
||||
<td>Orlando, Florida</td>
|
||||
<td>October 10-12, 2018</td>
|
||||
</tr>
|
||||
<!-- Angular Conf Australia-->
|
||||
<tr>
|
||||
@ -86,6 +50,36 @@
|
||||
<td>Melbourne, Australia</td>
|
||||
<td>Jun 22, 2018</td>
|
||||
</tr>
|
||||
<!-- ngJapan-->
|
||||
<tr>
|
||||
<th><a href="https://ngjapan.org/en.html" title="ng-japan">ng-japan</a></th>
|
||||
<td>Tokyo, Japan</td>
|
||||
<td>Jun 16, 2018</td>
|
||||
</tr>
|
||||
<!-- WeRDevs-->
|
||||
<tr>
|
||||
<th><a href="https://www.wearedevelopers.com/" title="WeAreDevs">WeAreDevelopers</a></th>
|
||||
<td>Vienna, Austria</td>
|
||||
<td>May 16-18, 2018</td>
|
||||
</tr>
|
||||
<!-- ngconf 2018-->
|
||||
<tr>
|
||||
<th><a href="https://www.ng-conf.org/" title="ng-conf">ng-conf</a></th>
|
||||
<td>Salt Lake City, Utah</td>
|
||||
<td>April 18-20, 2018</td>
|
||||
</tr>
|
||||
<!-- ngVikings-->
|
||||
<tr>
|
||||
<th><a href="https://ngvikings.org/" title="ngVikings">ngVikings</a></th>
|
||||
<td>Helsinki, Finland</td>
|
||||
<td>March 1-2, 2018</td>
|
||||
</tr>
|
||||
<!-- ngAtlanta-->
|
||||
<tr>
|
||||
<th><a href="http://ng-atl.org/" title="ngAtlanta">ngAtlanta</a></th>
|
||||
<td>Atlanta, Georgia</td>
|
||||
<td>January 30, 2018</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</article>
|
||||
|
@ -6,37 +6,37 @@
|
||||
|
||||
<p>No linenums at code-tabs level</p>
|
||||
<code-tabs >
|
||||
<code-pane title='TS code file' language='ts'>
|
||||
<code-pane header='TS code file' language='ts'>
|
||||
class {
|
||||
foo(param: string) {}
|
||||
}
|
||||
</code-pane>
|
||||
<code-pane title='HTML content file' language='html'><h1>Heading</h1></code-pane>
|
||||
<code-pane title='JSON data file' language='json' class='avoid'>{ "key": "value" }</code-pane>
|
||||
<code-pane header='HTML content file' language='html'><h1>Heading</h1></code-pane>
|
||||
<code-pane header='JSON data file' language='json' class='avoid'>{ "key": "value" }</code-pane>
|
||||
</code-tabs>
|
||||
<p></p>
|
||||
|
||||
<p>linenums=true at code-tabs level</p>
|
||||
<code-tabs linenums='true'>
|
||||
<code-pane title='TS code file' language='ts'>
|
||||
<code-pane header='TS code file' language='ts'>
|
||||
class {
|
||||
foo(param: string) {}
|
||||
}
|
||||
</code-pane>
|
||||
<code-pane title='HTML content file' language='html'><h1>Heading</h1></code-pane>
|
||||
<code-pane title='JSON data file' language='json' class='avoid'>{ "key": "value" }</code-pane>
|
||||
<code-pane header='HTML content file' language='html'><h1>Heading</h1></code-pane>
|
||||
<code-pane header='JSON data file' language='json' class='avoid'>{ "key": "value" }</code-pane>
|
||||
</code-tabs>
|
||||
<p></p>
|
||||
|
||||
<p>No linenums at code-tabs level; linenums=true for HTML pane</p>
|
||||
<code-tabs >
|
||||
<code-pane title='TS code file' language='ts'>
|
||||
<code-pane header='TS code file' language='ts'>
|
||||
class {
|
||||
foo(param: string) {}
|
||||
}
|
||||
</code-pane>
|
||||
<code-pane title='HTML content file' language='html' linenums='true'><h1>Heading</h1></code-pane>
|
||||
<code-pane title='JSON data file' language='json' class='avoid'>{ "key": "value" }</code-pane>
|
||||
<code-pane header='HTML content file' language='html' linenums='true'><h1>Heading</h1></code-pane>
|
||||
<code-pane header='JSON data file' language='json' class='avoid'>{ "key": "value" }</code-pane>
|
||||
</code-tabs>
|
||||
<p></p>
|
||||
|
||||
@ -66,7 +66,7 @@
|
||||
</code-example>
|
||||
|
||||
<p>Header on this one.</p>
|
||||
<code-example title="hero-details.component.ts (excerpt)">
|
||||
<code-example header="hero-details.component.ts (excerpt)">
|
||||
<hero-details <em>nghost-pmm-5>
|
||||
<h2 </em>ngcontent-pmm-5>Mister Fantastic</h2>
|
||||
<hero-team <em>ngcontent-pmm-5 </em>nghost-pmm-6>
|
||||
@ -76,7 +76,7 @@
|
||||
</code-example>
|
||||
|
||||
<p>An "avoid" header on this one.</p>
|
||||
<code-example class="avoid" title="hero-details.component.ts (Avoid)">
|
||||
<code-example class="avoid" header="hero-details.component.ts (Avoid)">
|
||||
<hero-details <em>nghost-pmm-5>
|
||||
<h2 </em>ngcontent-pmm-5>Mister Fantastic</h2>
|
||||
<hero-team <em>ngcontent-pmm-5 </em>nghost-pmm-6>
|
||||
|
@ -473,7 +473,7 @@
|
||||
"url": "guide/universal",
|
||||
"title": "Server-side Rendering",
|
||||
"tooltip": "Render HTML server-side with Angular Universal."
|
||||
},
|
||||
},
|
||||
{
|
||||
"title": "Upgrading from AngularJS",
|
||||
"tooltip": "Incrementally upgrade an AngularJS application to Angular.",
|
||||
@ -509,22 +509,22 @@
|
||||
"tooltip": "Install the Angular QuickStart seed for faster, more efficient development on your machine.",
|
||||
"hidden": true
|
||||
},
|
||||
|
||||
|
||||
{
|
||||
"url": "guide/file-structure",
|
||||
"title": "Project File Structure",
|
||||
"tooltip": "Inside the local development environment for SystemJS."
|
||||
"tooltip": "How your Angular workspace looks in your filesystem."
|
||||
},
|
||||
{
|
||||
"url": "guide/npm-packages",
|
||||
"title": "Packages",
|
||||
"tooltip": "Explanation of npm packages installed into a project by default."
|
||||
"title": "npm Dependencies",
|
||||
"tooltip": "Description of npm packages required at development time and at runtime."
|
||||
},
|
||||
{
|
||||
"url": "guide/typescript-configuration",
|
||||
"title": "TypeScript Configuration",
|
||||
"tooltip": "TypeScript configuration for Angular developers."
|
||||
},
|
||||
},
|
||||
{
|
||||
"url": "guide/aot-compiler",
|
||||
"title": "Ahead-of-Time Compilation",
|
||||
@ -544,14 +544,14 @@
|
||||
"url": "guide/deployment",
|
||||
"title": "Deployment",
|
||||
"tooltip": "Learn how to deploy your Angular app."
|
||||
},
|
||||
},
|
||||
{
|
||||
"url": "guide/browser-support",
|
||||
"title": "Browser Support",
|
||||
"tooltip": "Browser support and polyfills guide."
|
||||
},
|
||||
|
||||
{
|
||||
{
|
||||
"title": "Dev Tool Integration",
|
||||
"tooltip": "Integrate with your development environment and tools.",
|
||||
"children": [
|
||||
@ -567,13 +567,6 @@
|
||||
"hidden": true
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"url": "guide/setup-systemjs-anatomy",
|
||||
"title": "Anatomy of the Setup",
|
||||
"tooltip": "Inside the local development environment for SystemJS.",
|
||||
"hidden": true
|
||||
}
|
||||
]
|
||||
},
|
||||
@ -583,15 +576,15 @@
|
||||
"title": "Release Information",
|
||||
"tooltip": "Angular release practices, updating, and upgrading.",
|
||||
"children": [
|
||||
{
|
||||
"url": "guide/updating",
|
||||
"title": "Keeping Up-to-Date",
|
||||
"tooltip": "Information about updating Angular applications and libraries to the latest version."
|
||||
},
|
||||
{
|
||||
"url": "guide/releases",
|
||||
"title": "Angular Releases",
|
||||
"tooltip": "Angular versioning, release, support, and deprecation policies and practices."
|
||||
},
|
||||
{
|
||||
"url": "guide/updating",
|
||||
"title": "Keeping Up-to-Date",
|
||||
"tooltip": "Information about updating Angular applications and libraries to the latest version."
|
||||
}
|
||||
]
|
||||
},
|
||||
@ -739,6 +732,7 @@
|
||||
],
|
||||
|
||||
"docVersions": [
|
||||
{ "title": "v6", "url": "https://v6.angular.io" },
|
||||
{ "title": "v5", "url": "https://v5.angular.io" },
|
||||
{ "title": "v4", "url": "https://v4.angular.io" },
|
||||
{ "title": "v2", "url": "https://v2.angular.io" },
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user