@felixfiskare This is caused by the NgUniversal schematics, we added it to avoid flicker when bootstrapping on the client. We’ll move this issue over to angular/universal so that we can track a proper resolution. This may be a warning or a prompt, or possibly a link to documentation about certain pitfalls with adding initialNavigation, like the one you encountered here.

I’ve looked into the docs and the router_module and determined that guards and resolvers being run before the user’s own APP_INITIALIZER is working as intended.

• The router has its own APP_INITIALIZER.
• All APP_INITIALIZERS are run in parallel.
• When using initialNavigation: 'enabled' the router’s APP_INITIALIZER triggers a navigation. This means that if your initial navigation depends on your own APP_INITILIZER being completed first, you cannot use initialNavigation: 'enabled'.
• ApplicationRef.bootstrap (which happens after APP_INITIALIZER completion) calls all APP_BOOTSTRAP_LISTENERs, which triggers initial navigation if using initialNavigation: 'legacy_enabled'
• All of this also seems to follow the documented behavior for initialNavigation:

‘enabled’ - The initial navigation starts before the root component is created. The bootstrap is blocked until the initial navigation is complete. This value is required for server-side rendering to work. ‘legacy_enabled’- (Default, for compatibility.) The initial navigation starts after the root component has been created. The bootstrap is not blocked until the initial navigation is complete.

That said, if initialNavigation: 'enabled' was added automatically when upgrading as you say, this is a bug in the migration since the initialNavigation options are not equivalent.

Hi, any update of when is this going to be merged? Thanks!

Hi guys, here’s the workarounds I’m applying on my project (v11). It works with SRR as well. Hope it helps someone

• There will be a ReplaySubject userInfoSubject to inform the authentication status
• APP_INITIALIZER will call AuthenticationService to check for authentication status and emit the retrieved authentication status by userInfoSuject.next(userInfo). Note that whenever the userInfo changes (by sign in, sign up…) we need to emit the authentication status too
• CanActivate will subscribe to this replay subject

// app.module.ts
function initializeApp(
    authenticationService: AuthenticationService,
): () => Promise<any> | undefined {
    return () => {
        if (typeof window !== 'undefined') {
            return authenticationService.getUserInfo().toPromise();
        }
        return;
    };
}

// authentication.service.ts
export class AuthenticationService {
    userInfo: UserLoginInfo | null | undefined;
    userInfoSubject = new ReplaySubject<UserLoginInfo | null>(1);

    constructor(
        @Inject(PLATFORM_ID) private platformId: Record<string, unknown>,
        @Optional()
        @Inject('authenticatedUserData')
        public authenticatedUserDataFromSsr: UserLoginInfo | null | undefined,
        private httpClient: HttpClient,
        private transferStateService: TransferStateService,
    ) {
        if (isPlatformServer(this.platformId)) {
            this.transferStateService.set<UserLoginInfo | null | undefined>(
                'authenticatedUserData',
                authenticatedUserDataFromSsr
            );
        }
        this.userInfo = this.transferStateService.get('authenticatedUserData');
        if (this.isFetched(this.userInfo)) {
            this.userInfoSubject.next(this.userInfo);
        }
    }

    isFetched(data: any): boolean {
        return typeof data !== 'undefined';
    }

    getUserInfo(): Observable<UserLoginInfo | null | undefined> {
        if (this.isFetched(this.userInfo)) {
            return of(this.userInfo);
        }
        return this.httpClient.get<{ user: UserLoginInfo | null }>('/userData').pipe(
            map((response) => response.user),
            catchError((err) => {
                this.userInfoSubject.next(null);
                return of(null);
            }),
            tap((userInfo) => {
                this.userInfo = userInfo;
                this.userInfoSubject.next(userInfo);
            })
        );
    }
...
}

// authentication.guard.ts
export class AuthenticationGuard implements CanActivate {
    constructor(private authenticationService: AuthenticationService, private router: Router) {}

    canActivate(
        route: ActivatedRouteSnapshot,
        state: RouterStateSnapshot
    ): Observable<boolean | UrlTree> | Promise<boolean | UrlTree> | boolean | UrlTree {
        return this.authenticationService.userInfoSubject.pipe(
            map((userInfo) => {
                if (userInfo) {
                    return true;
                }
                return this.router.parseUrl('/');
            })
        );
    }
}

@nils-thomann, I believe that really depends on your project. For example, in my project I have dynamic routes, which I only know by doing an API Call. So now I have a few assumptions in my routes (so, now it’s not 100% dynamic, but like 80%) and I have a Resolver that makes the same call that I used to do in APP_INITIALIZER.

Yep, same issue here. I “resolved” by adding an “if isPlatformBrowser(this.platformId)” in each guard…

Hi, I’m facing the same issue here too