Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Type checking is disabled in the `standalone/` directory of the angular
project.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Enables type checking in the standalone directories.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Our Angular E2E tests are brittle because they rely on arbitrary
`cy.wait` calls to account for asynchronous routing. This leads to flaky
tests on CI and seemingly random test failures when we make adjustments
to the Ionic Anguar routing integration (see:
https://github.com/ionic-team/ionic-framework/pull/28188)
Additionally, our test execution for the navigation tests is quite slow
because transitions are enabled. As a result, we need to wait hundreds
of ms per test just for the transitions to finish.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the `testStack` command to use a new `getStack` [Cypress
query](https://docs.cypress.io/api/cypress-api/custom-queries). These
queries come with automatic retrying built-in. By leveraging this query
in the `testStack` command, we can avoid the arbitrary waits.
- Added `ionic:_testing=true` query strings to the navigation tests.
This causes Ionic to disable any transitions so the tests execute
faster.
- Removed most of the arbitrary `cy.wait` calls. I kept the swipe to go
back `cy.wait` -- I wasn't quite sure how to reduce flakiness on that
one.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
There is no Angular v17 test app.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
There is an Angular v17 test app.
New overrides:
- angular.json: `browserTarget` was changed to `buildTarget` and to
replace `@nguniversal` with `@angular/ssr` and
`@angular-devkit/build-angular`
- server.ts: Replace uses of `@nguniversal` with `@angular/ssr`
New change to base:
- polyfills.ts: Import
[changed](https://github.com/angular/angular/blob/main/CHANGELOG.md#zonejs)
from `import 'zone.js/dist/zone';` (this change is supported for all
versions of Angular that we support, so should be changed in the base
file)
All other files were duplicated from their v16 counterparts.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `GestureController` provider does not use the correct underlying
instance of the utilities from either the lazy or custom elements build,
depending on if the developer is using `@ionic/angular` or
`@ionic/angular/standalone`. It will always use the lazy instance.
This applied to the `createGesture` function.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `GestureController` uses the instance of the utilities based on it's
implementation type, e.g. `@ionic/angular/standalone` uses the custom
elements build with the utilities from `@ionic/core/components`.
- `@ionic/angular` and `@ionic/angular/standalone` now export their own
specific implementation of `GestureController`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `AnimationController` does not use the correct underlying instance
of the utilities from either the lazy or custom elements build,
depending on if the developer is using `@ionic/angular` or
`@ionic/angular/standalone`. It will always use the lazy instance.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `AnimationController` uses the instance of the utilities based on it's
implementation type, e.g. `@ionic/angular/standalone` uses the custom
elements build with the utilities from `@ionic/core/components`.
- `@ionic/angular` and `@ionic/angular/standalone` now export their own
specific implementation of `AnimationController`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
Ionic was re-exporting the `AnimationController` from both
`@ionic/angular` and `@ionic/angular/standalone` entry points.
Developers will not need to update their implementations or change
import paths to take advantage of this change.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
## What is the current behavior?
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
- Removed the common toast provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
This is part of my work for hack day, but I wanted to tackle the
following problems:
1. There is no easy way to have angular, angular-server, vue,
vue-router, react, and react-router automatically recompile when you
make a change. Right now you have to manually run `npm run build` every
time you make a change.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds `npm run build.watch` to let developers easily watch for changes
in each project.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common modal provider in favor of separate ones in
src/standalone
We already have test coverage for the modalController, so I did not add
new ones
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in src and
standalone. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common popover provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
I didn't add tests because there's already existing ones for popover
controller.
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common action sheet provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#28431
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
My previous attempt at fixing
https://github.com/ionic-team/ionic-framework/issues/28358 caused inputs
to no longer be correctly proxied to the underlying components. This was
an attempt to work around an underlying ng-packagr bug (see linked
thread for more info).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
I decided it would be best to continue using `ProxyCmp` (since we know
that works) and find an alternative to working around the ng-packagr
bug. I spoke with the Angular team, and they recommended pulling the
provider into its own object. `forwardRef` is now required since we are
referencing the component before it is declared.
- Revert
82d6309ef1
- Moves provider to an object to avoid ng-packagr issue
- I reverted the proxy e2e tests. These are no longer needed since we
are not ejecting from the typical `ProxyCmp` usage anymore.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.3-dev.11698699090.1151d73f`
Verified that the issue is fixed with the repro provided in
https://github.com/ionic-team/ionic-framework/issues/28431
Also verified that this does not regress the issue described in
https://github.com/ionic-team/ionic-framework/issues/28358.
Issue number: resolves#28418
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Due to
https://github.com/ionic-team/stencil-ds-output-targets/issues/397,
calling `proxyInputs` for the form controls caused an error to be logged
in developer applications.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated to a version of the Angular output targets with a patch for
this error
- I also excluded the `utils.ts` from all `angular-component-lib`
directories from prettier since it was causing a diff. These changes are
autogenerated so we should not be linting them anyways.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.3-dev.11698340692.18daff2f`
Issue number: resolves#28417
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The common `IonRouterOutlet` was trying to inject another common
`IonRouterOutlet` into `parentOutlet`:
dc94ae01fe/packages/angular/common/src/directives/navigation/router-outlet.ts (L119)
None existed, so this field was `null`.
This is a problem if developers are using the module `IonRouterOutlet`
since parent router outlets will not be currently injected because
Angular is trying to use the common `IonRouterOutlet` not the module
`IonRouterOutlet`:
https://github.com/ionic-team/ionic-framework/blob/main/packages/angular/src/directives/navigation/ion-router-outlet.ts.
The same goes for the standalone `IonRouterOutlet`.
This resulted in things such as `NavController.pop` not working in
nested outlets because the parentOutlet was not defined.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `IonRouterOutlet` now injects the correct router outlet instance for
`parentOutlet`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.3-dev.11698328998.1a79f815`
Issue number: #19539
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When an app uses Capacitor, then the platform subscriptions will run
outside of the Angular Zone.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The platform subscriptions will run inside of the Angular Zone
regardless if it uses Capacitor or not.
Added an extra `zone.run` within the event listener.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `npm install @ionic/angular@7.5.2-dev.11698187124.1b7ea660`
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Prettier is configured to ignore the `proxies.ts` file in the `src`
directory only. This means it is adjusting whitespace/commas/etc on the
`proxies.ts` file in the `standalone` directory which we do not want
because we will always get diffs whenever `npm run build` is run in
`core`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated prettier config to ignore all `proxies.ts` files in the
`angular` package
- Re-generated the proxies file
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#28358
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
28f2ec9c62
exposed a (possible) `ng-packagr` bug where the form control components
were being re-assigned, which breaks treeshaking. These components were
considered side effects and were always being pulled into the bundle.
This resulted in a higher than expected bundle size. This issue appears
to be caused by using 2 decorators **and** referring to the class in
`useExisting` (for providers). Doing just one of these does not
reproduce the issue.
The compiled output looks something like this:
```typescript
let IonToggle = IonToggle_1 = /*@__PURE__*/ class IonToggle extends ValueAccessor {
constructor(c, r, z, injector) {
super(injector, r);
this.z = z;
c.detach();
this.el = r.nativeElement;
proxyOutputs(this, this.el, ['ionChange', 'ionFocus', 'ionBlur']);
}
writeValue(value) {
this.elementRef.nativeElement.checked = this.lastValue = value;
setIonicClasses(this.elementRef);
}
handleIonChange(el) {
this.handleValueChange(el, el.checked);
}
};
/** @nocollapse */ IonToggle.ɵfac = i0.ɵɵngDeclareFactory({ minVersion: "12.0.0", version: "14.2.12", ngImport: i0, type: IonToggle, deps: [{ token: i0.ChangeDetectorRef }, { token: i0.ElementRef }, { token: i0.NgZone }, { token: i0.Injector }], target: i0.ɵɵFactoryTarget.Component });
/** @nocollapse */ IonToggle.ɵcmp = i0.ɵɵngDeclareComponent({ minVersion: "14.0.0", version: "14.2.12", type: IonToggle, isStandalone: true, selector: "ion-toggle", inputs: { checked: "checked", color: "color", disabled: "disabled", enableOnOffLabels: "enableOnOffLabels", justify: "justify", labelPlacement: "labelPlacement", legacy: "legacy", mode: "mode", name: "name", value: "value" }, host: { listeners: { "ionChange": "handleIonChange($event.target)" } }, providers: [
{
provide: NG_VALUE_ACCESSOR,
useExisting: IonToggle_1,
multi: true,
},
], usesInheritance: true, ngImport: i0, template: '<ng-content></ng-content>', isInline: true, changeDetection: i0.ChangeDetectionStrategy.OnPush });
IonToggle = IonToggle_1 = __decorate([
ProxyCmp({
defineCustomElementFn: defineCustomElement$1i,
inputs: TOGGLE_INPUTS,
})
], IonToggle);
```
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the `ProxyCmp` usage in favor of manually calling proxyInputs
and proxyMethods.
- Also saw that select was missing a form control test, so I added one
The compiled code now looks something like this:
```typescript
class IonToggle extends ValueAccessor {
constructor(c, r, z, injector) {
super(injector, r);
this.z = z;
defineCustomElement$1i();
proxyInputs(IonToggle, TOGGLE_INPUTS);
c.detach();
this.el = r.nativeElement;
proxyOutputs(this, this.el, ['ionChange', 'ionFocus', 'ionBlur']);
}
writeValue(value) {
this.elementRef.nativeElement.checked = this.lastValue = value;
setIonicClasses(this.elementRef);
}
handleIonChange(el) {
this.handleValueChange(el, el.checked);
}
}
/** @nocollapse */ IonToggle.ɵfac = i0.ɵɵngDeclareFactory({ minVersion: "12.0.0", version: "14.2.12", ngImport: i0, type: IonToggle, deps: [{ token: i0.ChangeDetectorRef }, { token: i0.ElementRef }, { token: i0.NgZone }, { token: i0.Injector }], target: i0.ɵɵFactoryTarget.Component });
/** @nocollapse */ IonToggle.ɵcmp = i0.ɵɵngDeclareComponent({ minVersion: "14.0.0", version: "14.2.12", type: IonToggle, isStandalone: true, selector: "ion-toggle", inputs: { checked: "checked", color: "color", disabled: "disabled", enableOnOffLabels: "enableOnOffLabels", justify: "justify", labelPlacement: "labelPlacement", legacy: "legacy", mode: "mode", name: "name", value: "value" }, host: { listeners: { "ionChange": "handleIonChange($event.target)" } }, providers: [
{
provide: NG_VALUE_ACCESSOR,
useExisting: IonToggle,
multi: true,
},
], usesInheritance: true, ngImport: i0, template: '<ng-content></ng-content>', isInline: true, changeDetection: i0.ChangeDetectionStrategy.OnPush });
```
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Ryan provided some context on a related Stencil bug where doing
reassignments broke treeshaking in Webpack. While the source of this bug
is not Stencil, understanding the Stencil bug helped me better
understand this issue:
https://github.com/ionic-team/stencil/issues/3191https://github.com/ionic-team/stencil/pull/3248https://github.com/ionic-team/stencil/pull/4188 (fixes an issue
introduced in the above stencil PR)
Dev build: `7.5.1-dev.11697480817.10fa2601`
Issue number: resolves#28337
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Duplicate instances of `menuController` are being created in
`@ionic/angular`. `ion-menu` registers itself in the `menuController`
from `@ionic/core`, but the `MenuController` from `@ionic/angular` uses
the `menuController` from `@ionic/core/components`. This is how the
overlay providers work too. Normally, this is not a problem. However,
`menuController` caches references to registered menus in each
controller instances:
dcbf45101f/core/src/utils/menu-controller/index.ts (L14)
This means that since there are two different controllers,
`menuController` B does not know about the menus in `menuController` A.
The end result is that the menu controller used in developer
applications did not have references to the registered menus, which gave
the impression that the menu controller did not work.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the architecture of `MenuController` in Ionic Angular to
accept a `menuController` instance. This allows `@ionic/angular` to pass
the `menuController` from `@ionic/core` and for
`@ionic/angular/standalone` to pass the `menuController` from
`@ionic/core/components`.
Note: Overlay controllers don't **need** this change per-se since they
don't cache references to overlays internally (they just query the DOM).
However, I think it would be good to have a consistent architecture
here, so I'll put up a separate PR that makes this change for overlays
too.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
Dev build: `7.5.1-dev.11697123035.1ee6b4a2`
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
Resolves feedback identified here:
baa37ef1e3 (r1356414362)
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The lifecycle interfaces are not exported from
`@ionic/angular/standalone`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Lifecycle interfaces are exported from `@ionic/angular/standalone`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
**1. Bundle Size Reductions**
All Ionic UI components and Ionicons are added to the final bundle of an
Ionic Angular application. This is because all components and icons are
lazily loaded as needed. This prevents the compiler from properly tree
shaking applications. This does not cause all components and icons to be
loaded on application start, but it does increase the size of the final
app output that all users need to download.
**Related Issues**
https://github.com/ionic-team/ionicons/issues/910https://github.com/ionic-team/ionicons/issues/536https://github.com/ionic-team/ionic-framework/issues/27280https://github.com/ionic-team/ionic-framework/issues/24352
**2. Standalone Component Support**
Standalone Components are a stable API as of Angular 15. The Ionic
starter apps on the CLI have NgModule and Standalone options, but all of
the Ionic components are still lazily/dynamically loaded using
`IonicModule`. Standalone components in Ionic also enable support for
new Angular features such as bundling with ESBuild instead of Webpack.
ESBuild does not work in Ionic Angular right now because components
cannot be statically analyzed since they are dynamically imported.
We added preliminary support for standalone components in Ionic v6.3.0.
This enabled developers to use their own custom standalone components
when routing with `ion-router-outlet`. However, we did not ship
standalone components for Ionic's UI components.
**Related Issues**
https://github.com/ionic-team/ionic-framework/issues/25404https://github.com/ionic-team/ionic-framework/issues/27251https://github.com/ionic-team/ionic-framework/issues/27387
**3. Faster Component Load Times**
Since Ionic Angular components are lazily loaded, they also need to be
hydrated. However, this hydration does not happen immediately which
prevents components from being usable for multiple frames.
**Related Issues**
https://github.com/ionic-team/ionic-framework/issues/24352https://github.com/ionic-team/ionic-framework/issues/26474
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic components and directives are accessible as Angular standalone
components/directives
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Associated documentation branch:
https://github.com/ionic-team/ionic-docs/tree/feature-7.5
---------
Co-authored-by: Maria Hutt <thetaPC@users.noreply.github.com>
Co-authored-by: Sean Perkins <sean@ionic.io>
Co-authored-by: Amanda Johnston <90629384+amandaejohnston@users.noreply.github.com>
Co-authored-by: Maria Hutt <maria@ionic.io>
Co-authored-by: Sean Perkins <13732623+sean-perkins@users.noreply.github.com>
Issue number: resolves#27911
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `openURL` utility is not available to developers.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Export `openURL` utilities from `@ionic/core`, `@ionic/angular`,
`@ionic/react` and `@ionic/vue`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#17499
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Currently, there isn't a way to position toasts such that they don't
overlap navigation elements such as headers, footers, and FABs.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Added the new `positionAnchor` property, which specifies an element that
the toast's position should be anchored to.
While the name can be tweaked, we should take care to keep the relation
between it and the `position` property clear. The `position` acts as a
sort of "origin" point, and the toast is moved from there to sit near
the chosen anchor element. This is important because it helps clarify
why the toast sits above the anchor for `position="bottom"` and vice
versa.
I chose not to rename the `position` prop itself to avoid breaking
changes.
Docs PR: https://github.com/ionic-team/ionic-docs/pull/3158
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
CI is failing for Cypress apps due to
https://github.com/cypress-io/cypress/issues/27804#issuecomment-1721476731.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- All Cypress test apps have been updated to Cypress 13.2.0 which is not
affected by this issue.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
