Ionic 3.0.0 Beta!

Ionic Framework ionic-v3
83

@reedrichards, @rapropos,

Hmm, this is definitely a bug. I am a little confused by it as we don’t do anything interesting or clever here, we differ all of this logic to Webpack. I’ll look into it.

Thanks,
Dan

1 Like
84

Thanks very much @danbucholtz.

85

Hi guys,

Do you have a working copy of :

http://ionicframework.com/docs/v1/nightly/api/navigation/DeepLinker/

Thanks

86

Require node 7+ and ionic-app-script 1.2.3. 1.2.2 just hang trying to build

87

any workaround in using beta3.0?

thanks.

88

Hello, everybody, and thanks for this update. I have a question, my dev team have a big question : How much longer will ionic 1 support? some projects are even developed on v 1.x but some teammates are resisting migrate to v2.0, and the want to know when ionic 1 will be deprecated?.

Thanks a lot for your time.

89

@reedrichards, @rapropos,

I cannot recreate this issue with @ionic/app-scripts@1.2.5. Can you try and verify?

Thanks,
Dan

90

@danbucholtz:

Thanks for taking the time to investigate. Yes, I still see the same behavior with app-scripts 1.2.5. I will try to put together a minimal repo.

91

I’d like to point out that @ionic/cloud and @ionic/cloud-angular still include ionic-native v2.x.x and @angular/core v2.x.x as dependencies. This causes ngc to fail when building for production, essentially making Ionic Cloud unusable on Ionic v3.

1 Like
92

Thanks. This is an extremely highly important issue. I will fix it ASAP. Please let me know if you want to chat further in a DM or something.

Thanks,
Dan

1 Like
93

rapropos/ionic-lazy-sandbox. Sorry it’s rather Q&D, but hopefully illustrates the issue. I was having trouble getting HomePage to get its own module, so ended up adding a third page. All the pages import SharedModule which provides the component that is at issue. When you build the project, hopefully you will see the marker string “katmandu” in both 0.main.js and 1.main.js.

PS: the page generator boilerplate is calling IonicModule.forChild() instead of IonicPageModule.forChild(). No clue if that’s deliberate or a bug.

1 Like
95

Thanks, I’m on it. The generators are being dramatically reworked for Ionic 3. They should be much, much better going forward.

Thanks,
Dan

96

Some numbers if anybody cares on APK sizes. Same codebase, built against Angular 2.4.8: 8.8MB. Built against Angular 4, but without lazy page loading: down to 7.9MB. With lazy page loading (and presumably the corresponding component code duplication): balloons to 11MB.

Startup time goes down from ~3sec with Angular 2 to ~2sec with Angular 4. Tough to say how much of an effect lazy page loading has, because the landing page for existing registered users is fairly heavy.

2 Likes
97

@rapropos,

I see this with Angular CLI too. I am going to pull in Sean Larkin and the Webpack crew to see if we can mitigate this.

See the hello-world Angular CLI reproduction here. Thank you for your help.

Thanks,
Dan

1 Like
98

Is there an issue or some other sort of public convo that I can follow on this?

99

@rapropos,

There is now.

Thanks,
Dan

1 Like
100

and @rapropos

Am I crazy for thinking this is sort of expected behavior. The shared module is not imported into the main module, only the two lazily loaded modules. So webpack doesn’t see it in the main module so it doesn’t bundle it there.

Then webpack sees it in page 1 so it puts it in that chunk, then sees it in page 2 and puts it in that chunk. There’s no way for it to know if one of those chunks has loaded before the other so it has to be in both. However there is a way you can make it know it will be loaded before either chunk, and that’s to import it into the main app module. Then it knows that is already loaded and won’t included it in the lazy loaded pages.

For Angular at least it seems to be a feature: https://github.com/angular/angular-cli/tree/master/packages/%40ngtools/webpack#features

Maybe after Angular splits up the code based on lazy loading it should look for common modules shared by the chunks it’s created and extract those out into their own chunk? Seems like it should be possible using the CommonsChunkPlugin, but since Angular is handling the splitting I don’t know exactly to do that.

1 Like
101

I don’t think so. I sort of half-feared that it was, which is why I didn’t start shouting from the rooftops initially.

Agreed so far.

Here’s where I hope that it’s at least theoretically possible to intervene, although I have nowhere near enough knowledge about webpack’s internals to say much in concrete terms.

One could imagine a world where main.js - the “spine” for lack of a better term - keeps a map of “bones” keyed by module name and valued by either the module code (if it’s been loaded) or an injector that knows how to get it. If bone 2 and bone 3 both want bone 1, once bone 1 has been attached to the spine, regardless of how that happened, it’s there and can be used by any further consumer.

Even if that could be implemented, whether new syntax aside from imports would be required is above my pay grade, but I fear it might.

Absolutely true. If the components in question are heavy, though, that negatively impacts launch time, which (as I understand it) is a major reason why we’re jumping through all these hoops in the first place.

102

So, from the sounds of this issue: Shared module code imported in lazy loaded modules is duplicated · Issue #2771 · angular/angular-cli · GitHub

Seems like you’re fairly close, but the issue is they need a graph instead of flat to keep track of that. I don’t fully understand that myself, but it seems like they need to go a couple levels deep to see that both lazy loaded modules import another module that also lives on it’s own. If they could do that they could make the shared module it’s own chunk. Then evidently only load it once? This is definitely deeper than my webpack knowledge as well at this point.

2 Likes
103

I’m experiencing the same issue when swapping my ngfor into virtualscroll. Seems not to work properly (yet).