After the previous update to yarn.lock a problem surfaced
with the `mkdir-promise` package. The latest version of
dgeni-packages (0.28.3) fixes this problem.
PR Close#35379
This file had not been updated for some time and lots of
the dependencies have new versions.
This is actually necessary because (at least on OS/X) there
is a problem with `chokidar` and `fsevent` that is solved by
bumping the versions here.
PR Close#35379
Previously, the `deployment` section, was using the `firebase`
CLI to deploy the angular project into firebase. With the better
integration through the `fire` schematics, it is now easier to
deploy angular applications into firebase. This commit takes
care of this, by outlined the required steps for deployment.
Closes#35274
PR Close#35355
The message service was added in a section create message service but was impoted much before it removed those imports because they can be confusing
Fixes#35259
PR Close#35354
Previously, a section in the FAQ was not clear when discussing a
simple unit test. We also want to move away from question-based
sections. This commit clarified the confusing section and
changed all question-based sections.
Closes#35056
PR Close#35316
Removing for now, since the info is stale, and we need to determine how to adjust the schedule due to the unexpected and significant version 9 delay.
PR Close#34474
On home page, image size set to 400px, which make the page not render
properly on devices below the size of 400px width.
Also, when search results were scrolled, they interfered with the top
nav items. Added border at the top of the search results container so
that the results are not visible under the nav items during scrolling.
PR Close#35098
Footer links did not have enough space between them, so lighthouse was
reporting that tap targets are not appropriately sized. Added the
required 8px space between links.
Also updated the margin of group headers accordingly.
Fixes#34901
PR Close#35098
Because the animation completes in 2000ms, and browser.wait checks
every 100ms, there can be a race condition of if the final state has
actually been reached to read the color. By moving to 2101ms, we ensure
that we cheack after the 2000ms of the animation has completed.
PR Close#35089
https://angular.io/resources needs to be sturctured to be able to navigate to all resources with improved user experience. A lone scroll bar in this page will not help the reader a great deal in exploring the resources
Fixes#33526
PR Close#34756
The golang section was recently added to the deployment guide
but has been reported as returning errors, where it had previously
worked. After discussion and testing with
Stephen Fluin, we are removing this section because of
inconsistency in functionality.
PR Close#34099
This change changes the priority order of static styling.
Current priority:
```
(least priority)
- Static
- Component
- Directives
- Template
- Dynamic Binding
- Component
- Map/Interpolation
- Property
- Directives
- Map/Interpolation
- Property
- Template
- Map/Interpolation
- Property
(highest priority)
```
The issue with the above priority is this use case:
```
<div style="color: red;" directive-which-sets-color-blue>
```
In the above case the directive will win and the resulting color will be `blue`. However a small change of adding interpolation to the example like so. (Style interpolation is coming in https://github.com/angular/angular/pull/34202)
```
<div style="color: red; width: {{exp}}px" directive-which-sets-color-blue>
```
Changes the priority from static binding to interpolated binding which means now the resulting color is `red`. It is very surprising that adding an unrelated interpolation and style can change the `color` which was not changed. To fix that we need to make sure that the static values are associated with priority of the source (directive or template) where they were declared. The new resulting priority is:
```
(least priority)
- Component
- Static
- Map/Interpolation
- Property
- Directives
- Static
- Map/Interpolation
- Property
- Template
- Static
- Map/Interpolation
- Property
(highest priority)
```
PR Close#34938
In #35004, we started ignoring yarn's engines check for `yarn install`
in AIO's `test-production.sh` script to fix a failure in the
`aio_monitoring_stable` CI job. (See #35004 for details.)
It turns out that the version of yarn used on the stable branch (1.17.3)
`--ignore-engines` is needed on all yarn commands (including `yarn
run`). Thus, #35004 is not enough to fix the failures.
New example failure: https://circleci.com/gh/angular/angular/604341
This commit turns of the engines check for the whole
`aio_monitoring_stable` CI job to fix the failure and make the job more
robust.
PR Close#35033
There are different `DebugNode`/`DebugElement` implementations (and
associated helper functions) for ViewEngine and Ivy. Additionally, these
classes/functions, which are defined inside the `core` package, are
imported by the `platform-browser` package.
Previously, this code was not tree-shaken as expected in Ivy. #30130
partially addressed the issue, but only for the case where `core` and
`platform-browser` end up in the same closure after webpack's scope
hoisting. In cases where this is not the case, our webpack/terser based
tooling is not capable of tree-shaking it.
This commit fixes the problem, by ensuring that the code retained in Ivy
mode (due to the cross-package import) does not unnecessarily reference
`DebugNode`/`DebugElement`, allowing the code to be tree-shaken away.
This results in a 7.6KB reduction in the size of the main angular.io
bundle.
Jira issue: [FW-1802](https://angular-team.atlassian.net/browse/FW-1802)
PR Close#35003
In #34955, we switched to Node.js v12 on master and 9.0.x. This causes
the `aio_monitoring_job` CI job (which checks out files from the stable
branch; currently 8.2.x) to start failing yarn's engines check (since
the 8.2.x branch expects Node.js version <11).
Example failure: https://circleci.com/gh/angular/angular/602499
Since the job is expected to run with files from both the stable and the
master branches (and since the version of Node.js is not important
here), this commit uses the `--ignore-engines` option to prevent
failures due to Node.js version mismatch.
NOTE:
Typically, the stable and master branch are on the same Node.js version,
because related PRs land on both master and the patch branch. One
exception is during RC periods, when the stable branch is different than
the patch branch. These periods are usually short, but in the case of
9.0.0 the period has lasted several months causing the CI environments
between master and the stable branch to get significantly out-of-sync.
PR Close#35004
earlier p sigly was used to define a paragraph element which was not clear what we want to refer changed it to paragrapg element for better understanding
Fixes#34922
PR Close#34927
This update increases the main bundle by ~0.6KB
payload size snapshot:
456581 Jan 24 22:07 dist/main-es2015.38c39f92eab2fcc8c835.js
541321 Jan 24 22:06 dist/main-es5.38c39f92eab2fcc8c835.js
52487 Jan 24 22:05 dist/polyfills-es2015.b374ef3555a700a97add.js
146193 Jan 24 22:05 dist/polyfills-es5.c7dc569e6c646e42fade.js
2987 Jan 24 22:05 dist/runtime-es2015.29be4028399ae41ba25e.js
2981 Jan 24 22:05 dist/runtime-es5.29be4028399ae41ba25e.js
PR Close#34966
Previously we would write to class/style as strings `element.className` and `element.style.cssText`. Turns out that approach is good for initial render but not good for updates. Updates using this approach are problematic because we have to check to see if there was an out of bound write to style and than perform reconciliation. This also requires the browser to bring up CSS parser which is expensive.
Another problem with old approach is that we had to queue the DOM writes and flush them twice. Once on element advance instruction and once in `hostBindings`. The double flushing is expensive but it also means that a directive can observe that styles are not yet written (they are written after directive executes.)
The new approach uses `element.classList.add/remove` and `element.style.setProperty/removeProperty` API for updates only (it continues to use `element.className` and `element.style.cssText` for initial render as it is cheaper.) The other change is that the styling changes are applied immediately (no queueing). This means that it is the instruction which computes priority. In some circumstances it may result in intermediate writes which are than overwritten with new value. (This should be rare)
Overall this change deletes most of the previous code and replaces it with new simplified implement. The simplification results in code savings.
PR Close#34804
NOTE: This change must be reverted with previous deletes so that it code remains in build-able state.
This change deletes old styling code and replaces it with a simplified styling algorithm.
The mental model for the new algorithm is:
- Create a linked list of styling bindings in the order of priority. All styling bindings ere executed in compiled order and than a linked list of bindings is created in priority order.
- Flush the style bindings at the end of `advance()` instruction. This implies that there are two flush events. One at the end of template `advance` instruction in the template. Second one at the end of `hostBindings` `advance` instruction when processing host bindings (if any).
- Each binding instructions effectively updates the string to represent the string at that location. Because most of the bindings are additive, this is a cheap strategy in most cases. In rare cases the strategy requires removing tokens from the styling up to this point. (We expect that to be rare case)S Because, the bindings are presorted in the order of priority, it is safe to resume the processing of the concatenated string from the last change binding.
PR Close#34616
This change moves information from instructions to declarative position:
- `ɵɵallocHostVars(vars)` => `DirectiveDef.hostVars`
- `ɵɵelementHostAttrs(attrs)` => `DirectiveDef.hostAttrs`
When merging directives it is necessary to know about `hostVars` and `hostAttrs`. Before this change the information was stored in the `hostBindings` function. This was problematic, because in order to get to the information the `hostBindings` would have to be executed. In order for `hostBindings` to be executed the directives would have to be instantiated. This means that the directive instantiation would happen before we had knowledge about the `hostAttrs` and as a result the directive could observe in the constructor that not all of the `hostAttrs` have been applied. This further complicates the runtime as we have to apply `hostAttrs` in parts over many invocations.
`ɵɵallocHostVars` was unnecessarily complicated because it would have to update the `LView` (and Blueprint) while existing directives are already executing. By moving it out of `hostBindings` function we can access it statically and we can create correct `LView` (and Blueprint) in a single pass.
This change only changes how the instructions are generated, but does not change the runtime much. (We cheat by emulating the old behavior by calling `ɵɵallocHostVars` and `ɵɵelementHostAttrs`) Subsequent change will refactor the runtime to take advantage of the static information.
PR Close#34683
Previously, the template type-checker would always construct a generic
template context type with correct bounds, even when strictTemplates was
disabled. This meant that type-checking of expressions involving that type
was stricter than View Engine.
This commit introduces a 'strictContextGenerics' flag which behaves
similarly to other 'strictTemplates' flags, and switches the inference of
generic type parameters on the component context based on the value of this
flag.
PR Close#34649
This commit increases payload size limits for angular.io application that triggered an error after merging another commit (00f13cc074). The goal of this commit is to bring master back to a "green" state and separate investigation is required to identify the root cause for size increase.
PR Close#34913
The StackBlitz API (which we use to generate StackBlitz projects on the
fly, when a user clicks on a live example link in the docs) allows
specifying the file to open in the editor by passing a query param. If
no file is specified, StackBlitz opens a default one. In the past, it
used to be `main.ts` and nowadays it seems to be `app.component.ts`.
StackBlitz builder, the tool that we use to generate the StackBlitz
projects, allows specifying the primary file by setting the `file`
property in the corresponding `stackblitz.json`.
Previously, if the `file` property was not set, StackBlitz builder would
not specify a file, thus falling back on StackBlitz's default behavior.
This was not great, because the default behavior may change unexpectedly
is the future to something that is less useful for our users.
This commit change StackBlitz builder to always specify a primary file.
If no file is specified in `stackblitz.json`, the builder will look
for the first file that exists in the example from a list of predefined
files.
Partially addresses #22357.
PR Close#34553
The StackBlitz API (which we use to generate StackBlitz projects on the
fly, when a user clicks on a live example link in the docs) allows
specifying the file to open in the editor by passing a query param. If
no file is specified, StackBlitz opens a default one.
This commit specifies relevant landing files for some of the examples to
make it easier to engage with the examples more quickly, and to see what
the example is attempting to demonstrate.
Fixes#22357.
PR Close#34553
First we used a messages array to display messages toh-4 but it dsplayed only one message added additional messages on click of a hero
Fixes#28739
PR Close#34496
When running the e2e tests on CI, it is desirable that the build
progress is not logged, because that clutters the logs and makes it
difficult to get to the useful info in case of failures.
The previous config to achieve that doesn't work any more.
This commit update the `ci` configuration for e2e tests to suppress
build progress logging.
PR Close#34840
Previously, the examples in the `comparing-observables` guide were hard-coded.
This made it impossible to test them and verify they are correct.
This commit fixes this by converting them into a proper mini-app. In a
subsequent commit, tests will be added to verify that the source code
works as expected (and guard against regressions).
Fixes#31024
PR Close#34327
Previously, the examples in the `cli-builder` guide were hard-coded.
This made it impossible to test them and verify they are correct.
This commit fixes this by converting them into a proper mini-app. In a
subsequent commit, tests will be added to verify that the source code
works as expected (and guard against regressions).
Fixes#34314
PR Close#34362
earlier in the docs it was told that adding typescript's type checking make json response typed so changed docs to say that it adds all typescipt capabilities during compile time
Fixes#34746
PR Close#34845
With TS 3.7, these examples were running into the error below (e.g. on https://circleci.com/gh/angular/angular/574906#tests/containers/0):
```
============== AIO example output for: /home/circleci/ng/aio/content/examples/observables/
running: yarn tsc --project ./
$ /home/circleci/ng/aio/content/examples/observables/node_modules/.bin/tsc --project ./
../../../tools/examples/shared/node_modules/protractor/built/index.d.ts(5,10): error TS2440: Import declaration conflicts with local declaration of 'PluginConfig'.
../../../tools/examples/shared/node_modules/protractor/built/index.d.ts(5,24): error TS2440: Import declaration conflicts with local declaration of 'ProtractorPlugin'.
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
completed: yarn tsc --project ./
```
This happened because of https://github.com/angular/protractor/issues/5348.
It's unclear why this typings problem does not affect `ng e2e` runs, and only affects `tsc` runs.
For now it seems sensible to alter the tests to compile only the app and not the e2e, since the intent of 2cc954d5a5 was never to verify the correctness of the e2e in the first place.
We still need a release of protractor that supports TS 3.7 though, but at least it doesn't seem to block our update proper.
PR Close#33717
This simplifies the Firebase redirect config, removing a redundant
pattern (`/api/http`) which is covered by the previous pattern and
dropping an unused named captured segment (`:rest*`).
This change does not affect the redirection behavior for the deployed
apps, but allows the Firebase hosting emulator to work correctly.
(See [here][1] for more info.)
NOTE: Although we are not currently using the Firebase emulator for
development/testing, we might want to use it in the future.
[1]: https://github.com/firebase/superstatic/issues/231#issuecomment-573034515
PR Close#34726
Currently, the angular.io projects do not use Firebase's Realtime
Database and therefore we only need to configure and deploy changes for
`hosting`.
This commit removes the unused Realtime Database related configs and
files.
PR Close#34696
Pete Bacon Darwin
Sonu Kapoor
Igor Minar
ajitsinghkaler
Santosh Yadav
Greg Magolan
Judy Bogart
Sachin Grover
Oleg Teterin
David Shevitz
Schneider
Misko Hevery
George Kalpakas
JiaLiPassion
Stephen Fluin
Kara Erickson
Filipe Silva
Sasha Rudan
Joey Perrott
Kapunahele Wong
陈旭
crisbeto
frosty
Alan Agius
Turtuvshin Byambaa
philonor
Alex Rickabaugh
Andrew Kushnir
Aravind
Kristina Gocheva
GavinMK
Adam
mikef