angular: App won't start on version 2.4.8

@DzmitryShylovich here is the repo to reproduce the issue: http://plnkr.co/edit/RKMEWDN44rf8yoyYP2Ya?p=preview

There is a service called LoginService, in that make variable isLoggedIn true and code in app.component will initialize else not.

Previously, the initial navigation would start after the root component has been created. Now it starts before it has been created. That’s why if you have a CanLoad guard that is somehow initialized in the root component, it won’t work.

Unfortunately, this is the only way for us to wait for the navigation to complete on bootstrap, which is needed for universal.

These are your options:

Do the initialization in the module

@NgModule({
  imports: [
    BrowserModule,
    RouterModule.forRoot(routes)
  ],
  declarations: [ App ],
  bootstrap: [ App ],
  providers: [ Guard, LoginService ]
})
export class AppModule {
  constructor(router: Router, loginService: LoginService) {
    loginService.initialize();
  }
}

This is a better strategy regardless of this issue. No reason to do in the component.

Turns of the initial navigation and do it yourself

@Component({})
class App {
  constructor(router: Router, loginService: LoginService) {
    loginService.initialize();    
    router.initialNavigation();
  }
}

@NgModule({
  imports: [
    BrowserModule,
    RouterModule.forRoot(routes, {initialNavigation: false})
  ],
  declarations: [ App ],
  bootstrap: [ App ],
  providers: [ Guard, LoginService ]
})
export class AppModule {
}

I too have stumbled upon this issue… In our case, the following routing structure was causing the error:

const routes: Routes = [
  path: '',
  canActivate: [SomeGuard],
  children: [
      { path: '', redirect: 'some-route', pathMatch: 'full' },
      { path: 'some-route', loadChildren: '......' },
  ]
];

The issue was resolved as soon as I removed lazy loading of the redirect route.

...
{ path: 'some-route, component: SomeRouteComponent }

Obviously, the module that was lazy loaded before needs to be imported into the AppModule.

The original implementation has been working for a long time, and the app stopped loading only after upgrading to 2.4.8

Edit: Refreshing the page while the user is in any part of the lazy loaded module - doesn’t work now as well… I.e. if the user navigated to any route that was originally lazy loaded, refreshing the page while still being on that route - the app never loads. Guards seem to have no effect in our case.

The issue is gone after downgrading to @angular/router: 3.4.7

@DzmitryShylovich OK let me rephrase my question then, when can we expect 2.4.9 with this fix to be released? 😃

@DzmitryShylovich, @vsavkin I see that the sam set of changes causing this issue (41dd62c) have been included on 4.0.0-rc.1 (2a191ca):

router: do not finish bootstrap until all the routes are resolved (#14608) (2a191ca), closes #12162 #14155

Honestly we all had to fall back at 2.4.7 and it seems that won’t be able to upgrade to a higher version of 4.0.0-beta.8 because these changes (2a191ca).

The question is, Angular 4.0 is planned to be backwards compatible, or not? Are there any plans about the changes on 2a191ca will exist, or be subject to opt-in, (or whatever) on further releases than rc.1?

Enlightment appreciated

The current version of universal works only with 2.x, so pushing it back to v4 isn’t super helpful. Plus, v4 won’t have any breaking changes.

If it is a big issue, we can introduce a separate flag to make the bootstrap logic behave as it does right now. So by default it will behave the same way it did in 3.4.7.

@vicb what do you think?

Can this change not be pushed back to v4? It is a breaking change as demonstrated by the number of people experiencing issues here, and also affected our production site.

@mogusbi the next release

I’m still unsure what the solution is for the lazy loaded routes. If the user tries to go to a lazy loaded route via the url bar, the router-outlet will always be empty, surely? hence the application will never load. I don’t get how lazy loading can work with this

what do you think we can do with it without the info how to reproduce? http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5?p=preview <- app using 2.4.8 and it works fine

This is the best solution 👍 Starting route after APP_Initialize response

@Component({}) class App { constructor(router: Router, loginService: LoginService) { loginService.initialize();
router.initialNavigation(); } }

@NgModule({ imports: [ BrowserModule, RouterModule.forRoot(routes, {initialNavigation: false}) ], declarations: [ App ], bootstrap: [ App ], providers: [ Guard, LoginService ] }) export class AppModule { }

@juanmcampos You don’t have to wait the next release, just fix your package.json dependencies to 2.4.7 instead of 2.4.8. (except 3.4.7 for @angular/router)

Example :

"dependencies": {  
  "@angular/common": "2.4.7",  
  "@angular/compiler": "2.4.7",  
  "@angular/core": "2.4.7",  
  "@angular/forms": "2.4.7",  
  "@angular/http": "2.4.7",  
  "@angular/platform-browser": "2.4.7",  
  "@angular/platform-browser-dynamic": "2.4.7",  
  "@angular/platform-server": "2.4.7",  
  "@angular/router": "3.4.7",
  ...
},
"devDependencies": {
  "@angular/compiler-cli": "2.4.7",
  ...
}`

@steveschmitt In your example there is no single route that is allowed for not logged in user. The fact that this is used to work for you was a side effect. How can you show login button in the first place if you can’t render the page that shows it (since guard keeps it away).

@kirjai see here http://plnkr.co/edit/9z5cXGGXZ4eFSOlX1EuI?p=preview

@steveschmitt we do not resolve https://github.com/angular/angular/blob/2.4.x/modules/@angular/router/src/router_module.ts#L310. That’s why my suggestion didn’t work. It’s a bug.

yeah, it should be reverted in 2.x branch and pushed into 4.x with breaking change commit msg. universal is 4.x only feature anyway

I think that the current way is actually the right way: If my root component has an outlet, I would expect that outlet not to be empty. The empty outlet is a wrong state because there is no way for me to get into that state after the first navigation. The fact that we allowed it before was an accident.

It’s more important for universal users because it actually fails in that scenario.

We also have this problem, closed source app, but I can describe what we do and what the problem seems to be.

TL;DR

Our RouterModule.forChild routes have a resolve that depends on the constructor of the bootstrapped component to run before the promise is resolved. So the child routes will never be resolved before the application is bootstrapped, and with the changes in 3.4.8 version of the router the application will not be bootstrapped before the child routes is resolved, so for us the application stopped working with version 3.4.8, and even though we can probably change our implementation so that it starts working again, I would definitely call this a breaking change and it should have waited until version 4.

What we do, Plunker here : http://plnkr.co/edit/DzaCE5CmMlPXgBrlin5b?p=preview (Might be a bit messy, maily because I have tried extracting the core of it, also there are a lot of style issues, due to partly copying and pasting from our code and partly writing new code in plunker)

We boostrap our AppComponent (Through an AppModule) which in it’s constructor starts fetching all kinds of dependencies (setting up globalize with the correct locales, doing alot of System.imports etc.), when everything is fetched and ready we trigger an observable in a service called finishedLoadingDependencies.

The AppComponent has a router-outlet where we load our ShellComponent which in turn has it’s own router-outlet where we load children using childRoutes, most of these children has a resolve part to their route definition, and this resolve part listens to the finishedLoadingDependencies observable mapped through a promise.

Experiencing a related issue. In 3.4.7 the NavigationStart Router event was emitted on the initial route. In 3.4.8 it no longer is.