mirror of
https://github.com/ionic-team/ionic-framework.git
synced 2025-08-18 19:21:34 +08:00
feat(angular): ship Ionic components as Angular standalone components (#28311)
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/910 https://github.com/ionic-team/ionicons/issues/536 https://github.com/ionic-team/ionic-framework/issues/27280 https://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/25404 https://github.com/ionic-team/ionic-framework/issues/27251 https://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/24352 https://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>
This commit is contained in:
64
packages/angular/common/src/utils/routing.ts
Normal file
64
packages/angular/common/src/utils/routing.ts
Normal file
@ -0,0 +1,64 @@
|
||||
/* eslint-disable @typescript-eslint/no-unused-vars */
|
||||
import { ActivatedRouteSnapshot, DetachedRouteHandle, RouteReuseStrategy } from '@angular/router';
|
||||
|
||||
/**
|
||||
* Provides a way to customize when activated routes get reused.
|
||||
*/
|
||||
export class IonicRouteStrategy implements RouteReuseStrategy {
|
||||
/**
|
||||
* Whether the given route should detach for later reuse.
|
||||
*/
|
||||
shouldDetach(_route: ActivatedRouteSnapshot): boolean {
|
||||
return false;
|
||||
}
|
||||
|
||||
/**
|
||||
* Returns `false`, meaning the route (and its subtree) is never reattached
|
||||
*/
|
||||
shouldAttach(_route: ActivatedRouteSnapshot): boolean {
|
||||
return false;
|
||||
}
|
||||
|
||||
/**
|
||||
* A no-op; the route is never stored since this strategy never detaches routes for later re-use.
|
||||
*/
|
||||
store(_route: ActivatedRouteSnapshot, _detachedTree: DetachedRouteHandle): void {
|
||||
return;
|
||||
}
|
||||
|
||||
/**
|
||||
* Returns `null` because this strategy does not store routes for later re-use.
|
||||
*/
|
||||
retrieve(_route: ActivatedRouteSnapshot): DetachedRouteHandle | null {
|
||||
return null;
|
||||
}
|
||||
|
||||
/**
|
||||
* Determines if a route should be reused.
|
||||
* This strategy returns `true` when the future route config and
|
||||
* current route config are identical and all route parameters are identical.
|
||||
*/
|
||||
shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
|
||||
if (future.routeConfig !== curr.routeConfig) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// checking router params
|
||||
const futureParams = future.params;
|
||||
const currentParams = curr.params;
|
||||
const keysA = Object.keys(futureParams);
|
||||
const keysB = Object.keys(currentParams);
|
||||
|
||||
if (keysA.length !== keysB.length) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// Test for A's keys different from B.
|
||||
for (const key of keysA) {
|
||||
if (currentParams[key] !== futureParams[key]) {
|
||||
return false;
|
||||
}
|
||||
}
|
||||
return true;
|
||||
}
|
||||
}
|
Reference in New Issue
Block a user