perf(platform-browser): avoid including Testability by default in bootstrapApplication

[AndrewKushnir]

The Testability-related logic was refactored in #45657 to become tree-shaking-friendly: it was decoupled from the core providers of the BrowserModule. This commit updates the newly-introduced bootstrapApplication function to exclude Testability-providers by default (note: the Testability is still included in the NgModule-based bootstrap).

In order to add the Testability to the app bootstrapped via bootstrapApplication, the withProtractorTestingSupport function is introduced.

PR Type

What kind of change does this PR introduce?

• Other... Please describe: performance improvement

Does this PR introduce a breaking change?

• Yes
• No, since the bootstrapApplication function is not released yet (will be released in v14).

[AndrewKushnir]

Note: CI indicates ~3.5kb of payload size savings for minified version (but before gzip):

Commit f2b0f6da2c20b84dfdfc8a88a2801dfa41a9e22e uncompressed
main fell below expected size by 500 bytes or >1% (expected: 87940, actual: 84237).

[AndrewKushnir]

Update: I've performed manual testing with the following e2e tools (that are presented as options in ng e2e):

• Cypress (@cypress/schematic)
• Nightwatch (@nightwatch/schematics)
• WebdriverIO (@wdio/schematics)

All of them work correctly with the bootstrapApplication-based setup without Testability, so it should not be a problem for users switching to bootstrapApplication.

For Protractor users, this PR adds the withProtractorTestingSupport function that can be used to add Testability providers into the app.

[AndrewKushnir]

Presubmit.

[jessicajaniuk]

reviewed-for: fw-core, integration-tests, public-api, size-tracking

[jelbourn]

I'm kind of iffy on this function starting with with, since I've usually only seen this used with builder-style APIs.

Why not just protractorTestingSupport? That way its use in providers reads like "provide protractor testing support"

[AndrewKushnir]

Thanks for the review @jelbourn 👍

The function will only be used (or rather makes sense) in a context of bootstrapping an app and the call site would look like this:

const appRef = bootstrapApplication(
  RootStandaloneComponent,
  {providers: [withProtractorTestingSupport()]}
);

So we bootstrap an app with protractor testing support - this is where the with prefix comes from. We plan to use similar prefixes for other things (like withRouter, etc). Please let us know what do you think.

// cc @alxhub

[jelbourn]

Yeah, I looked at the usage in the PR. I think that this is inconsistent with how providers like this are normally named and that it's not clear what with is modifying. It would be different if it were e.g.

bootstrapApplication(RootStandaloneComponent, providers: [...])
    .withProtractorSupport();

In that scenario, the with makes sense because it's clearly modifying the bootstrap call. (This builder-style API of course defeats the point of tree-shaking). But providers are traditionally more "noun-y". If you mix this API with other providers, the mismatch stands out:

const appRef = bootstrapApplication(
  RootStandaloneComponent,
  {providers: [
    UserDataClient,
    SideChannelDispatcher,
    withProtractorTestingSupport()
  ]}
);

I read this code like:
"Provide a user data client"
"Provide a side channel dispatcher"
"Provider a with protractor testing support"

[AndrewKushnir]

After some additional discussions, the function was renamed to provideProtractorTestingSupport. We'll have another round of discussions and finalize the name during the RC phase (before v14 final release).

[atscott]

reviewed-for: size-tracking

Withholding public API review so as to not cut short the ongoing conversation about the naming.

[dylhunn]

reviewed-for: public-api, size-tracking

But as atscott I don't intend to cut off the conversation above.

[pkozlowski-opensource]

should we have this e2e test / e2e testing infrastructure at all then? Or even this integration/standalone-bootstrap integration test at all? It seems like we are trying to have 2 things covered by this "app":

• size tracking;
• actual integration testing of the bootstrap operation.

It seems like those 2 needs are in conflict somehow?

[AndrewKushnir]

@pkozlowski-opensource currently those two parts (size tracking and e2e tests) are bundled together in one build rule:

angular/integration/standalone-bootstrap/BUILD.bazel

Lines 3 to 7 in 74321a4

	ng_integration_test(
	name = "test",
	setup_chromium = True,
	track_payload_size = "standalone-bootstrap",
	)

