The previous image referred to "Mr IQ". The example application
(and the content of the referring guide) actually uses "Dr IQ".
Closes#34823
PR Close#40022
The previous tutorial content referred to a `Routes` member of
`AppRoutingModule`, which is not correct. Instead there is a
`routes` variable that is passed to the `forRoot()` method when
configuring the `AppRoutingModule`.
Replaces #36583
PR Close#40023
1. In line 25 changed the word "components" to "component's".
2. In line 66 changed the phrase "you never refer to them" to "you should never refer to them".
3. Appended the paragraph containing the above phrase in a `div` with the class `alert is-helpful`.
PR Close#39246
Remove the statements where mentions the component in the `entryComponents`
array inside `NgModule` metadata.
This is not required since Angular version 9.
PR Close#39242
Aside from using the @input() decorator, we can use the @Attrbitute decorator too.
Of course, those two are different and support different causes.
I expected to see a working example on the Attribute Bindings section, but I didn't find one.
This PR depicts the usage of the Attribute decorator between two components
PR Close#38721
after angular version 8 string based lazy loading is not activated by default it is an opt in behaviour in which you have to add the lazy loaded routes in the tsconfig file for compilation. Aded a note too that it will be removed in version 11.
Fixes#35652
PR Close#35956
Since #39853, it is possible to deploy to multiple Firebase sites from a
single branch. In order to deploy to a site, we need to associate an
alias (`aio`) with a site. This is done via the `firebase target:apply`
command. However, when the command is called multiple times, it
associates the alias with many sites, which subsequently fails during
deployment ([example failure][1]), since the `firebase deploy` command
does not know what site to deploy to.
This commit fixes the deployment script by ensuring that any previous
association with the `aio` alias is cleared (via the
`firebase target:clear` command) before associating it with a new site.
[1]: https://circleci.com/gh/angular/angular/871020
PR Close#39948
Previously, test descriptions used `latest` to refer to the most
recent/highest version. This was ambiguous, because `latest` can also
refer to the stable version of a package (e.g. see `@latest` npm tag).
This commit replaces `latest` with `highest` (or `highest for major`) to
reduce ambiguity.
Discussed in:
https://github.com/angular/angular/pull/39853#discussion_r531730317
PR Close#39853
Currently there is an issue with redirecting `rc.angular.io` to
`angular.io` when there is no active RC. If a user has visited
`rc.angular.io` before and has a ServiceWorker registered for that
subdomain, they will never "see" the redirect to `angular.io`.
This commit fixes the problem by doing an additional deployment from the
stable branch to the `rc-angular-io-site` Firebase site when there is no
active RC. This additional deployment will ensure that:
1. Users will be temporarily redirected from `rc.angular.io` to
`angular.io`.
2. Users with a registered ServiceWorker (who don't see the redirect)
will have their ServiceWorker unregistered on the next visit.
3. The content on both sites is identical.
See #39760 for more details on the problem and the solution.
NOTE:
As mentioned in #39760, for this fix to take affect, we need to remove
the redirect from `rc.angular.io` to `angular.io` in the Firebase
console for site `rc-angular-io-site`.
Fixes#39760
PR Close#39853
Previously, a branch would be deployed as `archive` even if it had a
major version that was equal/higher than that of the stable branch (as
long as it was not the RC branch - i.e. not the most recent minor
branch). For example, with `11.0.x` as the stable branch and `12.0.x`
as the RC branch, `11.1.x` would be deployed as archive.
Theoretically, we should never find ourselves in such a situation.
Typically, there will only be at most one minor branch most recent than
the stable one (and that branch will be the RC branch). However, it
is possible under unusual circumstances.
This commit adds additional checks to guard against this problem. It
also refactors the code in preparation of fixing an issue with
`rc.angular.io` redirects in the presence of a ServiceWorker, which will
require identifying whether there is an active RC version or not.
See #39760 for more details.
PR Close#39853
Previously, the latest commit for branch may be computed multiple times
in the `deploy-to-firebase.js` tests.
This commit avoids the unnecessary re-computations by computing the
latest commits for the necessary branches at the beginning and using the
computed values throughout the tests.
PR Close#39853
Previously, the `deploy-to-firebase.js` script would only perform one
deployment operation on each run.
This commit adds support for performing multiple deployment operations.
NOTE:
In a subsequent commit, this will be leveraged fix an issue with
`rc.angular.io` redirects in the presence of a ServiceWorker by
deploying the same artifacts to multiple Firebase projects/sites.
See #39760 for more details.
PR Close#39853
Previously, the `deploy()` function in `deploy-to-firebase.js` would
also perform other operations (beyond deploying), such as building the
app, checking the generated payload size, testing the PWA score of the
deployed app.
This commit decouples these operations, so that deploying can be
performed independently.
NOTE:
In a subsequent commit, this will be leveraged fix an issue with
`rc.angular.io` redirects in the presence of a ServiceWorker by
deploying the same artifacts to multiple Firebase projects/sites.
See #39760 for more details.
PR Close#39853
Since we turned off the Selenium Promise Manager in #39600, the AIO e2e
tests have started flaking on CI. After trying out several things, the
only change that seems to eliminate the flakiness is turning the
Selenium Promise Manager back on (see #39873 for more details).
This commit turns the Selenium Project Manager on to get rid of the
flakiness.
Fixes#39872
PR Close#39905
This commit edits the copy on the interpolation page.
Tightens language, clarifies headers, and streamlines text.
There are no content or code changes.
PR Close#38687
DEPRECATION:
Mark the {[key: string]: any} type for the options property of the FormBuilder.group method as deprecated.
Using AbstractControlOptions gives the same functionality and is type-safe.
PR Close#39769
This adds angulararchitects.io to the tranings section in the
resources.json file for angular.io. It also adds a description
for angulararchitects.io.
PR Close#37139
The article previously referred was out of date. Most of the article content
was already duplicated here, or described how to generate multiple bundles. But
creating multiple bundles manually is now obsolete and the parameter `--localize`
should be preferred instead, because it is much faster.
This commit integrate the only interesting part left, relating to webserver configuration.
Co-authored-by: David Shevitz <dshevitz@google.com>
PR Close#36553
`en-US` makes it link to the English (US) version.
This patch removes this and let's MDN auto-redirect to the user's preferred/selected language/website locale.
PR Close#39842
This commit disables the Selenium Promise Manager when running e2e tests
for docs examples in order to more closely align them with new apps
created with CLI v11. This change requires that any async operations in
tests are handled explicitly (e.g. using `async/await` or
`Promise#then()`).
PR Close#39818
This commit removes some code that is no longer necessary for the
`upgrade-module` docs example e2e tests to run. It used to be necessary
in earlier version of Protractor but not any more.
PR Close#39818
Previously, the tests made no meaningful assertions. It seems that the
intention was to ensure that some elements were present on the page, but
all the assertions did was verify that the corresponding
`ElementFinder`s were defined. The `ElementFinder`s would always be
defined, even if there were no corresponding elements on the page. In
fact, some of the `ElementFinder` selectors were incorrect, so they did
not match any actual elements.
This commit fixes the tests by fixing the `ElementFinder` selectors and
asserting that the elements are actually present on the page.
PR Close#39818
Previously, the test made no meaningful assertion. It seems that the
intention was to ensure that some elements were present on the page, but
all the assertions did was verify that the corresponding
`ElementFinder`s were defined. The `ElementFinder`s would always be
defined, even if there were no corresponding elements on the page. In
fact, some of the `ElementFinder` selectors were incorrect, so they did
not match any actual elements.
This commit fixes the tests by fixing the `ElementFinder` selectors and
asserting that the elements are actually present on the page.
PR Close#39818
Addresses documentation gaps as reported in #35078. The documentation only
contained a single statement on foreign function/value compatibility
without going into detail on what this means. This commit adds several
examples to the Ivy compatibility guide and explains why Ivy behaves differently
compared to VE.
PR Close#36092
Archives most of the content in the template expression operators doc.
The pipes precedence section that was originally in
template expression operators moves into the pipes doc
with some editing and an addition of a ternary example.
PR Close#39170
Edits copy and removes tokens and treeshaking
sections to reduce content duplication and keep
info focused. Moves provideParent() from di-navtree
to di providers.
PR Close#39403
While JavaScript does support implicit returns, it seems TypeScript will not infer the function return type from
the implicit return of the last statement (at least not in TS 3.4.3). So, when the `return` is missing from the
`get` function the implicit type of the function is `void`. So for the `get` function to be usable it needs to an
explicit return.
PR Close#31434
Occasionally, the SW would end up in a broken state where some of the
eagerly cached resources of an older version were available in the local
cache, but others (such as lazy-loaded bundles) were not. This would
leave the app in a broken state and a blank screen would be displayed.
See #28114 for a more detailed discussion.
This commit takes advantage of the newly introduced (in v11)
[SwUpdate#unrecoverable][1] API to detect these bad states and recover
by doing a full page reload whenever an [UnrecoverableStateEvent][2] is
emitted.
Partially addresses #28114.
NOTE:
Currently, `SwUpdate.unrecoverable` only works if the app has already
bootstrapped; i.e. if only lazy-loaded bundles have been purged from the
cache.
That should be fine in practice, since the cache entries are removed in
least-recently-used order. Thus the eagerly loaded bundles will be the
last to be removed from the cache (which rarely happens in practice).
[1]: https://v11.angular.io/api/service-worker/SwUpdate#unrecoverable
[2]: https://v11.angular.io/api/service-worker/UnrecoverableStateEvent
PR Close#39651
Previously, the `LocationService` depended on the `SwUpdatesService`.
This felt backwards, since `LocationService` is a more low-level and
basic service and should not be depending on a service for a
higher-level, specific feature (ServiceWorkers).
This commit inverses the relation, making `SwUpdatesService` depend on
`LocationService` instead.
PR Close#39651
Since we have a `MockLogger` class in `src/testing/`, there is no need
to create a new `MockLogger` class for the `SwUpdatesService` unit
tests.
This commit switches to using the `MockLogger` class from
`src/testing/`.
PR Close#39651
Removes duplicate info, moves document into conceptual
reference section, but doesn't edit remaining content.
Groups two dependency injection documents together in
one expandable nav section.
PR Close#39544
This commit fixes a confusing description of the `strictTemplates` flag.
> When `true`, enables strict template type checking in Angular version 9.
This seems to imply that the flag is only available in one version.
Strict template type checking is available in version 9 **and above**.
PR Close#39745
This commit downgrades `karma` to version 5.1.1, because of a regression
in version 5.2.0: karma-runner/karma#3560
It has been fixed with karma-runner/karma@05dc288016 on
master, but the fix is not included in the latest release (v5.2.3).
PR Close#39600
This commit updates `@angular/*` and `@angular/cli` (and related
packages) to version 11.0.0-rc.2. Apart from the automatic migrations,
this commit also tries to align `aio/` with new apps generated by the
latest CLI. (See [here][1] for a diff between a v10.1.3 and a
v11.0.0-rc.2 CLI app.)
[1]: https://github.com/cexbrayat/angular-cli-diff/compare/10.1.3...11.0.0-rc.2
PR Close#39600
Previously we hand coded the list of previous major versions
that are displayed in the left navigation.
Now these are generated from the tags in GitHub.
Closes#39688
PR Close#39689
ngNonBindable documentation was not present, on docs site added documentation for ngNonBindable. With this template primitive, Angular won't
evaluate expressions in elements.
Fixes#28577Fixes#19497
PR Close#36560
Since WebStorm 2019.1, all of Angular Compiler validations has been implemented
as inspections, which has some additional benefits of being able to provide some
basic quick fixes like adding missing selector property, or something as neat as
auto-module import.
See https://intellij-support.jetbrains.com/hc/en-us/community/posts/360009914880
Signed-off-by: Adrien Crivelli <adrien.crivelli@gmail.com>
PR Close#39637
In #39470, the `deploy-to-firebase.sh` script (used to deploy AIO to
Firebase when building an upstream branch), was replaced by an
equivalent JS script. In this new `deploy-to-firebase.js` script, we
were overly aggressive with suppressing command output, which made it
hard to investigate failures ([example failing CI job][1]).
This commit updates the `deploy-to-firebase.js` script to capture
command output as usual in the CI job logs. This makes the output
similar to the one generated by the old [deploy-to-firebase.sh][2]
script ([example CI logs][3]).
One concern with capturing command output is having the value of a
secret environment variables leaked in the logs. This is not the case
here, since:
1. The secret env vars are not printed from the commands that use them.
2. CircleCI will [mask the values of secret env vars][4] in the output.
As an extra precaution (although not strictly necessary), we run `yarn`
with the `--silent` option, which avoid echoing the executed yarn
commands.
[1]: https://circleci.com/gh/angular/angular/849310
[2]: https://github.com/angular/angular/blob/3b0b7d22109c79b4dceb/aio/scripts/deploy-to-firebase.sh
[3]: https://circleci.com/gh/angular/angular/848109
[4]: https://circleci.com/docs/2.0/env-vars/#secrets-masking
PR Close#39596
The commit updates the AIO deployment script to also print the commit
SHA. This makes it easier to check whether a version has been
successfully deployed, by comparing the commit SHA from the CI job with
the SHA in the version string in the footer of the AIO app.
PR Close#39596
Previously, the documentation for each major Angular version was hosted
on each own Firebase project. This required creating a new project for
each major release and increased the administrative/maintenance cost.
Now that Firebase supports hosting [multiple websites][1] as part of the
same project, we are switching to deploying all major versions to sites
created on `angular-io` project.
This is part of the work needed to prepare angular.io for our
[new versioning/branching process][2] (also tracked in #39366).
[1]: https://firebase.google.com/docs/hosting/multisites
[2]: https://docs.google.com/document/d/197kVillDwx-RZtSVOBtPb4BBIAw0E9RT3q3v6DZkykU
PR Close#39470
This commit breaks up the code in `deploy-to-firebase.js` script, that
we use for deploying angular.io to production, to smaller functions
(instead of a monolithic block). This makes the script easier to
maintain and also makes testing individual operations easier.
The commit also updates the `deploy-to-firebase.spec.js` spec file to
take advantage of the standalone functions to speed up testing by
calling the corresponding function instead of having to spawn a new
process and run the `deploy-to-firebase.js` script with the `--dry-run`
flag.
NOTE: Before updating the tests, I verified that the updated
`deploy-to-firebase.js` script passed the old tests.
PR Close#39470
Pete Bacon Darwin
m-ahmadi
George Kalpakas
Panagiotis Kyriazopoulos
ankitkaushik24
profanis
Ajit Singh
Alexey Elin
Keen Yee Liau
Alvaro
Jeremy Elbourn
Wes Grimes
Kapunahele Wong
Jaime Oliveira
bluemyria
christos-P
Ryan Russell
Manfred Steyer
Adrien Crivelli
Charles Lyding
rugk
JoostK
Srashti Jain
Michael Gerullis
Marcono1234
andyg3
Jacob Foshee
Will Mendes
WilliamKoza
David Shevitz
Licanueto
Santosh Yadav
spixy
Antonio Cardenas
Yvonne Allen
Alan Agius
JiaLiPassion
SephirotJustin
Leif Segen
mgechev
George Vrettos
Aristeidis Bampakos
GeopJr
