Signal Access

Motivation

All Web Components that want a public interface for their signals need to expose them in one way or the other through properties or methods on the custom element. This is generally preferable to the attribute interface as properties and arguments can be any type, while attributes are always strings. This is therefore very common and also good practice. It is further required internally for sharing signals across lifecycle callbacks.

Current Implementation

To get the current value of a signal:

component.get('value')

To set an initial or updated value of a signal:

component.set('value', value)

To check whether a signal has been defined:

component.has('value')

To remove a signal and its registered observers:

component.delete('value')

To retrieve the signal variable:

component.signal('value')

Comparison to Native Alternative

Without a common implementation in the UIElement base class application developers would likely implement one of the following options:

• A pair of getter/setter for each signal, effectively making them reactive properties
• Custom methods to get and set each signal, leading to many additional methods with no clear naming schema across components
• An object property on the component for a collection of signals
• A Map property on the component for a collection of signals
• A Proxy property on the component for a collection of signals
• Any mixture of the above

The likely outcome of various different interfaces for the same feature on components by different authors is something we try to avoid. This would lead to confusion and frustration on the side of developers who use Web Components built with UIElement.

Besides that, the namespace of properties and methods on HTMLElement is already quite crowded, so component developers will have to choose a less optimal property key in some cases to avoid conflicts with existing properties.

Conclusion: The Map-like interface for signals on UIElement components creates a common denominator component authors and users can rely on.

API Design Considerations

• Developers should not have to implement a custom public interface for signals
• The API should feel familiar to use in the JavaScript context
• Developers should not have to worry about collisions with other keys in the same namespace or reserved words
• The API to access signals should be different to normal property accessors in JavaScript as signals behave differently
• The API should not block type inference in TypeScript