feat: Ionic Angular standalone component feedback #28445
Comments
|
I'd like to discuss the @ionic/angular version I'm using. With the adoption of v7.5.3-nightly, I've observed a noticeable reduction in my app's bundle size, all thanks to the standalone feature. Regarding 'addIcon', I think it's an effective means to distribute and manage icons, aligning perfectly with the core concept of the "standalone" approach. However, it's worth noting that despite the benefits, I'm still sticking with v7.5.2 for everything except icons. This decision is primarily driven by the ongoing issues that persist within the standalone approach. By the way, this issue could serve as valuable feedback for further improvement. |
|
Hey there! Thanks for trying the standalone build of Ionic. There are several pieces of feedback here, so I'll reply to each individually.
Ionic uses a tool provided by the Angular CLI called I will also note that ESBuild support is experimental in Angular, so I would expect there to be some issues with that. I recommend providing feedback to the Angular team for issues here since we do not control the ESBuild configuration. If you are still running into treeshaking issues with a Webpack configuration, please open a separate issue with a GitHub repo we can use to reproduce the issue. Treeshaking issues can be tricky, so having a separate thread to discuss will be useful if you are still running into problems.
We actually do provide (experimental) support for migration. You can access it here: https://github.com/ionic-team/ionic-angular-standalone-codemods Since it's experimental, we are rolling it out slowly. We plan to publicize it more in the future. This tool won't migrate everything, but it's designed to assist with some of the more tedious parts of the migration.
I'm not sure I really understand the use case for this. Importing exactly the components you need is by design, so having import groups would mean you are potentially importing more than you need. It also requires the developer to know exactly which components are contained in the import group which can be confusing. For example, an "accordion group" is pretty straightforward, but what should go into a "toolbar group" is fairly subjective.
This is a required process in order to have proper treeshaking and aligns with how other Angular icon libraries work (such as https://ng-icons.github.io/ng-icons/#/). If developers do not define the icons they want to use, then the bundler has no way of knowing which icons should be pulled into the build. As a result, the bundler will pull in every single icon, and the bundle size would increase drastically. The migration tool is designed to assist with registering icons as well. You don't have to call
I agree that the icon error messaging could be improved. I opened ionic-team/ionicons#1297 to address this. I am going to close this since we use this tracker for bug issues and feature requests, but please feel free to reply and I'll be more than happy to continue the conversation. As for the documentation and icon improvements, you can follow the linked thread for updates on that work. |
|
@liamdebeasi thank you for taking the time to respond to my feedback 🙂
Just tested
Awesome. That will help a lot. Do you plan to announce this new tool anytime soon?
I agree, that the toolbar group was a bad example, but I still think card, accordion, list, tabs component groups make perfect sense. How do you know what's inside the group? Just check the docs:
I didn't know. That makes it a lot easier to use. I think mentioning that in the docs will help a lot of other users as well.
Thank you. |
We do test our demo apps, and treeshaking works well there. Unfortunately, there are many ways in which treeshaking can fail (side effects can cause unexpected things to be imported). Can you open a separate issue with a demo? I can take a look.
Yep! I just updated the announcement blog with a link. I also opened ionic-team/ionic-docs#3223 to publicize the migration utility on the documentation.
That's part of my concern for this. I don't think developers should have to constantly reference the documentation website whenever they want to import a component from Ionic. That being said, you should be able to create import groups in your own application which give you a similar result. I think this is a better approach because it allows developers to define groups in a way that makes sense for them/their team. src/import-groups.ts import { IonAccordion, IonAccordionGroup, IonInput, IonTextarea } from '@ionic/angular/standalone';
export const ACCORDION_GROUP = [IonAccordion, IonAccordionGroup];
export const INPUT_GROUP = [IonInput, IonTextarea];src/home/home.page.ts import { Component } from '@angular/core';
import { IonHeader, IonToolbar, IonTitle, IonContent } from '@ionic/angular/standalone';
import { INPUT_GROUP } from '../../import-groups';
@Component({
selector: 'app-home',
templateUrl: 'home.page.html',
styleUrls: ['home.page.scss'],
standalone: true,
imports: [IonHeader, IonToolbar, IonTitle, IonContent, ...INPUT_GROUP],
})
export class HomePage {
constructor() {}
} |
I'll try to crate a simple reproduction ASAP.
Awesome 🙂
Exporting standalone component groups is an official Angular recommendation for library creators and as it wouldn't be mandatory to use the groups instead of importing single components, I think it would only add value to the users, but yes, I can just as easily create the groups myself. imports: [IonContent, ...INPUT_GROUP],Small tip: you can import an array of components in both modules and standalone components without having to use the spread operator: imports: [IonContent, INPUT_GROUP],Same applies to |
|
Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Ionic, please create a new issue and ensure the template is fully filled out. |
Prerequisites
Describe the Feature Request
I have recently tested the new Ionic standalone components and found out that not only the production bundle increased but the DX became worse as well.
Build Stats
Webpack builds with
IonicModule(vanilla experience):Bundle size:
Build time without cache: 64.56s
Build time with cache: 21.75s
Webpack builds with Ionic standalone components (all imports from
@ionic/angular/standalone)Bundle size:
Build time without cache: 65.59s
Build time with cache: 24.45s
Esbuild build with Ionic standalone components
Bundle size:
Build time without cache: 24.44s
Conclusion
Bundle size ballooned from
1.19 MBto1.76 MB(almost 50% increase), cold production build time decreased from64.56sto24.44s(~2.6x decrease).General experience with Ionic standalone components
Cons
importslist. My suggestion would be to export component groups like the following:addIcons()DX is just plain terrible. Not only you have to remember to manually import all the icons, but, when you forget to import some, you get a non-descript error message like the following:My suggestion would be to get rid of
addIcons()and instead add a config toionic.config.jsoncalledicons, where you can list all the icons you want to use. If the user does not provide this config, default to importing all icons like before.Pros
dev serverrebuilds when usingesbuildbuilder. It's a bit faster compared to webpack builds without HMR (ng serve --hmr), but still slower compared to webpack HMR builds.esbuildbuilder.Describe the Use Case
Better DX.
Describe Preferred Solution
No response
Describe Alternatives
No response
Related Code
No response
Additional Information
Small tip for people who want to try the new
esbuildbuilder. If you get errors like the following after switching toesbuild:You have to update your
stylePreprocessorOptionsin the builderoptions:The text was updated successfully, but these errors were encountered: