Unable to acquire PlatformRef and ModuleRef with aot during bootstrap

Very similar to #8234

Bug Report or Feature Request (mark with an `x`)

- [ X ] bug report -> please search issues before submitting
- [ ] feature request

Versions. ng-cli@rc-8, ng@rc-9

Repro steps.

The following bootstrap code worked somewhere around rc-3 and down:

environment.ngPlatformRef = platformBrowserDynamic();
environment.ngPlatformRef.bootstrapModule(AppModule).then(r => environment.ngModuleRef = r);

The log given by the failure.

Same templateUrl 404's as #8234.
http://localhost:4200/material.component.html 404 (Not Found)

Desired functionality.

The desire is to have the ability to tear down an angular application, as our front end separates behavioral services in a separate parallel application from the angular application. This is done by calling the dispose methods on the module and platform (some detail found in issue for known memory leak: angular/angular#13725). I have tried a few forms of capturing these to no avail (settings to constants first, etc...). As soon as I give up the concern for tearing the ng app down, the standard platformBrowserDynamic().bootstrapModule(AppModule) works fine.

This happens due to the way we try to replace the bootstrap code for AOT. We look for platformBrowserDynamic().bootstrapModule(AppModule) and that detection is not flexible enough to allow for this sort of indirection.

This was fixed, thanks.

Oops, stupid mistake on my part. It still is an issue.

Are you still able to reproduce this issue with the latest version?

Yup, you can drop this into an 'ng new' main.ts and then run with --aot. This was 7.2.0-rc.0 and errors out here. Everything runs fine without aot.

const ngPlatformRef = platformBrowserDynamic();
let ngModuleRef: NgModuleRef<AppModule>;
ngPlatformRef.bootstrapModule(AppModule).then(r => ngModuleRef = r);

@EricABC

@EricABC
What about this option?

import { getPlatform, NgModuleRef, PlatformRef } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

let ngPlatformRef: PlatformRef;
let ngModuleRef: NgModuleRef<AppModule>;

platformBrowserDynamic().bootstrapModule(AppModule)
  .then(r => {
    ngModuleRef = r;
    ngPlatformRef = getPlatform(); // or r.injector.get(PlatformRef);
  });

Thanks for the suggestion. Although this works, it couples the synchronous entry point and resource allocation of angular with the asynchronous application resource allocation. I think there is value in separating the angular context (platform) from the developer context (app bootstrapping). If an angular app fails to bootstrap, there is a way to recover the 'outer' app. This could be useful for any situation where angular works in harmony with other external entry points, frameworks, tooling apps that assist in angular development, etc...

Actually, I was starting to write a proposal to PR this, but Ivy looks like it's being designed to handle more complex use cases, including multiple root nodes and root contexts. I'm thinking that any work here might be short-lived. I'm happy closing this as out of scope, or if desired I could still PR. If you want the PR, I would implement by creating a separate entrypoint discovery context class that explicitly maps SyntaxKind.Identifier entryModuleIdentifiers to imports, discovers variable assignments, and ultimately replaces the expressions. replaceBootstrap and replaceServerBootstrap would both use this class to map one or more entrypoints.

Actually, I tried this and I was able to access and dispose the platform properly at both a synchronous failure (ie. module constructor throws) and an async failure (ie. a component constructor throws).

try {
  platformBrowserDynamic().bootstrapModule(AppModule).catch(e => {
    console.log('async');
    getPlatform().destroy();
  });
} catch (err) {
  console.log('sync');
  getPlatform().destroy();
}

I'd close this, but i'll leave it to you guys since its marked with a higher priority, or if you wanted the PR anyway to support more entrypoint syntax.

I think the approach you are suggesting should be ok. We try to avoid adding more bootstrap patterns because they are brittle by nature.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

Navigation Menu

Repository navigation

Unable to acquire PlatformRef and ModuleRef with aot during bootstrap #8265

Bug Report or Feature Request (mark with an `x`)

Versions. ng-cli@rc-8, ng@rc-9

Repro steps.

The log given by the failure.

Desired functionality.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unable to acquire PlatformRef and ModuleRef with aot during bootstrap #8265

Description

Bug Report or Feature Request (mark with an x)

Versions. ng-cli@rc-8, ng@rc-9

Repro steps.

The log given by the failure.

Desired functionality.

Activity

filipesilva commented on Oct 31, 2017

EricABC commented on May 26, 2018

EricABC commented on May 26, 2018

mgechev commented on Dec 22, 2018

EricABC commented on Dec 22, 2018

alexzuza commented on Dec 23, 2018

EricABC commented on Dec 23, 2018

EricABC commented on Dec 23, 2018

filipesilva commented on Oct 8, 2019

angular-automatic-lock-bot commented on Nov 8, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Bug Report or Feature Request (mark with an `x`)