Adds a test to the nullish coalescing diagnostic check to serve as
self-documentation on how it works with nullish coalescing on pipes that
are often misconfigured.
This also removes that non null assertion operator, which is incorrect
because there _are_ situations where a symbol cannot be retrieved.
PR Close#43419
Currently the compiler has three different classes to represent a "call to something":
1. `MethodCall` - `foo.bar()`
2. `SafeMethodCall` - `foo?.bar()`.
3. `FunctionCall` - Any calls that don't fit into the first two classes. E.g. `foo.bar()()`.
There are a few problems with this approach:
1. It is inconistent with the TypeScript AST which only has one node: `CallExpression`.
2. It means that we have to maintain more code, because the various parts of the compiler need to know about three node types.
3. It doesn't allow us to easily implement some new JS features like safe calls (e.g. `foo.bar?.())`).
These changes rework the compiler so that it produces only one node: `Call`. The new node behaves similarly to the TypeScript `CallExpression` whose `receiver` can be any expression.
There was a similar situation in the output AST where we had an `InvokeMethodExpression` and `InvokeFunctionExpression`. I've combined both of them into `InvokeFunctionExpression`.
PR Close#42882
The previous replacement logic would not account for the CRLF line
endings when applying replacements because it would replace the whole
template with `template.content.length` which would not account for
CRLF. This update applies individual expression edits at each location
in the template rather than attempting to replace the whole template
contents with a new string that contains the migrations.
fixes#43416
PR Close#43519
The migration was previously touching files that did not have any
expressions to migrate. This change ensures that the migration doesn't
commit any updates on files that do not need them.
This change, however, does not address the underlying issue with the
migration and CRLF (which is fixed in a follow-up change).
Related to #43416
PR Close#43519
Previously, anchor links that were supposed to point to fragments inside
the current page (e.g. `href="#something"`) would end up navigating to
the homepage (`/`). This was due to them being resolved relative to the
base URL, which is set to `/` (via `<base href="/">`). See also
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base#in-page_anchors.
This commit fixes this issue by handling such links specially in
`LocationService#handleAnchorClick()` and prepending the current path to
the URL.
This will also be useful for implementing a "skip to content" link as
described in #42936.
PR Close#43460
When using `ScrollService#scrollToElement()` to scroll to a specific
element, also focus the element if it is focusable (i.e. if it has a
`focus()` method).
This will be useful for implementing a "skip to content" link as
described in #42936.
PR Close#43460
Improve the accessibility of contributor cards (in `/about`) by making
them easier to navigate via keyboard:
- Show the (otherwise hidden) contributor info links on focus.
- Make the "View bio" link focusable via keyboard (to give a clearer
indication that users can click to view the bio - although technically
the click is handled by an ancestor).
- Make the flipped cards focusable via keyboard (so it is possible to
click them to unflip).
PR Close#43460
Improve the accessibility of button groups (such as those seen in
`/about` and `/resources` to choose between the different categories)
by making them easier to navigate via keyboard:
- Make the individual buttons focusable via keyboard.
(Previously, they were not focusable - despite being anchor elements,
because they were lacking an `href` attribute.)
- Give focused buttons a different style.
PR Close#43460
This bit of code is problematic for several reasons:
1. AngularJS-specific handling should not exist in core router code if it can be avoided.
It's not something that should complicated the code long-term
2. It causes URL flickering (the `replace: /` really does happen and can be observed)
3. The original intent was likely for the URL to not actually change;
since the Router only initially supported 'deferred' navigations, this would _usually_ be the case.
4. It actually causes observers of URL changes more problems in handling changes
because the router is already about to process another navigation request.
Notice that when using `'computed'` restoration logic, we do not reset the URL
because it would cause another location change event and conflict with the new navigation.
5. It only resets the browser URL but does nothing to sync the rest of the internal state of the router.
6. It makes guards which call `router.navigate()` behave _slightly_ differently
than guard which return `UrlTree`. Guards which return `UrlTree` do not reset the
URL, but instead just trigger a new navigation.
7. It resets the entire URL rather than just the portion that the
`UrlHandlingStrategy` is configured to handle. Theoretically, the
Router could be configured to only handle a part of the URL so failed
navigations should not reset parts it is not configured to touch.
Note that this is actually a problem in other places in the router as
well where `resetState` is not called before
`resetUrlToCurrentUrlTree`.
As a nice benefit, when `urlUpdateStrategy` is set to `'eager'`, this
makes #17004 possible.
BREAKING CHANGE:
The router will no longer replace the browser URL when a new navigation
cancels an ongoing navigation. This often causes URL flicker and was
only in place to support some AngularJS hybrid applications. Hybrid
applications which rely on the `navigationId` being present on initial
navigations that were handled by the Angular router should instead
subscribe to `NavigationCancel` events and perform the
`location.replaceState` themselves to add `navigationId` to the Router
state.
In addition, tests which assert `urlChanges` on the `SpyLocation` may
need to be adjusted to account for the `replaceState` which is no longer
triggered.
PR Close#43496
The template type-checker has to emit type constructors for the
directives that are used in a template, where a type constructor's
declaration has to mirror the type parameter constraints as they were
originally declared. Therefore, the compiler analyzes whether a type
parameter constraint can be recreated, e.g. by generating imports for
any type references. Some type references cannot be recreated, in which
case the compiler has to fall back to a strategy where the type
constructor is created inline in the original source file (which comes
with a performance penalty).
There used to be an issue for type references to namespaced declarations.
The compiler is unable to emit such references such that an inline
type constructor should be used as fallback, but this did not happen.
This caused the attempt to emit the type reference to fail, as the
namespaced declaration cannot be located by the reference emitters.
This commit fixes the issue by using a stricter check to determine if a
type parameter requires an inline type constructor. The TypeScript
reflection host's `isStaticallyExported` logic was expanded to work for
any declaration instead of just classes, as e.g. type declarations can
also be referenced in a type parameter constraint.
Closes#43383
PR Close#43511
Fixes that the "Loved by millions" graphic doesn't look correctly on Safari.
Note that this fix is somewhat repetitive, but I couldn't find a better one. These are the other things I tried:
* Setting units on the size of `#angular-logo`.
* Setting the size of `#angular-logo` inside the `style` tag.
* Setting the size with inline styles.
Fixes#43498.
PR Close#43502
Improve the aio contributors page responsiveness regarding the browser's
font-size so that the page looks good regarding on font-size settings
(no cropped or cramped content)
PR Close#43355
The getTransition helper function ensures that urlAfterRedirects is assigned for when
the router does not process the previous or current URL. In this case, we would set
the browserUrlTree to be the urlAfterRedirects, which was initialized to be the browserUrlTree.
This is a no-op, so there's no need for the getTransition function at all.
PR Close#43436
These token interfaces will make it easier to reason about tokens in the
parser and in specs.
Previously, it was never clear what items could appear in the `parts`
array of a token given a particular `TokenType`. Now, each token interface
declares a labelled tuple for the parts, which helps to document the token
better.
PR Close#43132