In the past, the closure file has been generated so that all individual
locale files were imported individually. This resulted in a huge
slow-down in g3 due to the large amount of imports.
With 90bd984ff7 this changed so that we
inline the locale data for the g3 closure locale file. Also the file
only contained data for locales being supported by Closure. For this a
list of locales has been extracted from Closure Compiler, as well as a
list of locale aliases.
This logic is prone to CLDR version updates, and also broke as part of
the Gulp -> Bazel migration where this logic has been slightly modified
but caused issues in G3. e.g. a locale `zh-Hant` was requested in g3,
but the locale data had the name of the alias locale that provided the
data at index zero (which represents the locale name). Note that the
locale names at index zero always could differentiate from the requested
`goog.LOCALE` due to the aliasing logic. This just didn't come up before.
We simplify this logic by generating a `goog.LOCALE` case for all
locales CLDR provides data for. We don't need to bother about aliasing
because with the refactorings to the CLDR generation tool, all locales
are built (which also captures the aliases), and we can generate the locale
file on the fly (which has not been done before).
PR Close#42230
The CLDR extraction tool has been reworked to run as part of Bazel.
This adds a initial readme explaining what the tool generates. It's
far from a detailed description but it can serve as foundation for more
detailed explanations.
PR Close#42230
Introduces a few Starlark macros for running the new Bazel
CLDR generation tool. Wires up the new tool so that locales
are generated properly. Also updates the existing
`closure-locale` file to match the new output generated by the Bazel tool.
This commit also re-adds a few locale files that aren't
generated by CLDR 37, but have been accidentally left in
the repository as the Gulp script never removed old locales
from previous CLDR versions. This problem is solved with the
Bazel generation of locale files, but for now we re-add these
old CLDR 33 locale files to not break developers relying on these
(even though the locale data indicies are incorrect; but there might
be users accessing the data directly)
PR Close#42230
Converts the CLDR locale extraction script to a Bazel tool.
This allows us to generate locale files within Bazel, so that
locales don't need to live as sources within the repo. Also
it allows us to get rid of the legacy Gulp tooling.
The migration of the Gulp script to a Bazel tool involved the
following things:
1. Basic conversion of the `extract.js` script to TypeScript.
This mostly was about adding explicit types. e.g. adding `locale:
string` or `localeData: CldrStatic`.
2. Split-up into separate files. Instead of keeping the large
`extract.js` file, the tool has been split into separate files.
The logic remains the same, just that code is more readable and
maintainable.
3. Introduction of a new `index.ts` file that is the entry-point
for the Bazel tool. Previously the Gulp tool just generated
all locale files, the default locale and base currency files
at once. The new entry-point accepts a mode to be passed as
first process argument. based on that argument, either locales
are generated into a specified directory, or the default locale,
base currencies or closure file is generated.
This allows us to generate files with a Bazel genrule where
we simply run the tool and specify the outputs. Note: It's
necessary to have multiple modes because files live in separate
locations. e.g. the default locale in `@angular/core`, but the
rest in `@angular/common`.
4. Removal of the `cldr-data-downloader` and custom CLDR resolution
logic. Within Bazel we cannot run a downloader using network.
We switch this to something more Bazel idiomatic with better
caching. For this a new repository rule is introduced that
downloads the CLDR JSON repository and extracts it. Within
that rule we determine the supported locales so that they
can be used to pre-declare outputs (for the locales) within
Bazel analysis phase. This allows us to add the generated locale
files to a `ts_library` (which we want to have for better testing,
and consistent JS transpilation).
Note that the removal of `cldr-data-downloader` also requires us to
add logic for detecting locales without data. The CLDR data
downloader overwrote the `availableLocales.json` file with a file
that only lists locales that CLDR provides data for. We use the
official `availableLocales` file CLDR provides, but filter out
locales for which no data is available. This is needed until we
update to CLDR 39 where data is available for all such locales
listed in `availableLocales.json`.
PR Close#42230
This is a pre-refactor commit allowing us to move
the CLDR locale generation to Bazel where files would
no longer be checked-in, except for the `closure-locale`
file that is synced into Google3.
PR Close#42230
For quite a while it is an unspoken convention to add a trailing
new-line files within the Angular repository. This was never enforced
automatically, but has been frequently raised in pull requests through
manual review. This commit sets up a lint rule so that this is
"officially" enforced and doesn't require manual review.
PR Close#42478
Switches the repository to TypeScript 4.3 and the latest
version of tslib. This involves updating the peer dependency
ranges on `typescript` for the compiler CLI and for the Bazel
package. Tests for new TypeScript features have been added to
ensure compatibility with Angular's ngtsc compiler.
PR Close#42022
We have some internal proxies for all of the Jasmine functions, as well as some other helpers. This code hasn't been touched in more than 5 years, it can lead to confusion and it isn't really necessary since the same can be achieved using Jasmine.
These changes remove most of the code and clean up our existing unit tests.
PR Close#42177
`Location.go` does not trigger the browser's `popstate` event because
the Angular Router uses `pushState` and `replaceState`. This can be
confusing when calling `Location.go` and using `Location.subscribe`.
This commit clarifies the behavior of `Location.subscribe` and points
developers to the `onUrlChanges` subscription instead.
Fixes#12691
PR Close#42272
Update the supported range of node versions for to be less restrictive, no longer causing
yarn or npm to fail engine's checks for future versions of node.
While this change will no longer cause yarn or npm to fail these engine's check, this does
not reflect a change in the officially supported versions of node for Angular. Angular
continues to maintain support for Active LTS and Maintenance LTS versions of node.
PR Close#42205
Remove publishConfig property from the package.json entry for each of the entries in
the publish configuration. Using the wombat proxy is now ensured/managed by the
ng-dev release tooling.
PR Close#42104
URLSearch params are by default supported in the browser but are not supported by angular/http package added support for URLSearchParams
Fixes#36317
PR Close#37852
adding optional body for HTTP delete request options. This new param added as an optional so won't break the existing code also provide the capability the send the body when and where it required.
PR Close#41723
The `ViewportScroller` figures out which element to scroll into view using `document.getElementById`. The problem is that it won't find elements inside the shadow DOM.
These changes add some extra logic that goes through all the shadow roots to look for the element.
Fixes#41470.
PR Close#41644
Add new method `historyGo`, that will let
the user navigate to a specific page from session history identified by its
relative position to the current page.
We add some tests to `location_spec.ts` to validate the behavior of the
`historyGo` and `forward` methods.
Add more tests for `location_spec` to test `location.historyGo(0)`, `location.historyGo()`,
`location.historyGo(100)` and `location.historyGo(-100)`. We also add new tests for
`Integration` spec to validate the navigation when we using
`location#historyGo`.
Update the `historyGo` function docs
Note that this was made an optional function in the abstract classes to
avoid a breaking change. Because our location classes use `implements PlatformLocation`
rather than `extends PlatformLocation`, simply adding a default
implementation was not sufficient to make this a non-breaking change.
While we could fix the classes internal to Angular, this would still have been
a breaking change for any external developers who may have followed our
implementations as an example.
PR Close#38890
The moved `XhrFactory` still needs to be available from `@angular/common/http`
for some libraries that were built prior to 12.0.0, otherwise they cannot be
used in applications built post-12.0.0.
This commit adds back the re-export of `XhrFactory` and deprecates it.
PR Close#41393
With this change we move `XhrFactory` to the root entrypoint of `@angular/commmon`, this is needed so that we can configure `XhrFactory` DI token at a platform level, and not add a dependency between `@angular/platform-browser` and `@angular/common/http`.
Currently, when using `HttpClientModule` in a child module on the server, `ReferenceError: XMLHttpRequest is not defined` is being thrown because the child module has its own Injector and causes `XhrFactory` provider to be configured to use `BrowserXhr`.
Therefore, we should configure the `XhrFactory` at a platform level similar to other Browser specific providers.
BREAKING CHANGE:
`XhrFactory` has been moved from `@angular/common/http` to `@angular/common`.
**Before**
```ts
import {XhrFactory} from '@angular/common/http';
```
**After**
```ts
import {XhrFactory} from '@angular/common';
```
Closes#41311
PR Close#41313
A long-requested feature for HttpClient is the ability to store and retrieve
custom metadata for requests, especially in interceptors. This commit
implements this functionality via a new context object for requests.
Each outgoing HttpRequest now has an associated "context", an instance of
the HttpContext class. An HttpContext can be provided when making a request,
or if not then an empty context is created for the new request. This context
shares its lifecycle with the entire request, even across operations that
change the identity of the HttpRequest instance such as RxJS retries.
The HttpContext functions as an expando. Users can create typed tokens as instances of HttpContextToken, and
read/write a value for the key from any HttpContext object.
This commit implements the HttpContext functionality. A followup commit will
add angular.io documentation.
PR Close#25751
The `DomAdapter` is present in all Angular apps and its methods aren't tree shakeable.
These changes remove the methods that either aren't being used anymore or were only
used by our own tests. Note that these changes aren't breaking, because the adapter
is an internal API.
The following methods were removed:
* `getProperty` - only used within our own tests.
* `log` - Guaranteed to be defined on `console`.
* `logGroup` and `logGroupEnd` - Only used in one place. It was in the DomAdapter for built-in null checking.
* `logGroupEnd` - Only used in one place. It was placed in the DomAdapter for built in null checking.
* `performanceNow` - Only used in one place that has to be invoked through the browser console.
* `supportsCookies` - Unused.
* `getCookie` - Unused.
* `getLocation` and `getHistory` - Only used in one place which appears to have access to the DOM
already, because it had direct accesses to `window`. Furthermore, even if this was being used
in a non-browser context already, the `DominoAdapter` was set up to throw an error.
The following APIs were changed to be more compact:
* `supportsDOMEvents` - Changed to a readonly property.
* `remove` - No longer returns the removed node.
PR Close#41102
This is necessary for closure compiler in order to support cross chunk code motion.
I'm intentionally not annotating these call sites with @__PURE__ at the moment because
build-optimizer does it within the Angular CLI build. In the future we might want to consider
having both annotations here in case we change how build-optimizer works.
PR Close#41096
In the new behavior Angular cleanups `popstate` and `hashchange` event listeners
when the root view gets destroyed, thus event handlers are not added twice
when the application is bootstrapped again.
BREAKING CHANGE:
Methods of the `PlatformLocation` class, namely `onPopState` and `onHashChange`,
used to return `void`. Now those methods return functions that can be called
to remove event handlers.
PR Close#31546
PR Close#40867
This change fixes an incompatibility between the old `@angular/http` package
and its successor (`@angular/common/http`) by re-introducing the types that were supported before.
It now allows to use number and boolean directly as HTTP params, instead of having to convert it to string first.
Before:
this.http.get('/api/config', { params: { page: `${page}` } });
After:
this.http.get('/api/config', { params: { page }});
`HttpParams` has also been updated to have most of its methods accept number or boolean values.
Fixes#23856
BREAKING CHANGE:
The methods of the `HttpParams` class now accept `string | number | boolean`
instead of `string` for the value of a parameter.
If you extended this class in your application,
you'll have to update the signatures of your methods to reflect these changes.
PR Close#40663
Currently `NgTemplateOutlet` recreates its view if its template is swapped out or a context
object with a different shape is passed in. If an object with the same shape is passed in,
we preserve the old view and we mutate the previous object. This mutation of the original
object can be undesirable if two objects with the same shape are swapped between two
different template outlets.
The current behavior is a result of a limitation in `core` where the `context` of an embedded
view is read-only, however a previous commit made it writeable.
These changes resolve the context mutation issue and clean up a bunch of unnecessary
logic from `NgTemplateOutlet` by taking advantage of the earlier change.
Fixes#24515.
PR Close#40360
This commit adds support for Finnish full date formatting,
as well as `c/cc/ccc/cccc/ccccc/cccccc` date formats in the `DatePipe`.
Fixes#26922
PR Close#40766
Before this change, when Google Chrome cancels a XMLHttpRequest, an Observable of the response
never finishes. This happens, for example, when you put your computer to sleep or just press
Ctrl+S to save the browser page. After this commit, if request is canceled or aborted an
appropriate Observable will be completed with an error.
Fixes#22324
PR Close#40767
When using the [timeout attribute](https://xhr.spec.whatwg.org/#the-timeout-attribute) and an XHR
request times out, browsers trigger the `timeout` event (and execute the XHR's `ontimeout`
callback). Additionally, Safari 9 handles timed-out requests in the same way, even if no `timeout`
has been explicitly set on the XHR.
In the above cases, `HttpClient` would fail to capture the XHR's completing (with an error), so
the corresponding `Observable` would never complete.
PR Close#26453
PR Close#39807
Jessica Janiuk
Paul Gschwendtner
Vahid Mohammadi
Kristiyan Kostadinov
Igor Minar
Andrew Scott
Joey Perrott
Ajit Singh
va-stefanek
Gopal Jayaraman
Gourav102
Ben Lesh
Ahmed Ayed
Pete Bacon Darwin
Alan Agius
FDIM
Theoklitos Bampouris
Quentin Monmert
arturovt
Chris
Kapunahele Wong
cexbrayat
Jefiozie
kirjs
Dmitry Drobyshev
Alexey Elin
abarghoud