In past versions a build would create:
vendor.js
main.js
runtime.js
polyfill.js
styles.js
Now when I build I am getting another 165 numbered .js files added into /www/. Is this aspect of 4 just not ready yet, intentionally not compiling everything into main.js or (likely) something I don’t understand?
npm run build -prod is what I’ve been using
All thoughts appreciated.
thanks!
Mostly lazy loading if you didn’t used it in v3. For me already in v3 I had multiple Xx.Js files
Then I guess it’s also the introduction of the use of the Angular Cli and other improvements like code splitting etc.
Okay, thanks. That info helps. If that is standard, I can live with it. It seems there is a lot more weight to it this way though, and unfortunately, AWS S3 counts file uploads as part of its pricing, so that could be an issue. I hit the free upload limit with a couple refreshes.
Thanks!
That’s for the good, the goal is to make the app boot and load faster
For a contrarian viewpoint, I am not a big fan of Ionic’s lazy loading. It is still possible to avoid it in Ionic 4. Delete every page.module.ts file, declare all your components in your app module, and change the router entries in app.routing.ts to look like this instead:
path: "foo", component: FooPage
Give it a try on a scratch branch of your project and see if it reduces your build file count.
Yep, that should work. It’s a nice option. Thanks.
Ionic/Angular lazy loading I guess but I’m curious to hear the reason, could you develop just bit? Pretty sure like always that I will learn something from your post if you’ve got time
I still don’t think they’ve fixed the code duplication problem. My apps tend to have a bunch of relatively heavy components that are reused across several different pages. This means importing them into each page that uses them, resulting in N copies of code that really only needs to be in one place.
As I understand it, the only real hope for addressing this would involve hoisting stuff that is used in multiple places into a “commons chunk”, at which point we have basically reinvented the monolithic app module, adding additional complexity for not a whole lot of benefit.
Which brings me to the PITA factor. There is a lot of boilerplate code involved in declaring all the lazy-loading modules, and things get especially tedious when you have services like ngx-translate and font-awesome which I use virtually everywhere. After spending about 40 minutes wrestling with getting those features working in my first Ionic 4 port, I decided to try throwing everything back in the app module, and found that it drastically reduced my potential points of failure.
If you have an app with seriously compartmentalized code, I could see lazy loading being helpful. I’m still not convinced it’s the right default, though.
Thx for the feedback, interesting. Could I ask you, doing so, putting back everything in a single module, had a bad effect on your boot time or it was still ok? I guess the good thing with v4 is that @ionic/core is base on Web Components which are lazy loaded, therefore in any case the perf should be better than v3
About duplicate code, when I did some tests (Ionic 4 Lazy Loading and Modals) I noticed that code from modals weren’t duplicated but didn’t went further
Final thought: since now the Ionic CLI relies on the Angular CLI which use Webpack, I guess it’s would be more a Webpack improvements than an Ionic thing right? Do you know if there is something open/in progress about this subject?
And thx again for the feedback
Haven’t done extensive benchmarking, but anecdotally, still seems faster than the v3 version.
Probably the best jumping-off point is angular-cli #2771. Although it’s closed, there are links to other related issues.
thx for the feedback, interesting 