angular/packages/elements/src/create-custom-element.ts

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

255 lines
8.8 KiB
TypeScript
Raw Normal View History

/**
* @license
* Copyright Google LLC All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.dev/license
*/
import {Injector, Type} from '@angular/core';
import {Subscription} from 'rxjs';
import {ComponentNgElementStrategyFactory} from './component-factory-strategy';
import {NgElementStrategy, NgElementStrategyFactory} from './element-strategy';
import {getComponentInputs, getDefaultAttributeToPropertyInputs} from './utils';
/**
* Prototype for a class constructor based on an Angular component
* that can be used for custom element registration. Implemented and returned
* by the {@link createCustomElement createCustomElement() function}.
*
* @see [Angular Elements Overview](guide/elements "Turning Angular components into custom elements")
*
* @publicApi
*/
export interface NgElementConstructor<P> {
/**
* An array of observed attribute names for the custom element,
* derived by transforming input property names from the source component.
*/
readonly observedAttributes: string[];
/**
* Initializes a constructor instance.
build: typescript 3.8 support (#35864) This commit adds support in the Angular monorepo and in the Angular compiler(s) for TypeScript 3.8. All packages can now compile with TS 3.8. For most of the repo, only a handful few typings adjustments were needed: * TS 3.8 has a new `CustomElementConstructor` DOM type, which enforces a zero-argument constructor. The `NgElementConstructor` type previously declared a required `injector` argument despite the fact that its implementation allowed `injector` to be optional. The interface type was updated to reflect the optionality of the argument. * Certain error messages were changed, and expectations in tests were updated as a result. * tsserver (part of language server) now returns performance information in responses, so test expectations were changed to only assert on the actual body content of responses. For compiler-cli and schematics (which use the TypeScript AST) a major breaking change was the introduction of the export form: ```typescript export * as foo from 'bar'; ``` This is a `ts.NamespaceExport`, and the `exportClause` of a `ts.ExportDeclaration` can now take this type as well as `ts.NamedExports`. This broke a lot of places where `exportClause` was assumed to be `ts.NamedExports`. For the most part these breakages were in cases where it is not necessary to handle the new `ts.NamedExports` anyway. ngtsc's design uses the `ts.TypeChecker` APIs to understand syntax and so automatically supports the new form of exports. The View Engine compiler on the other hand extracts TS structures into metadata.json files, and that format was not designed for namespaced exports. As a result it will take a nontrivial amount of work if we want to support such exports in View Engine. For now, these new exports are not accounted for in metadata.json, and so using them in "folded" Angular expressions will result in errors (probably claiming that the referenced exported namespace doesn't exist). Care was taken to only use TS APIs which are present in 3.7/3.6, as Angular needs to remain compatible with these for the time being. This commit does not update angular.io. PR Close #35864
2020-03-05 01:27:27 +00:00
* @param injector If provided, overrides the configured injector.
*/
new (injector?: Injector): NgElement & WithProperties<P>;
}
/**
* Implements the functionality needed for a custom element.
*
* @publicApi
*/
export abstract class NgElement extends HTMLElement {
/**
* The strategy that controls how a component is transformed in a custom element.
*/
protected abstract ngElementStrategy: NgElementStrategy;
/**
* A subscription to change, connect, and disconnect events in the custom element.
*/
protected ngElementEventsSubscription: Subscription | null = null;
/**
* Prototype for a handler that responds to a change in an observed attribute.
* @param attrName The name of the attribute that has changed.
* @param oldValue The previous value of the attribute.
* @param newValue The new value of the attribute.
* @param namespace The namespace in which the attribute is defined.
* @returns Nothing.
*/
abstract attributeChangedCallback(
attrName: string,
oldValue: string | null,
newValue: string,
namespace?: string,
): void;
/**
* Prototype for a handler that responds to the insertion of the custom element in the DOM.
* @returns Nothing.
*/
abstract connectedCallback(): void;
/**
* Prototype for a handler that responds to the deletion of the custom element from the DOM.
* @returns Nothing.
*/
abstract disconnectedCallback(): void;
}
/**
* Additional type information that can be added to the NgElement class,
* for properties that are added based
* on the inputs and methods of the underlying component.
*
* @publicApi
*/
export type WithProperties<P> = {
[property in keyof P]: P[property];
};
/**
* A configuration that initializes an NgElementConstructor with the
* dependencies and strategy it needs to transform a component into
* a custom element class.
*
* @publicApi
*/
export interface NgElementConfig {
/**
* The injector to use for retrieving the component's factory.
*/
injector: Injector;
/**
* An optional custom strategy factory to use instead of the default.
* The strategy controls how the transformation is performed.
*/
strategyFactory?: NgElementStrategyFactory;
}
/**
* @description Creates a custom element class based on an Angular component.
*
* Builds a class that encapsulates the functionality of the provided component and
* uses the configuration information to provide more context to the class.
* Takes the component factory's inputs and outputs to convert them to the proper
* custom element API and add hooks to input changes.
*
* The configuration's injector is the initial injector set on the class,
* and used by default for each created instance.This behavior can be overridden with the
* static property to affect all newly created instances, or as a constructor argument for
* one-off creations.
*
* @see [Angular Elements Overview](guide/elements "Turning Angular components into custom elements")
*
* @param component The component to transform.
* @param config A configuration that provides initialization information to the created class.
* @returns The custom-element construction class, which can be registered with
* a browser's `CustomElementRegistry`.
*
* @publicApi
*/
export function createCustomElement<P>(
component: Type<any>,
config: NgElementConfig,
): NgElementConstructor<P> {
const inputs = getComponentInputs(component, config.injector);
const strategyFactory =
config.strategyFactory || new ComponentNgElementStrategyFactory(component, config.injector);
const attributeToPropertyInputs = getDefaultAttributeToPropertyInputs(inputs);
class NgElementImpl extends NgElement {
// Work around a bug in closure typed optimizations(b/79557487) where it is not honoring static
// field externs. So using quoted access to explicitly prevent renaming.
static readonly ['observedAttributes'] = Object.keys(attributeToPropertyInputs);
protected override get ngElementStrategy(): NgElementStrategy {
// TODO(andrewseguin): Add e2e tests that cover cases where the constructor isn't called. For
// now this is tested using a Google internal test suite.
if (!this._ngElementStrategy) {
const strategy = (this._ngElementStrategy = strategyFactory.create(
this.injector || config.injector,
));
// Re-apply pre-existing input values (set as properties on the element) through the
// strategy.
fix(elements): switch to `ComponentRef.setInput` & remove custom scheduler (#56728) The custom element implementation previously used a custom code path for setting inputs, which contained bespoke code for writing input properties, detecting whether inputs actually change, marking the component dirty, scheduling and running CD, invoking `ngOnChanges`, etc. This custom logic had several downsides: * Its behavior different from how Angular components behave in a normal template. For example, inputs setters were invoked in `NgZone.run`, which (when called from outside the zone) would trigger synchronous CD in the component, _without_ calling `ngOnChanges`. Only when the custom rAF- scheduled `detectChanges()` call triggered would `ngOnChanges` be called. * CD always ran multiple times, because of the above. `NgZone.run` would trigger CD, and then separately the scheduler would trigger CD. * Signal inputs were not supported, since inputs were set via direct property writes. This change refactors the custom element implementation with two changes: 1. `ComponentRef.setInput` is used instead of a custom code path for writing inputs. This allows us to drop all the custom logic related to managing `ngOnChanges`, since `setInput` does that under the hood. `ngOnChanges` behavior now matches how the component would behave when _not_ rendered as a custom element. 2. The custom rAF-based CD scheduler is removed in favor of the main Angular scheduler, which now handles custom elements as necessary. Running `NgZone.run` is sufficient to trigger CD when zones are used, and the hybrid zoneless scheduler now ensures CD is scheduled when `setInput` is called even with no ZoneJS enabled. As a result, the dedicated elements scheduler is now only used when Angular's built-in scheduler is disabled. As a concession to backwards compatibility, the element's view is also marked for refresh when an input changes. Doing this allows CD to revisit the element even if it becomes dirty during CD, mimicking how it would be detected by the former elements scheduler unconditionally refreshing the view a second time. As a part of this change, the elements tests have been significantly refactored. Previously all of Angular was faked/spied, which had a number of downsides. For example, there were tests which asserted that change detection only happens once when setting multiple inputs. This wasn't actually the case (because of `NgZone.run` - see logic above) but the test didn't catch the issue because it was only spying on `detectChanges()` which isn't called from `ApplicationRef.tick()`. Even the components were fake. Now, the tests use real Angular components and factories. They've also been updated to not use `fakeAsync`. A number of tests have been disabled, which were previously asserting behavior that wasn't matching what was actually happening (as above). Other tests were disabled due to real differences with `ngOnChanges` behavior, where the current behavior could be seen as a bug. Fixes #53981 BREAKING CHANGE: as part of switching away from custom CD behavior to the hybrid scheduler, timing of change detection around custom elements has changed subtly. These changes make elements more efficient, but can cause tests which encoded assumptions about how or when elements would be checked to require updating. PR Close #56728
2024-06-26 23:09:59 +00:00
// TODO(alxhub): why are we doing this? this makes no sense.
inputs.forEach(({propName, transform}) => {
if (!this.hasOwnProperty(propName)) {
// No pre-existing value for `propName`.
return;
}
// Delete the property from the DOM node and re-apply it through the strategy.
const value = (this as any)[propName];
delete (this as any)[propName];
strategy.setInputValue(propName, value, transform);
});
}
return this._ngElementStrategy!;
}
private _ngElementStrategy?: NgElementStrategy;
constructor(private readonly injector?: Injector) {
super();
}
override attributeChangedCallback(
attrName: string,
oldValue: string | null,
newValue: string,
namespace?: string,
): void {
const [propName, transform] = attributeToPropertyInputs[attrName]!;
this.ngElementStrategy.setInputValue(propName, newValue, transform);
}
override connectedCallback(): void {
fix(elements): fire custom element output events during component initialization (#37570) Previously, event listeners for component output events attached on an Angular custom element before inserting it into the DOM (i.e. before instantiating the underlying component) didn't fire for events emitted during initialization lifecycle hooks, such as `ngAfterContentInit`, `ngAfterViewInit`, `ngOnChanges` (initial call) and `ngOnInit`. The reason was that `NgElementImpl` [subscribed to events][1] _after_ calling [ngElementStrategy#connect()][2], which is where the [initial change detection][3] takes place (running the initialization lifecycle hooks). This commit fixes this by: 1. Ensuring `ComponentNgElementStrategy#events` is defined and available for subscribing to, even before instantiating the component. 2. Changing `NgElementImpl` to subscribe to `NgElementStrategy#events` (if available) before calling `NgElementStrategy#connect()` (which initializes the component instance) if available. 3. Falling back to the old behavior (subscribing to `events` after calling `connect()` for strategies that do not initialize `events` before their `connect()` is run). NOTE: By falling back to the old behavior when `NgElementStrategy#events` is not initialized before calling `NgElementStrategy#connect()`, we avoid breaking existing custom `NgElementStrategy` implementations (with @remackgeek's [ElementZoneStrategy][4] being a commonly used example). Jira issue: [FW-2010](https://angular-team.atlassian.net/browse/FW-2010) [1]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L167-L170 [2]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L164 [3]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/component-factory-strategy.ts#L158 [4]: https://github.com/remackgeek/elements-zone-strategy/blob/f1b6699495a8c0909dbbfbdca12770ecca843e15/projects/elements-zone-strategy/src/lib/element-zone-strategy.ts Fixes #36141 PR Close #37570
2020-06-13 08:06:35 +00:00
// For historical reasons, some strategies may not have initialized the `events` property
// until after `connect()` is run. Subscribe to `events` if it is available before running
// `connect()` (in order to capture events emitted during initialization), otherwise subscribe
// afterwards.
fix(elements): fire custom element output events during component initialization (#37570) Previously, event listeners for component output events attached on an Angular custom element before inserting it into the DOM (i.e. before instantiating the underlying component) didn't fire for events emitted during initialization lifecycle hooks, such as `ngAfterContentInit`, `ngAfterViewInit`, `ngOnChanges` (initial call) and `ngOnInit`. The reason was that `NgElementImpl` [subscribed to events][1] _after_ calling [ngElementStrategy#connect()][2], which is where the [initial change detection][3] takes place (running the initialization lifecycle hooks). This commit fixes this by: 1. Ensuring `ComponentNgElementStrategy#events` is defined and available for subscribing to, even before instantiating the component. 2. Changing `NgElementImpl` to subscribe to `NgElementStrategy#events` (if available) before calling `NgElementStrategy#connect()` (which initializes the component instance) if available. 3. Falling back to the old behavior (subscribing to `events` after calling `connect()` for strategies that do not initialize `events` before their `connect()` is run). NOTE: By falling back to the old behavior when `NgElementStrategy#events` is not initialized before calling `NgElementStrategy#connect()`, we avoid breaking existing custom `NgElementStrategy` implementations (with @remackgeek's [ElementZoneStrategy][4] being a commonly used example). Jira issue: [FW-2010](https://angular-team.atlassian.net/browse/FW-2010) [1]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L167-L170 [2]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L164 [3]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/component-factory-strategy.ts#L158 [4]: https://github.com/remackgeek/elements-zone-strategy/blob/f1b6699495a8c0909dbbfbdca12770ecca843e15/projects/elements-zone-strategy/src/lib/element-zone-strategy.ts Fixes #36141 PR Close #37570
2020-06-13 08:06:35 +00:00
//
// TODO: Consider deprecating/removing the post-connect subscription in a future major version
// (e.g. v11).
let subscribedToEvents = false;
if (this.ngElementStrategy.events) {
// `events` are already available: Subscribe to it asap.
this.subscribeToEvents();
subscribedToEvents = true;
}
this.ngElementStrategy.connect(this);
fix(elements): fire custom element output events during component initialization (#37570) Previously, event listeners for component output events attached on an Angular custom element before inserting it into the DOM (i.e. before instantiating the underlying component) didn't fire for events emitted during initialization lifecycle hooks, such as `ngAfterContentInit`, `ngAfterViewInit`, `ngOnChanges` (initial call) and `ngOnInit`. The reason was that `NgElementImpl` [subscribed to events][1] _after_ calling [ngElementStrategy#connect()][2], which is where the [initial change detection][3] takes place (running the initialization lifecycle hooks). This commit fixes this by: 1. Ensuring `ComponentNgElementStrategy#events` is defined and available for subscribing to, even before instantiating the component. 2. Changing `NgElementImpl` to subscribe to `NgElementStrategy#events` (if available) before calling `NgElementStrategy#connect()` (which initializes the component instance) if available. 3. Falling back to the old behavior (subscribing to `events` after calling `connect()` for strategies that do not initialize `events` before their `connect()` is run). NOTE: By falling back to the old behavior when `NgElementStrategy#events` is not initialized before calling `NgElementStrategy#connect()`, we avoid breaking existing custom `NgElementStrategy` implementations (with @remackgeek's [ElementZoneStrategy][4] being a commonly used example). Jira issue: [FW-2010](https://angular-team.atlassian.net/browse/FW-2010) [1]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L167-L170 [2]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L164 [3]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/component-factory-strategy.ts#L158 [4]: https://github.com/remackgeek/elements-zone-strategy/blob/f1b6699495a8c0909dbbfbdca12770ecca843e15/projects/elements-zone-strategy/src/lib/element-zone-strategy.ts Fixes #36141 PR Close #37570
2020-06-13 08:06:35 +00:00
if (!subscribedToEvents) {
// `events` were not initialized before running `connect()`: Subscribe to them now.
// The events emitted during the component initialization have been missed, but at least
// future events will be captured.
this.subscribeToEvents();
}
}
override disconnectedCallback(): void {
// Not using `this.ngElementStrategy` to avoid unnecessarily creating the `NgElementStrategy`.
if (this._ngElementStrategy) {
this._ngElementStrategy.disconnect();
}
if (this.ngElementEventsSubscription) {
this.ngElementEventsSubscription.unsubscribe();
this.ngElementEventsSubscription = null;
}
}
fix(elements): fire custom element output events during component initialization (#37570) Previously, event listeners for component output events attached on an Angular custom element before inserting it into the DOM (i.e. before instantiating the underlying component) didn't fire for events emitted during initialization lifecycle hooks, such as `ngAfterContentInit`, `ngAfterViewInit`, `ngOnChanges` (initial call) and `ngOnInit`. The reason was that `NgElementImpl` [subscribed to events][1] _after_ calling [ngElementStrategy#connect()][2], which is where the [initial change detection][3] takes place (running the initialization lifecycle hooks). This commit fixes this by: 1. Ensuring `ComponentNgElementStrategy#events` is defined and available for subscribing to, even before instantiating the component. 2. Changing `NgElementImpl` to subscribe to `NgElementStrategy#events` (if available) before calling `NgElementStrategy#connect()` (which initializes the component instance) if available. 3. Falling back to the old behavior (subscribing to `events` after calling `connect()` for strategies that do not initialize `events` before their `connect()` is run). NOTE: By falling back to the old behavior when `NgElementStrategy#events` is not initialized before calling `NgElementStrategy#connect()`, we avoid breaking existing custom `NgElementStrategy` implementations (with @remackgeek's [ElementZoneStrategy][4] being a commonly used example). Jira issue: [FW-2010](https://angular-team.atlassian.net/browse/FW-2010) [1]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L167-L170 [2]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L164 [3]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/component-factory-strategy.ts#L158 [4]: https://github.com/remackgeek/elements-zone-strategy/blob/f1b6699495a8c0909dbbfbdca12770ecca843e15/projects/elements-zone-strategy/src/lib/element-zone-strategy.ts Fixes #36141 PR Close #37570
2020-06-13 08:06:35 +00:00
private subscribeToEvents(): void {
// Listen for events from the strategy and dispatch them as custom events.
this.ngElementEventsSubscription = this.ngElementStrategy.events.subscribe((e) => {
const customEvent = new CustomEvent(e.name, {detail: e.value});
fix(elements): fire custom element output events during component initialization (#37570) Previously, event listeners for component output events attached on an Angular custom element before inserting it into the DOM (i.e. before instantiating the underlying component) didn't fire for events emitted during initialization lifecycle hooks, such as `ngAfterContentInit`, `ngAfterViewInit`, `ngOnChanges` (initial call) and `ngOnInit`. The reason was that `NgElementImpl` [subscribed to events][1] _after_ calling [ngElementStrategy#connect()][2], which is where the [initial change detection][3] takes place (running the initialization lifecycle hooks). This commit fixes this by: 1. Ensuring `ComponentNgElementStrategy#events` is defined and available for subscribing to, even before instantiating the component. 2. Changing `NgElementImpl` to subscribe to `NgElementStrategy#events` (if available) before calling `NgElementStrategy#connect()` (which initializes the component instance) if available. 3. Falling back to the old behavior (subscribing to `events` after calling `connect()` for strategies that do not initialize `events` before their `connect()` is run). NOTE: By falling back to the old behavior when `NgElementStrategy#events` is not initialized before calling `NgElementStrategy#connect()`, we avoid breaking existing custom `NgElementStrategy` implementations (with @remackgeek's [ElementZoneStrategy][4] being a commonly used example). Jira issue: [FW-2010](https://angular-team.atlassian.net/browse/FW-2010) [1]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L167-L170 [2]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/create-custom-element.ts#L164 [3]: https://github.com/angular/angular/blob/c0143cb2abdd172de1b95fd1d2c4cfc738640e28/packages/elements/src/component-factory-strategy.ts#L158 [4]: https://github.com/remackgeek/elements-zone-strategy/blob/f1b6699495a8c0909dbbfbdca12770ecca843e15/projects/elements-zone-strategy/src/lib/element-zone-strategy.ts Fixes #36141 PR Close #37570
2020-06-13 08:06:35 +00:00
this.dispatchEvent(customEvent);
});
}
}
// Add getters and setters to the prototype for each property input.
inputs.forEach(({propName, transform}) => {
Object.defineProperty(NgElementImpl.prototype, propName, {
get(): any {
return this.ngElementStrategy.getInputValue(propName);
},
set(newValue: any): void {
this.ngElementStrategy.setInputValue(propName, newValue, transform);
},
configurable: true,
enumerable: true,
});
});
return NgElementImpl as any as NgElementConstructor<P>;
}