move the check for non-animatable properties from the animation building
phase to the application of the animation's transition instead, in such
a way we can check it against the keyframes of the transition's timeline
in order to only provide warnings for properties which are being
animated, thus not providing any warning for non-animatable properties
being applied to elements via the style function
this change has the benfit just mentioned above but it comes with two
drawbacks:
- the warning handling is not done in the building time so it is a bit
inconsistent with other type of validations (such as the unsupported css
properties one for example)
- before the warning was being applied only when the animation's data
was being parsed, so it happed only once but now since it is applied
when the animation is actually being prepared to be played, it happens
each time the animation runs
resolves#46602
PR Close#46666
After a bugfix in #46096, the compiler is now better capable of detecting pipes
which require an inline type constructor. However, there is an issue in how all
pipes are considered when verifying the inline type-ctor requirement: it should
only check actually used pipes.
Fixes#46747
PR Close#46807
Most of the increase comes from code being moved from `index.html`
to the main bundle. A small increase comes from the additional `gtag.js`
loading logic, but other than that the size is effectively increased
due to the untracked code from `index.html` being moved into the
`main.js` bundle.
PR Close#46801
This is acceptable because `gtag.js` is also only loaded as part of the
service, similary `ga` is only registered in the service (so the
reporting was a noop if errors are thrown before -- no change here)
We can benefit from downleveling etc. and do not need to be careful
with the inline script in the `index.html`
PR Close#46801
We currently use Universal Analytics. This is deprecated in favor of
Google Analytics 4 and UA will stop processing hits in October 2023.
This change intends to prepare us for this migration, and to already
pre-populate our GA4 property (there is no way to migrate existing data
/properties into a GA4 property -- a new one needs to be created).
This will help us minimize the data gap so that we can:
* Continue to look at the UA property with the full time span until
October 2023
* Can start using the GA4 property long-term in the future, starting
with data even before Universal Analytics stops processing new data.
We need to keep the existing `analytics.js` setup. Initially we have
considered using `gtag.js` for both the UA and GA4 properties, as it
supports that, but that doesn't work with our strict trusted types
enforcement because it results in multiple `gtag.js` scripts (specific
versions for UA or GA4) that recreate the same trusted type policies.
This causes runtime errors and breaks the setup.
Instead, with continued use of `analytics.js` we have the benefit of
a good separation of trusted types + events and configuration. There is
some problematic with translation of Universal Analytics Events to GA4,
or the other way around (even though we don't use custom events
currenlty)
We also do not need to send page views for our GA4 property because GA4
with gtag supports this automatically (respecting the history state --
using the `Enhanced measurement events` setting in the UI).
For our UA legacy instance we continue to dispatch events manually. This
logic can be removed in the future.
More details can be found here:
https://docs.google.com/document/d/1aK8u4ZlXbqQ2wMqmgSX7Ces8iLgamC13oCoG6VeBruA/edit?usp=sharing&resourcekey=0-EVe-Rhnme3bj_pkz2RcOmw.
PR Close#46801
The JS size-tracking logic has been moved into the dev-infra repository
and the rule has been updated to work better with Bazel labels. The
Starlark target is updated accordingly in this commit.
PR Close#46802
This script was used back when dev-infra code was part of
the Angular framework repository. The script is now unused
and can be deleted.
PR Close#46798
The jasmine seed generator is only used in a single karma configuration
file. Used by the legacy build and the Saucelabs/ZoneJS Karma jobs.
We should move the separate script code directly into the config to make
it clear that the seed generation is not used elsewhere, and to simplify
the Starlark code.
PR Close#46798
Remove or reframe references to the obsolete HeroListComponent component that was taken from an old version of the Tour of Heroes tutorial.
Incorporates review feedback.
Fix#44662
PR Close#46647
The integration test rule now always executes tests in a directory
outside of the execroot. This ensures a more hermetic test environment
on platforms without a sandbox, or when tests are run with `tags:
local`.
As part of this change, an issue with Yarn 1.x. and `nodejs_binary`
unveiled. Yarn 1.x. is resolved properly using the tool mapping but
when Yarn inside Yarn is invoked (e.g. using `package.json` scripts),
then the second nested Yarn invocation fails due to an unknown path.
This happens because Yarn in the original invocation creates another
directory in the `/tmp` directory and modifies the `PATH` so that
the same `yarn` can be invoked again. This makes sense conceptually
but breaks in our case because the Yarn Bash script put into the `/tmp`
directory tries to resolve our vendored Yarn script relatively (which
is the wrong spot here). It worked previously in the execroot because
`nodejs_binary` invoked Yarn through `<external>/../node.sh
<absolute-path-to-yarn-cjs-script>`, but outside the execroot it invoked
Yarn using a relative path (which then ended up being preserved in the
Yarn temporary directory).
We can fix this by updating the Bazel NodeJS repository which seems to
have coincidentally have a fix for the path resolution. See:
https://github.com/bazelbuild/rules_nodejs/pull/3493#event-6870301735.
PR Close#46778
The existing logic does something similar but in a more roundabout way.
It reads _the whole array_. If it encounters a pending value, it ignores
the remaining ones. If it hasn't encountered a pending value by the time
it hits false/UrlTree, it returns that result.
The new logic is the same, but reverses what we're looking for. Instead
of processing the whole array, we stop when we encounter an initial
value. When we encounter one that isn't `true`, that gets returned. If
we get to the end and everything was `true`, return `true`.
PR Close#46745
For the branch rename migration we temporarily had to work
from a forked-off branch. Now that all the migration and cleanup
Is complete, we can switch to the actual new main branch.
This is the last remaining cleanup in the organization as it seems.
PR Close#46743
Add a section regarding component view encapsulations in the complex animation
sequences guide to let developers know how animations work in regard to
view encapsulations.
This section is used to both add information to the guide but also to
take a stand on how the animations should behave in regard to the
shadow dom view encapsulation.
This relates to PR #46488 which by trying to make sure the query
function works with shadow dom elements proved that having the
animations implementation work with shadow dom would increase the
complexity of the code and would have a negative impact on performance,
such facts alongide the small adoption of shadow dom by users influenced
the decision to keep the current functionalities and simply discourage
the use of animations and shadow dom components.
PR Close#46738
This reverts commit b417370383.
The change applied is no longer appropriate since the use of animations
and shadow dom components is discouraged (as of #46738)
PR Close#46739
Jessica Janiuk