Ideally we'd need to decouple them into 2 separate build rules, so that we have more flexibility in terms of configuration. Once it's done, we can refactor the usage here to just leverage the size-tracking piece.

[alxhub]

Reviewed-for: public-api

[pkozlowski-opensource]

Reviewed-for: public-api

[jessicajaniuk]

reviewed-for: fw-core, integration-tests, public-api, size-tracking

[AndrewKushnir]

This PR was merged into the repository by commit 3165fa3.

[StanislavKharchenko]

@AndrewKushnir Thanks for your response.
What generally will be with Testability functionality?
Do you plan to continue supporting it in the future?
We asking about it since rely on this functionality in our selenium e2e infrastructure.

Thanks.

[AndrewKushnir]

What generally will be with Testability functionality?
Do you plan to continue supporting it in the future?

@StanislavKharchenko the Testability was primarily designed to support Protractor, which is now deprecated. We are considering Testability deprecation as well, but we'll need to do some additional analysis first to understand if there are any critical use-cases that it covers which can not be handled by using other APIs.

If we end up deprecating the Testability classes, there will be an additional communication (via release notes and updates to the deprecations page) and the classes will be available for a long period of time, so developers can transition to other APIs.

We asking about it since rely on this functionality in our selenium e2e infrastructure.

Could you please share a bit more on how you use Testability in your e2e infrastructure and whether there are existing replacement APIs (provided by Angular) that you can consider?

[StanislavKharchenko]

@AndrewKushnir We use FrameworkStabilizer to wait until Angular application finish rendering and available for interaction.
We know about Protractor deprecation and moved to native selenium-webdriver (all other alternatives like webdriver-io, cypress etc are not suitable for our needs).
Since selenium doesn't have built-in waits and explicit waits functionality not enough to make sure that page rendering completed - we taken example of angular-wait provided by Keen https://github.com/kyliau/angular-wait/blob/main/server/server.ts

and whether there are existing replacement APIs (provided by Angular) that you can consider?

We need some condition to check that all pending http requests and angular rendering finished so it guarantee that elements on page will not change. Is there any alternative API provided by Angular to execute js code in browser which say us that Angular fully rendered?
This very critical for our e2e infrastructure.

[AndrewKushnir]

@StanislavKharchenko thanks for additional information.

We need some condition to check that all pending http requests and angular rendering finished so it guarantee that elements on page will not change. Is there any alternative API provided by Angular to execute js code in browser which say us that Angular fully rendered?

As a possible option you can use ApplicationRef.isStable (see more info here). You can obtain a reference to the ApplicationRef by either:

const ngModuleRef = platformBrowser().bootstapModule(YourAppModule);
const appRef = ngModuleRef.injector.get(ApplicatonRef);
// the `appRef.isStable` is available here.

or directly from the bootstrapApplication call:

const appRef = bootstrapApplication(YourRootBootstrapComponent);
// the `appRef.isStable` is available here.

Similar approach is used for the SSR use-cases (see here).

Please let me know if that would work for your use-case.

Thank you.

[StanislavKharchenko]

const ngModuleRef = platformBrowser().bootstapModule(YourAppModule);
const appRef = ngModuleRef.injector.get(ApplicatonRef);
// the appRef.isStable is available here.

@AndrewKushnir It seems this solution is suitable in case if e2e tests are under application structure.
For our cases we have independent e2e infrastructure that lives outside Angular application folder.
So we need something that provided by Angular to execute in browser and get results which say that application stable.
For now - these are "getAngularTestabilities" (or "frameworkstabilizers") from global window object.

Could "ApplicationRef" be accessible from browser not in dev. mode?

[AndrewKushnir]

@StanislavKharchenko I think you can try exposing the ApplicationRef.isStable on the window and get an access to that reference in your e2e test code, so it'd be very close to what you get with Testability classes:

// in your Angular app code:
const appRef = bootstrapApplication(YourRootBootstrapComponent);
window.isAngularAppStable = appRef.isStable;

// later in the e2e code:
window.isAngularAppStable.subscribe( ... );

[StanislavKharchenko]

@AndrewKushnir So it looks like relevant with v14 release when "bootstrapApplication" will be available.
Thanks.

[angular-automatic-lock-bot]

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.}