[Complete] Sub-RFC 3: Signal-based Components

[jelbourn]

Sub-RFC 3: Signal-based Components

Changelog

April 10, 2023

• Added section on effects and change detection, explaining the timing of effects relative to the change detection process.
• Added section on afterRender & other functions describing them as application hooks, not component lifecycle hooks.
• Reworked section on component lifecycle hooks to align with new direction: signal components have ngOnInit and ngOnDestroy only, and other hooks replaced by signal functionality.

Introduction

This discussion covers the API of signal-based components.

Note: this document applies to both components and directives. However, repeating "components and directives" is rather cumbersome, so for brevity we just say "components" everywhere.

Signal-based components

Components are the primary building block of an Angular application. As such, they make a natural boundary for participation in the signal-based reactivity model.

You can mark a component as a signal-based component by setting signals: true in the component metadata:

@Component({
  signals: true,
  ...
})

This setting controls a number of framework behaviors outlined in the rest of this document.

We'll refer to components with signals: false as zone-based components.

You can use both signal-based components and zone-based components in a single application.

Signal-based components cannot extend zone-based components or the other way around.

_Note: we know setting both signals: true and standalone: true is kind of boilerplate-y. We're still thinking of ways to make this more concise.

Using a signal in a component

Let's take a look at a counter component that uses signals:

@Component({
  signals: true,
  selector: 'simple-counter',
  template: `
  <!-- count is invoked as a getter! -->
  <p>Count {{ count() }}</p>
  <button (click)="increment()">Increment count</button>`,
})
export class SimpleCounter {
  count = signal(0); // WritableSignal<number>

  increment() {
    this.count.update(c => c + 1);
  }
}

You always call the signal getter to retrieve the signal's value.

Isn't calling a function in a template slow?

Angular developers have learned over the years to avoid calling functions inside templates because the function re-runs on every change detection. This idea no longer applies in a signal-based component because the expressions will only re-evaluate as a result of a signal dependency changing.

Could Angular automatically "unwrap" signal values?

You might be wondering if Angular instead could support binding to a signal directly, implicitly reading the signal's value. In the example above, that would change the binding to count to <p>{{count}}</p>. This would be similar to the way Vue or Preact automatically unwrap the value in templates.

Angular cannot automatically unwrap signal values like this for a couple of reasons:

• A component may want to bind or accept a signal as a value rather than always reading a signal's contained value.
• Angular compiles templates to JavaScript code at compile-time. However, the tracking mechanism inside signals operates entirely at run-time. As such, developers can deeply nest a signal read inside a function call. For example:

<p>{{ someObject.someMethod().someProperty }}</p>

class SomeObject {
  items = signal(['a', 'b', 'c']);

  someMethod(): string {
    return this.items()[0].toUpperCase();
  }
}

Here, Angular cannot statically know (at compile-time) that the template expression accesses a signal getter.

Further, explicitly calling the signal getter in the template makes reading values consistent inside and outside of templates.

We know that this is a departure from Angular today that may feel strange for some people, but we've found in our early user studies that developers internalize the concept and it becomes familiar relatively quickly.

Reading non-signal values in templates

Let's look at an example that mixes use of signal and non-signal values in a template:

@Component({
  signals: true,
  selector: 'simple-counter',
  template: `
  <!-- count is invoked as a getter! -->
  <p>Count {{ count() }}</p>
  <p>{{ name }}</p> <!-- Not reactive! -->
  <button (click)="increment()">Increment count</button>`,
})
export class SimpleCounter {
  count = signal(0); // WritableSignal<number>
  name = 'Morgan';

  increment() {
    this.count.update(c => c + 1);
  }
}

This example includes both binding to a signal value (count()) and a plain value (name). Let's say that the name and the value of count were both to change. You might expect that only the changes to count() would be reflected in the rendered DOM, but in this scenario Angular would update both values in the rendered DOM. This happens because Angular still re-checks every binding within the component when one or more signal dependencies change. Only a change to the count would trigger that change detection, however.

This behavior can be surprising- in a signal-based component, you might expect that only bindings that read from signals should ever update.

In the signal-based component world, this behavior is a symptom of not embracing the central principle - dynamic state (particularly state referenced from a template) must be tracked within a signal.

We have some ideas on how to help guard against this behavior:

• Raise an error at run-time if a template expression changes without depending on a signal read.
• Raise a compile-time warning or error via the Angular Language Service if you bind to a non-signal value that is not readonly

See "Granularity of change detection" for background on this behavior.

Discussion point 3A: We're actively looking for feedback on the developer experience of this behavior.

Computed properties

You can define computed properties similar to how you define writable signals. Let's look at an example of component that shows a Fahrenheit temperature from a Celsius source:

@Component({
  signals: true,
  selector: 'temperature-calc',
  template: `
    <p>C: {{ celsius() }}</p>
    <p>F: {{ fahrenheit() }}</p>
  `,
})
export class SimpleCounter {
  celsius = signal(25);

  // The computed only re-evaluates if celsius() changes.
  fahrenheit = computed(() => this.celsius() * 1.8 + 32);
}

Computed properties can simplify your code and reduce unnecessary recomputation by replacing:

• Manually updating properties in lifecycle methods
• Function calls in template expressions
• Pure pipes in templates which transform input values when they change

Computed properties are a longstanding feature request for Angular.

Signal-based inputs

In signal-based components, all component inputs are signals. Let's look at an example of declaring some signal-based inputs:

@Component({
  signals: true,
  selector: 'user-profile',
  template: `
    <p>Name: {{ firstName() }} {{ lastName() }}</p>
    <p>Account suspended: {{ suspended() }}</p>
  `,
})
export class UserProfile {
  // Create an optional input without an initial value.
  firstName = input<string>(); // Signal<string|undefined>

  // Create an input with a default value
  lastName = input('Smith'); // Signal<string>

  // Create an input with options.
  suspended = input<boolean>(false, {
    alias: 'disabled',
  }); // Signal<boolean>
}

Here, the input function replaces the @Input decorator as the means of declaring a component input.

input accepts two parameters:

• An initial value, similar to signal, and
• An options object

input returns a read-only Signal. Reading the value from an input always returns the up-to-date bound value.

To a consumer of the component, signal-based inputs are indistinguishable from non-signal inputs, using the same syntax for binding. Whether or not an input is signal-based is an implementation detail of the receiving component.

Model inputs

Signal-based components additionally have access to a new type of input, model inputs.

@Component({
  signals: true,
  selector: 'some-checkbox',
  template: `
    <p>Checked: {{ checked() }}</p>
    <button (click)="toggle()">Toggle</button>
  `,
})
export class SomeCheckbox {
  // Create a model, which is a *writable* signal that supports two-way binding.
  checked = model(false);

  toggle() {
    // Normal inputs are read-only, but a model is writable
    // and propagates the value back to the parent.
    checked.update(c => !c);
  }
}

@Component({
  signals: true,
  selector: 'some-page',
  template: `
    <!-- Note that the getter is *not* called here, the raw signal is passed -->
    <some-checkbox [(checked)]="isAdmin" />
  `,
})
export class SomePage {
  isAdmin = signal(false);
}

The model function defines a special kind of input that establishes a contract between parent component and child component. A model input gives you a WritableSignal, which propagates its value back to the source. This lets you create two-way bindings without any additional requirements.

When using two-way binding, the binding accepts a WritableSignal reference and not the unwrapped signal value. By passing the signal reference instead of the value, you're explicitly opting into the contract that the child component can write values into your signal. We see this pattern as additionally illustrating, by contrast, the value of explicitly invoking the signal getting for one-way bindings.

One-way binding behavior

You can create one-way bindings on model inputs just like the standard input. Modifying the

example above:

@Component({
  signals: true,
  selector: 'some-page',
  template: `
    <some-checkbox [checked]="isAdmin()" />
  `,
})
export class SomePage {
  isAdmin = signal(false);
}

In this situation, the SomeCheckBox component declares a model called checked and can still change its values, but the values it writes will not propagate back to the parent (SomePage). If the bound value from the parent component (SomePage) changes, it will overwrite the model's value. The model value (checked) will always reflect the most recently set value. This matches the current behavior of Angular inputs.

Two-way-binding syntax

This RFC uses Angular's existing banana-in-a-box syntax, [(propertyName)] syntax for two-way bindings. This syntax originally came about as a shorthand for both a property binding and an event binding. For example, the following two are equivalent:

<my-control [(value)]="something" />

<!-- is equivalent to -->
<my-control [value]="something" (valueChange)="something = $event" />

However, in signal-based components, this original thinking doesn't exactly apply; the two-way binding does not literally map to an event handler. Instead, the value propagates back up when the component sets a value into the model property. Because of this, it might make sense to use an alternate syntax for two-way binding in signal-based components.

Discussion point 3B: Should signal-based components introduce a new syntax for two-way bindings?

Inputs are read-only

In signal-based components, inputs are read-only inside the component that receives them. This is a departure from Angular's current approach, where inputs are mutable everywhere. We believe that making inputs read-only will lead to cleaner, easier-to-follow code. The input signal's value always reflects the most recent value bound into the component from outside.

When adapting existing Angular components to a signals world, model provides a way to preserve the original behavior.

Discussion point 3C: We recognize that making inputs read-only is a significant change that may make adopting signals more difficult for existing projects. While we believe that this decision produces the best outcome, it may be too different. We want your feedback on how disruptive this change would be.

Input configuration

Inputs take an options object, which allows specifying the initial value of the input when not bound, the alias, whether the input is required, etc.

user = input<User>({
  initialValue: {username: 'unknown'},
  alias: 'currentUser',
});

Many inputs have primitive values (boolean, number, string, etc). There is an alternate syntax available which uses the first argument for the initial value:

isLoggedIn = input(true);
isAllPowerful = input(false, {alias: 'isAdmin'});

These are equivalent to the longer forms which use the initialValue option:

isLoggedIn = input({initialValue: true});
isAllPowerful = input({initialValue: false, alias: 'isAdmin'});

Discussion point 3D: We're interested in hearing opinions on the developer experience of this API.

Why no decorator?

See "Decorators in signal-based components" below.

input and model have special meaning to Angular

See "Special functions in signal-based APIs" below.

Signal-based queries

Angular queries include the APIs ViewChild, ContentChild, ViewChildren, and ContentChildren.

In signal-based components, all queries produce signals. Let's look at an example of declaring some signal-based queries:

@Component({
  signals: true,
  selector: 'form-field',
  template: `
    <field-icon *ngFor="let icon of icons()"> {{ icon }} </field-icon>
    <div class="focus-outline">
      <input #field>
    </div>
  `
})
export class FormField {
  icons = viewChildren(FieldIcon); // Signal<FieldIcon[]>
  input = viewChild<ElementRef>('field'); // Signal<ElementRef>

  someEventHandler() {
    this.input().nativeElement.focus();
  }
}

Queries work the same way as before in signal-based components with one exception: they always return a Signal. This applies to both singular (child) and plural (children) queries. This has the side effect of eliminating the QueryList API in signal-based components.

Why no decorator?

See "Decorators in signal-based components" below.

Query functions have special meaning to Angular

See "Special functions in signal-based APIs" below.

Output in signal-based components

Adopting signals as a reactivity primitive in Angular does not inherently affect component outputs. However, we believe that maintaining consistency between the API for inputs and outputs is important. Let's look at the proposed output API for signal-based components:

@Component({
  signals: true,
  selector: 'simple-counter',
  template: `
    <button (click)="save()">Save count</button>
    <button (click)="reset()">Reset count</button>
  `,
})
export class SimpleCounter {
  saved = output<number>(); // EventEmitter<number>
  cleared = output<number>({alias: 'reset'});
  
  save() {
    this.saved.emit(123);
  }
  
  reset() {
    this.cleared.emit(456);
  }
}

Aside from the change in declaration API, output behavior remains unchanged.

Why no decorator?

See "Decorators in signal-based components" below.

output has special meaning to Angular

See "Special functions in signal-based APIs" below.

effects and Change Detection

effects allow for the execution of side effects when dependent signals change. Although effects are usable throughout the application, their close coupling with the change detection operation has several implications on component & directive authoring.

Effects wait for inputs to be set

When an effect is created during the construction of a component, that effect will not execute until that component's inputs are available. This guarantee means that effects can be written which depend on component inputs without having to guard against early execution.

Effects run during zone change detection

As Angular is traversing the component tree during change detection, any effects which are queued will be eagerly flushed.

Effects can become dirty during change detection if they observe a signal input which is bound in a zone component. That input isn't change detected until the parent zone component is processed, making the effect dirty.

It's important that the effect is flushed eagerly, as it might affect future rendering of that component. For example it might create or destroy views (such as a reactive form of NgIf might do).

Risk of ExpressionChangedAfterItHasBeenChecked errors

Because effects flush during change detection, they behave similarly to other lifecycle hooks (e.g. ngOnInit) with respect to application data flow. That is, using an effect which reads component inputs and further modifies application state may result in ExpressionChangedAfterItHasBeenChecked errors in other parts of the application, if the modified state is read in components which have already been change detected.

Therefore, caution should be used when authoring effects which set other signals and change application state. This includes converting signals to Observables via toObservable, as this exposes the effect timing via the Observable.

This issue only exists when interleaving signal and zone components. In a fully signal-based application, effects cannot become dirty during change detection, eliminating this risk.

Application rendering lifecycle

To supplement signal components, we're introducing three new application-level lifecycle hooks focused on running code after Angular performs any rendering operations. These are:

afterNextRender

function afterNextRender(fn: () => void): void;

afterNextRender schedules a function to execute after the next rendering operation (that is, change detection cycle) is complete. This is useful whenever you want to read or write from the DOM manually.

Delaying DOM reads until after the framework has finished writing to the DOM during rendering is essential to avoiding unnecessary reflows.

@Component({
  template: `
    <p #p>{{ longText() }}</p>
  `,
})
export class AfterRenderCmp {
  constructor() {
    afterNextRender(() => {
      console.log('text height: ' + p().nativeElement.scrollHeight);
    })
  }
  
  p = viewQuery('p');
}

You can use afterNextRender in any injection context, including components, directives, or services.

afterRender

function afterRender(fn: () => void): {destroy(): void};

afterRender schedules a function to be executed after any time the framework performs DOM updates during rendering.

You can use afterRender in any injection context, including components, directives, or services.

afterRenderEffect

function afterRenderEffect(fn: () => void): {destroy(): void};

afterRenderEffect is a special kind of effect which, when triggered, executes with afterRender timing.

Component lifecycle and effects

Zone-based components support eight different lifecycle methods that let you hook into different stages of Angular's change detection. Because many of these methods are tightly coupled to Angular current change detection model, they don't make sense for signal-based components.

Signal-based components will retain the following lifecycle methods:

• ngOnInit
• ngOnDestroy

The remaining lifecycle methods will not be available in signal components. For all of these methods, signals provide new patterns to achieve the same use cases:

• ngOnChanges - is used to observe changes to inputs. As inputs are signal-based, computed can be used to derive new values, or effect to react side-effectfully.
• ngDoCheck - typically this hook was used to implement custom change detection. effect is a likely (and more performant) replacement.
• ngAfterViewInit is often used to perform some action after initial rendering. afterNextRender can be used instead (and is more correct).
• ngAfterContentInit, ngAfterViewChecked and ngAfterContentChecked are often used to observe query results. Since queries are also signal-based and therefore reactive by default, signals can be used directly.

Decorators in signal-based components

You might have noticed a pattern in the APIs presented in this RFC: signal-based components don't use any member decorators.

Decorators have long been a hallmark of Angular's authoring experience. For inputs and queries inside signal-based components, we believe that the proposed function-based APIs produce the best overall developer experience.

Let's use input to illustrate our thought process.

Each input needs to create a Signal instance to contain its value at construction time. Imagine a theoretical API where this happens with decorators:

class UserProfile {
  @Input() isAdmin = createInputSignal(false);
}

We find this API unappealing because it introduces significantly more boilerplate for declaring inputs. You might ask "Can Angular automatically create the signal behind the scenes?" Let's imagine another such API:

class UserProfile {
  @Input({defaultValue: false}) isAdmin!: Signal<boolean>;
}

We find this API unappealing because:

• It relies on the Angular compiler to initialize the input, which is confusingly magical for any developer that isn't already familiar with Angular.
• It requires the non-null assertion operator, which is easy to forget and potentially confusing for new developers.
• It introduces more boilerplate by requiring both the decorator and the explicit Signal type.

This leads us back to the proposed API:

class UserProfile {
  isAdmin = input(false);
}

We find this API appealing because:

• It's concise.
• The type is inferred naturally without any compiler magic.
• It satisfies TypeScript's strictPropertyInitialization setting.

Above we discussed @Input, @Output, and all the query decorators. This leaves @HostBinding and @HostListener, which we further propose dropping in signal-based components. Because input, output, and the query functions provide a much cleaner, more concise API, dropping @HostBinding and @HostListener results in a consistent authoring experience.

Special functions in signal-based APIs

Today, Angular processes decorators like @Input at compile-time. Your run-time JavaScript bundle does not actually include any decorators. The new signal-based function APIs behave the same way- Angular will process input, output, viewChild, etc. at compile-time to statically understand the declarations.

This means that you can't use these APIs as typical functions throughout your code. For example, you cannot create a custom booleanFlag that calls input:

function booleanFlag(config) {
  // The Angular compiler won't accept this.
  return input(false, config);
}

Instead, you can exclusively use these APIs as part of a component property initializer. Angular will report an error if these functions are used in any other context.

Why not ChangeDetectionStrategy.Signals?

Longtime Angular developers might ask here, "Why not ChangeDetectionStrategy.Signals?" We considered this option, but decided on a separate API for two reasons:

• Opting into signals affects a much wider range of behaviors than change detection alone.
• Directives don't currently support the changeDetection setting. Adding this setting to directives would be confusing, since directives participate in change detection based on the view in which they're contained. However, directives are affected by other aspects of participation in the signal reactivity system.

Signal-based components completely drop the changeDetection setting.

Will there be lint warnings or compiler checks for common anti-patterns with signals?

Yes! We're still exploring what kinds of checks we'll be able to implement, but some early ideas include:

• Ensuring that inputs/outputs/other signal properties are readonly (the value inside the signals should change, not the identity of the signal itself)
• Depending on non-readonly, non-signal values in component templates
• Performing mutable operations or other side effects inside computed computation functions

[kzagoris]

For input decorators, why, not this syntax:

@Input() isAdmin = signal(false)

It defines an input signal; you do not need different keywords/functions.
We love the decorators in Angular :)

[alxhub]

Good question! The short answer is: because inputs are not signal()s.

signal() constructs a WritableSignal - a signal that you can set the value of. Inputs are different in at least two ways:

• you don't have control over their value - the component binding to the input does
• bindings in signal components to signal inputs work like computed properties - you're specifying the expression of the input, not its value. you can think of this as [isAdmin]="user().roles.includes('admin')" behaving as if the input property was initialized to the signal computed(() => user().roles.includes('admin')).

So we can't initialize inputs to WritableSignals via signal() - they're a special kind of thing, and so we would need some kind of inputSignal() initializer. That brings us back to the argument in the RFC that the decorator is redundant at that point.

[simonmumenthaler]

There is actually an advantage to getting rid of the Input()/Output() decorators: Type Safety

For example the ComponentRef<T> would benefit from this:

When dynamically instantiating a Component with createComponent from @angular/core it's not unusual to then "manually" set one or several "inputs" on the returned ComponentRef#instance. Recently the ComponentRef#setInput method was introduced but is weakly typed with setInput(name: string, value: unknown).

As Inputs/Models will be typed as such, it becomes possible to use strong typings for this method (as the "type" and basically even "required" information is actually reachable in contrast to the today's decorator based inputs).

[Harpush]

@simonmumenthaler That's actually really good. Branding should be applied here and then a fully typed version can exist.

[mfp22]

I don't think I'll ever get used to this:

user = input<User>({
  initialValue: {username: 'unknown'}
});

If options could always be the 2nd argument, instead of this:

info = input({ required: true })
selectedItem = input<Item>(
  { initialValue: defaultItem },
  { required: true },
})

It could be

info = input(undefined, { required: true })
selectedItem = input<Item>(defaultItem, { required: true })

The undefined version would have less boilerplate and more consistency.

Actually, if you don't define an initialValue, what value will the template initially receive? Will it be undefined? That's what I was assuming in this comment. Or will it receive the value from the parent from the very first call? In that case, it might be relatively rare to have to define an initial value.

Also, is there anything preventing me from wrapping input with my own requireInput function that only takes in an initial value?

[yjaaidi]

I think that the function overload or alternate syntax here is confusing.
A single signature: input(options: Options) is way enough.

[tomalaforge]

it means: if there is not default value, the input must be required=true. isn't it?

[yjaaidi]

Either required: true or maybe the initial value could default to undefined but I don't think that this would happen due to:

The afterInit callback runs after Angular has created the component and applied the initial values to all inputs. Attempting to read an input signal before this point may result in an error.

but I still wonder if this means that the error will happen if inputs in general or just required inputs are not initialized yet.

[alxhub]

My take: it should be all inputs. Before afterInit, reading an input signal would return an error - inputs are not yet available.

After initialization, reading an input should return the value the user provided (if they provided one), or the default value (if the input is not required).

That is, for inputs you have to decide if the consumer has to provide a value. If not, you must provide a default/fallback value. But in either case, the inputs are not available until afterInit.

[yjaaidi]

Totally agreed! All inputs should throw before afterInit even if they have default value for consistency's sake.

[jnizet]

Food for thought regarding discussion point 3D.

Given that passing options should not be frequent (in my experience, aliasing inputs is not used often, and I haven't seen any other option described here), an fluent API could be used

  person = input({ name: '' }).withOptions({ alias: 'user' })

or even

  person = input({ name: '' }).aliasedAs('user')

Pros:

• the syntax for setting the initial value is the same whether the initial value is an object or not

Cons:

• fluent APIs are not so frequent in Angular, although existing, such as HttpParams and HttpHeaders.
• ?

[tomalaforge]

really like the fluent API proposed above.
as, isRequired

and saying that because it is not very frequent in Angular should stop from implementing, is not a valid argument. The api will change drastically with signal so that's a good time for it.

[ranemloc]

I see too much focus on the initial value of an input. However, shouldn't be the default for inputs (i.e. you expect a value to be passed from the outside) to NOT take an initial value from within the component that declares it?

IMHO the ideal way to declare an input would be userId = input<number>(), i.e. there is no initial value, and I do not have to deal with awkward undefined or false initial values (e.g. 0) down the reactive chain.

It might require me to wrap a signal with an *ngIf in the template, but that's Ok. I do not want to render anything anyways until I've been passed values for my inputs.

[nartc]

@ranemloc there are plenty of use-cases to have initial value for Inputs. Eg: DataList view mode (horizontal, vertical). Most reusuable components have some sort of default values for inputs to allow customizations, if needed.

[gioragutt]

The problem with the fluent api, like any other builder-style api, is that at some point you need to stop the "chain". Using the example above (input(defaultValueOrUndefined).withOptions(optsObject)), If you don't provide .withOptions, you're still left with a value that has a withOptions which can be called later in the code. It's not something you'd want people to do, but it will be in type of the variable so people will be people and end up calling it not as intended.

IMO, the signature of input should be:

function input<T>(): Signal<T | undefined>;
function input<T>(defaultValue: T, options?: Options): Signal<T>;

And if required means that it'll always have a value (which is not the case, you can't prevent it from being called before all inputs are set), you can add another overload:

function input<T>(
	defaultValue: T | undefined,
	options: Options & {required: true},
): Signal<Exclude<T, undefined>>;

[nthonymiller]

@gioragutt I do agree with you dot chaining makes it difficult to know what ends the chain and restricts extensibility. Having said this, I do like the below syntax as it avoids this, however it is more verbose than the original signal syntax.

input<number>(undefined, withAlias('userId')); // Signal<number | undefined>
input<User>({name: 'angular'}, withRequired()); // Signal<User>

[rlmestre]

This is probably outside the scope of this RFC, but: given the new function APIs would also be analyzed at compilation time, could a similar (or identical) API be introduced for non-Signal-based Components? (Replacing decorators)

[alxhub]

Yes, in theory. It couldn't be input() because that will have a return type which is fundamentally tied to signals.

In practice, I think it would be a lot of unnecessary churn.

[rlmestre]

Are there other alternatives being considered for @HostBinding/@HostListener aside from @Component.host? That config's getting pretty crowded 😅

[jelbourn]

Not in the short term, but longer term it would be something we'd consider revisiting in Angular's authoring experience.

[PavelYemelyanau]

Will @HostBinding work in pair with input?

Example:
@HostBinding('class') type = input('test')

[jelbourn]

Not based on this current proposal- this is a bit buried at the bottom, but signal-based components wouldn't support @HostBinding and @HostListener (in favor of the host API in the component decorator). The timing for this is due to signal-based components dropping all of the other class member decorators, but for full transparency I've seen these APIs as anti-patterns for some time. Based on my own experience:

• For complex components, the host property is much easier to quickly parse. CSS classes, ARIA
  attributes, and event handlers can be grouped, making it easy to understand the state space of the
  host element.
• @HostListener doesn't allow expressions, which encourages developers to create unnecessary
  one-line methods.
• @HostBinding doesn't allow for static values (e.g. role and tabindex), leading developers to
  create superfluous bindings.
• Member decorators only exist inside classes. If Angular were to hypothetically consider alternate
  authoring formats in the future, these decorators would need to be replaced.

[rubiesonthesky]

Maybe Angular style guide should be revisited, because it recommends not using host https://angular.io/guide/styleguide#hostlistenerhostbinding-decorators-versus-host-metadata

I think it will be little bit confusing that you suddenly need to use the discouraged way, so it would be better if the style guide would be updated before Signals land. (If possible)

There is also angular eslint rule for that which also recommends not using host https://github.com/angular-eslint/angular-eslint/blob/main/packages/eslint-plugin/docs/rules/no-host-metadata-property.md (Which is of course external tool, but would be good for ecosystem to have it updated too)

[gioragutt]

@jelbourn aren't hostListener(...) / hostBinding(...) possible?

I do agree with the first bullet (about grouping and colocation of such attributes), but just for the sake of technicality.

[jelbourn]

Maybe Angular style guide should be revisited, because it recommends not using host

Yeah, we know that the style guide is long overdue for an overhaul. We're planning to use the introduction of signals as an opportunity to revisit that doc and update it to our current thinking.

[jelbourn]

@jelbourn aren't hostListener(...) / hostBinding(...) possible?

We could certainly look at alternate APIs, but with the current authoring format it's hard to justify investing time to come up with yet another way of declaring host bindings instead of rolling with the one we already have. In general we try to make sure there's only one way of doing things.

[e-oz]

Discussion point 3A

It's quite surprising to see that we'll need signals: true, and it's not a nice surprise.
After reading all the changes about lifecycle methods I see why you want to do this, but it also means that signals can not be gently introduced into the existing components, and it means that it's not quite an opt-in change. If you want to use signals or signals-based change detection, you'll have to write a new component, not modify an existing one (because you'll need new inputs, new outputs, new everything).

Because these methods are tightly coupled to Angular current change detection model, they don't make sense for signal-based components.

It should be defined by a changeDetection strategy then, not by the signals flag.

Opting into signals affects a much wider range of behaviors than change detection alone

Looks like it only changes the lifecycle and change detection.

Discussion point 3C

Please leave them readonly. It's a very important and right change.

Discussion point 3D

When using objects as initial values, a longer form must be used

Sorry for the strong word, but it's awful.

We find this API unappealing because it introduces significantly more boilerplate for declaring

It is such a weak argument. You are breaking compatibility just for this? That's depressing...

Yeah, it's the most frustrating sub-RFC, sorry that I can not stay positive - I still hope my opinion will somehow help...

[tomalaforge]

I think CheckAlways is the Default strategy.

And I agree with you that adding a new flag is cumbersome, you still need to find a way to separate your signal-base component from zone-based one to take full advantage of the fined graine reactivity.

One question: if you are starting a new app or going full signal, will it not be possible to set the flag inside the bootstapApplication function. (same for standalone flag) instead of putting it inside every component. A signal-CD mode should be possible ?

[jgbpercy]

Is gradually introducing signals into a component really very desirable? I feel like I can count on one hand the number of components across several apps I work on that are big and complex enough to warrant that... And I'm not against big, complex components when they're needed, as some people are.

Feels like the component is a reasonable unit for which to add signals or convert existing functionality to use them, honestly.

Fair enough, in complex apps people are going to have signal state coming from services that might be consumed by multiple components, some of which might be signals: true and some not, didn't really think that through. I still feel like in our apps the vast majority of components are going to be signals: true or no signals, but maybe I'm wrong, and others are going to do differently (and it seems like that will work fine).

[e-oz]

@jgbpercy I can use just one finger (not that one 😉): I would like to convert observables in templates for a better change detection mechanism. Not per-view, but still, not zonejs-based.

[atscott]

Is gradually introducing signals into a component really very desirable? I feel like I can count on one hand the number of components across several apps I work on that are big and complex enough to warrant that... And I'm not against big, complex components when they're needed, as some people are.

Feels like the component is a reasonable unit for which to add signals or convert existing functionality to use them, honestly.

Certainly, but making signal reads work correctly for existing components is still important. If it weren't possible to read signals in an OnPush or Default component, you'd not be able to update any state in services to be signals until you were ready to also take on migrating the components that read state as well.

[atscott]

One question: if you are starting a new app or going full signal, will it not be possible to set the flag inside the bootstapApplication function. (same for standalone flag) instead of putting it inside every component.

We will be working on a way to set the global configuration to be "all signals". This would probably be at the compiler level and would throw an error if it encounters a non-signal component.

A signal-CD mode should be possible ?

Yes, we would be able to remove the existing top-down change detection in this case. We can rethink our change detection strategy completely when all we need to do is update a set of signal views.

[rlmestre]

_Note: we know setting both signals: true and standalone: true is kind of boilerplate-y. We're still thinking of ways to make this more concise.

Are there reasons signals: true shouldn't opt into standalone: true by default?

[alxhub]

They're unrelated options, so it's possible to have a signals: true but standalone: false component.

This gets at a larger question though: "if Angular does change X and then change Y, should we make you update to do X first before you can use Y?" Doing so adds considerable friction to updating, but also minimizes the number of "states" you can be in and the syntactic overhead.

Thus far our answer has been "no" - we try not to couple features together when it's not technically necessary. We believe the friction this would add to people updating defeats the benefits.

As @jelbourn wrote, we do see having to declare both signals and standalone flags as overly boilerplate-y, and that's a problem we want to solve in a much more general way.

[ranemloc]

Have you though on new decorators? Stupid idea: @ComponentV16({}) which translates to @Component({standalone: true, signals: true}).
You could publish a new decorator with each major version that reflect the last trends on Angular and let application authors adopt these at their own pace and will.
A big drawback is that important information (standalone, signals) gets hidden behind a number (v16). It could also lead to annoying situations in large codebases where refactoring takes long, and you might have in the same repository a mix of versions (v16, v17, v18...). After a while, not even the most veteran developers will remember what these numbers mean.

[alxhub]

We could do @NewComponent, then @NewNewComponent, etc. :)

Yep, you're thinking about this along the same lines we are. I think version number is a poor identifier - ideally we won't be introducing multiple new component types per year 😄 so having a number that increments regularly just adds to the confusion.

I particularly like how Rust solves this problem with editions.

[ShawnTalbert]

They're unrelated options, so it's possible to have a signals: true but standalone: false component.

This gets at a larger question though: "if Angular does change X and then change Y, should we make you update to do X first before you can use Y?" Doing so adds considerable friction to updating, but also minimizes the number of "states" you can be in and the syntactic overhead.

Thus far our answer has been "no" - we try not to couple features together when it's not technically necessary. We believe the friction this would add to people updating defeats the benefits.

As @jelbourn wrote, we do see having to declare both signals and standalone flags as overly boilerplate-y, and that's a problem we want to solve in a much more general way.

I'm not impressed with standalone components so far, so I would absolutely NOT want those technically unrelated features coupled together.

[jnizet]

If inputs are read-only signals, how can we set their value programmatically

• in pure unit tests
• when using directive composition

Would it be possible to inject DirectiveRef, which would wrap the directive instance and allow setting it's inputs?

Speaking of directive composition, can a zone-based directive host a signal-based one, and vice-versa?

And regarding queries, is the ElementRef still necessary?

[yjaaidi]

I don't think that there will be signal-based vs. zone-based directives. The distinction is only for components.

[jnizet]

That's not what this RFC is saying.

[yjaaidi]

Oh! You're right! Except the input/outputs and lifecycle hooks, I wonder how their behavior will defer 🤔

[alxhub]

A component's inputs are set by its consumer, the thing that created it.

For a component declared in a parent component's template, the value of those inputs are determined by the bindings the parent makes to them.

When you create a component "dynamically" (e.g. with ViewContainerRef.createComponent) then you "control" the component and its inputs via its ComponentRef. ComponentRef has .setInput to update the values for inputs of that component.

In tests, ComponentFixture exposes the .componentRef so you can use .setInput to test the component by manipulating its inputs. All of this works today, and will work with signal components too.

[yjaaidi]

But as mentioned by @jnizet, what about directives that want to programmatically set a host directive's input?

[yjaaidi]

What happens if lifecycle hooks are called outside the constructor?

Will they throw an error if there is no injection context?

Will the injection context be provided in methods when called as output or DOM event handlers?

[alxhub]

What happens if lifecycle hooks are called outside the constructor?

Depends on the hook. Most of them will probably just require an injection context (e.g. afterNextRender). Obviously afterInit needs to be established before initialization.

Will the injection context be provided in methods when called as output or DOM event handlers?

We haven't thought it through yet - something to talk about. I like the idea in principle, but I'm concerned that injection context is inherently "leaky" - if you call a root service from your event handler, that service method is also running in the component's injection context, which might cause strange behavior. I could see people being really confused when things work in some contexts and not others.

Injection context is a powerful tool and helps us keep the component APIs really clean, but it's also hidden global state with a bunch of downsides, and we need to be mindful of that fact.

[yjaaidi]

What happens if a signal-based component implements old method lifecycle hooks (e.g. ngOnDestroy)?

will there be a compilation error?

[alxhub]

Yep :)

[tomalaforge]

why not using the current lifecycle hook synthax?

[yjaaidi]

Concerningafter*Render*

For all of these APIs, the DOM in question is not tied to the component in which the callback is registered. Instead, the callbacks run based on when any DOM has been updated by Angular.

I am a bit petrified 😅

How can we name this to let people know that afterRender() might be called way more times than one might assume?
I think that it deserves a more explicit name.

Also, we might want to opt-out from all DOM updates and just focus on the component itself... how can we achieve this without afterRenderEffect() in case we don't want to list all our signals in it.

[elmarbeckmann]

Agree, afterRender() implies (to me, somehow) that it is only run once after. I would make it more explicit. Like afterEachRender(), which also makes it useful to have something like afterFirstRender() ... etc.

[garrettld]

My gut reaction was that the initialValue thing was gross, as others have mentioned, but after playing with it for a bit I think it's fine, even preferable. 90% of the time that I'm dealing with objects I don't have a default/initial object anyway, and this syntax is cleaner in that common case, and it's cleaner for required primitive inputs with no initial value, too.

I know the components team uses @Component.host over @HostThing, but I'm surprised that this RFC doesn't propose hostBinding/hostListener functions. I think it should at least be updated to clarify that the guidance is to use @Component.host instead, I had to double check the RFC to make sure I hadn't missed something.

Finally, I'm confused by the timing of the rendering effects. They run after any DOM has been updated, not just the component's DOM? I think some examples would be helpful, I'm struggling to understand when I'd want to respond to other potentially unrelated components being rendered.

[alxhub]

Hey, thanks for the feedback :)

I know the components team uses @Component.host over @HostThing, but I'm surprised that this RFC doesn't propose hostBinding/hostListener functions.

We discussed it, and @jelbourn can elaborate on why @Component.host is the preferred option, but we felt strongly enough about that direction to not want to introduce new operations.

Finally, I'm confused by the timing of the rendering effects. They run after any DOM has been updated, not just the component's DOM? I think some examples would be helpful, I'm struggling to understand when I'd want to respond to other potentially unrelated components being rendered.

A major use for "after rendering" timing is to read styling or layout information from the DOM. You really, really want to do this after all DOM updates have finished, since it will force the browser to run its layout process for the page. If the DOM is mutated again after this, it invalidates that layout work. We've found that components/directives doing such operations in ngAfterViewChecked callbacks, for example, are a source of performance problems in real applications we've profiled. So waiting until the framework has finished rendering is the right timing, even if you only care about the current component's DOM.

Then there's the question of how often it should run. There's a whole spectrum of options here:

• Always, after every rendering
• Only after anything in the current view tree has written to the DOM (the whole component + all its children)
• Only after any of the views in the current component have written to the DOM
• Only after the root view of the current component has written to the DOM

Then there are questions about like, what do you do with projected content? Transplanted <ng-template> views? Host bindings from child components? etc. It turns out to be really complicated to define a set of conditions which captures "the current component changing" that won't have surprising behavior or exclude some use cases. And in fact, via CSS component layout can be affected without ever being updated themselves.

So we feel the current pair of functions offers the best compromise for this complexity. afterRender which runs after any DOM changes and covers most "read from the DOM" use cases, and afterRenderEffect which ties the reaction to a signal updating and covers most "write to the DOM" use cases (under the assumption that you want to keep the signal's value in sync with some DOM property manually).

[derekkite]

The rxjs RFC didn't answer this, so here goes.

The way I use observables goes like this

<mycomponent [myinput]=myobservable | async>

If myinput is a signal input, how would that look? I suppose a default value would be required.

[yg-endava]

Maybe instead of async pipe, we may have to use <mycomponent [myinput]=myobservable.asSignal()> ?

[alxhub]

@derekkite that will work just fine if mycomponent uses signals. It has to, for backwards compatibility.

async pipe's job is to always, synchronously have a value, because (as this example shows) template bindings must always have a value. If the observable hasn't emitted, that value defaults to null.

[antischematic]

This is such a radically different way of writing components, why not just go full hog and make signal-based components as functional components? Is there any real benefit to classes at this point? Makes it easier to distinguish zone-based components from signal-based components too.

export const MyComponent = defineComponent({
  selector: 'my-component',
  setup() {
    const count = input(0)

    return {
      count
    }
  },
  template: `
    <div>{{ count() }}</div>
  `
})

[e-oz]

I don't care about React at all. It's ok that Angular takes some ideas from React. I just don't get why Angular wants to take ideas that even React developers hate (hooks, props, context, functional components).

[e-oz]

But it's not bad.

Mixins are not bad? Well, ask Google “why mixins are anti-pattern” or “why composition over inheritance” - you’ll find interesting things to read.

[bryanrideshark]

@e-oz you can Google support for almost any position. Mixins are used in the Angular Material library as recently as version 13 (and maybe until today, I just haven't checked).

You may not like mixins, but many people do; Host Directives are a form of mixin. The Angular team is going functional composition with this proposal, and if they are, we need to know what to expect with all that that implies.

[e-oz]

@bryanrideshark let's stop arguing, let's just listen to some nice music.

[mikeandtherest]

Are there any arguments other than "I don't like React"?

@bryanrideshark Many of us (senior devs/tech leads/architects etc.) need be able to understand and create applications with more than one FE or BE frameworks. That's in the nature of our job. So it's not about liking Angular and hating React. Each of them is a great tool for a specific need and perspective. And same goes for Vue, Svelte, SolidJs, Qwik, just to name a few.

So it's really not about not liking React, it is about wanting Angular to keep the peculiarities that makes it unique and great for a specific slice of the market.

[ctusch]

Discussion point 3A: We're actively looking for feedback on the developer experience of this behavior.

This happens because Angular still re-checks every binding within the component when one or more signal dependencies change.

Why does Angular do a re-check on all bindings? I would have expected that it only checks the binding of the changed signal.

Regarding DX my first thought was to prohibit binding to non-signal properties. It would be clear and hence quick to learn. But maybe it could also be an option to provide a mutate call for the component where we can change the component's properties and have Angular pick up on it, similar to Signal.mutate. Just a thought.

Discussion point 3B: Should signal-based components introduce a new syntax for two-way bindings?

Yes, because it's not backward compatible and hence could lead to a lot of confusion. Also, upgrading existing components with zone-based two-way binding to signals would lead to a breaking change to consumers. And it could lead to conflicts when having a model "property" and an output "propertyChange".

Discussion point 3C: We recognize that making inputs read-only is a significant change that may make adopting signals more difficult for existing projects. While we believe that this decision produces the best outcome, it may be too different. We want your feedback on how disruptive this change would be.

I agree with your reasoning. It will be a pain to upgrade but worth it for new components.

[alxhub]

Why does Angular do a re-check on all bindings? I would have expected that it only checks the binding of the changed signal.

It depends on the level at which we track signal dependencies. We could absolutely treat each binding as a separate reactive node, and track dependencies individually. See the "Granularity of local change detection" section in #49684 for details.

[mikeandtherest]

@alxhub I've read the part where it is explained what are the possible granularity levels and why the team decided to go with the 'per view reactivity'. However, out of curiosity, is this 100% decided or are there still some chances to reconsider it and go one more level deeper?

I'm asking because from what I know, both qwik and SolidJs are going down to the 'per DOM element' as granularity level, and going forward, I think this would be better also in Angular (I might think at scenarios where we have multiple inputs controls/components, which don't make sense to be grouped under a view, but for which we still want to have independent reactivity). And honestly it's not even about scenarios we can come up with currently, it's actually about things that we can't even foresee that will happen in the next 5+ years. I'd say if we do something now, let's do it in the best possible "future proof" way.

The concerns regarding the expensive computation and memory issues must have been somehow surmounted by the qwik / solidjs teams, so could it be worth giving another look to an even finer grained reactivity in Angular?

[alxhub]

is this 100% decided or are there still some chances to reconsider it and go one more level deeper?

It's not 100% decided - if a strong argument emerged in this RFC for more granular checking, for example, we would consider it. But I do think the bar is high, because view-level checking makes the interop story between zones and signals a lot cleaner.

might think at scenarios where we have multiple inputs controls/components, which don't make sense to be grouped under a view, but for which we still want to have independent reactivity

Note that for signal-signal component bindings, those are reactive at the binding level (they're constructed as computeds) and don't cause the parent view to change detect at all. Only bindings to DOM nodes are checked as part of checking a view.

I'd say if we do something now, let's do it in the best possible "future proof" way.

Ivy's instruction architecture is really amenable to changes like this - we can create different binding instructions that behave differently in the future if we want to. We're not locked into any choices we make today regarding granularity.

[mikeandtherest]

Note that for signal-signal component bindings, those are reactive at the binding level (they're constructed as computeds) and don't cause the parent view to change detect at all. Only bindings to DOM nodes are checked as part of checking a view.

Hmm, I think I'll need to read again the whole thing, because tbh I haven't seen this piece of info mentioned anywhere. But it's great news, nevertheless! :)

Ivy's instruction architecture is really amenable to changes like this - we can create different binding instructions that behave differently in the future if we want to. We're not locked into any choices we make today regarding granularity.

If that's the case, then it's really cool since you can start with view level and refine later if needed. Good to know!

[alxhub]

Hmm, I think I'll need to read again the whole thing, because tbh I haven't seen this piece of info mentioned anywhere.

See "Signal-based inputs as computations" in #49684 :)

[luisfpg]

People are concerned to have multiple ways of doing the same thing. But this is unavoidable for a large project, such as Angular, to remain usable. For example, it took Java 3 interactions to implement a decent date and time API. In Java 1.0 there was java.util.Date. In 1.1 they added java.util.Calendar. Then, only in Java 8, the new java.time package with all its glorious classes.
If Angular would need a next-gen framework to introduce those new approaches, such as standalone components and now signals, the project would fracture itself very badly, with a new project for every new large improvement, and it would be much worst than having both old and new approaches to co-exist in the framework.
I've been using Angular since 2.0, and it is amazing the pace it evolve. Only this week I realized it is possible to inject components with the inject() function (I still thought it was only possible in the constructor).
I hope the project keeps evolving!

[elvisbegovic]

I think we can’t make this comparison. In 2023 Java version we can still use java.util.Date released ~30years ago and that even if java.util.Date has limitations and design issues.

geek mindset: iam researchers and 2y writing same code, oh it is annoying we will experiment other things.
business mindset: it should works for years like COBOL.

I think : if something must change/enhance, it could but only if it is primary based on « migration code » to not waste time on rewriting/updating same code again and again or your code could not be updated to last version in 5y. Question: @alxhub is migration-code considered?

+1 @spierala

[luisfpg]

I think we can’t make this comparison. In 2023 Java version we can still use java.util.Date released ~30years ago and that even if java.util.Date has limitations and design issues.

Yes, but likewise, in 2030, you'll still be able to write Angular zone.js-based components. At least this is the promise the Angular team is doing in these RFC's.

[wxyer]

i think application life hooks should be same pattern like interface onInit,angular is classs code ,not function,i dont like function hook apis

[ajuni880]

I still cannot wrap my head around how signals run the new change detection mechanism to re render the template.
Currently zone.js notifies about events and the change detection is ran but how this happens in signal based component? What makes re run the change detection? Updating the signal? Is the component view added as a consumer of the signal?

[pkozlowski-opensource]

Updating the signal? Is the component view added as a consumer of the signal?

Yes and yes

[ajuni880]

Thanks, do you know where can I find the source code of this behaviour? Where the view is added as consumer

[luisfpg]

After downloading the recently released 16.0.0-rc.0 version, but I found out that @Component( signals: true ) isn't yet supported.
Will this land in the final 16 version?

[jelbourn]

No- the developer preview in v16 is for the main signal primitives (signal, computed, and effect). The rest of the framework-level APIs will come later.

[luisfpg]

Thanks @jelbourn

[DibyodyutiMondal]

Forgive my eagerness, but when you say 'later' do you mean as minor/patch updates to v16 or will it be pushed all the way back to v17?

[alxhub]

We're not committing to any particular release date for signal components or the other APIs. This is a fairly foundational change in Angular, and we want to make sure we get it right. The RFC is one step in a larger process of research, design, validation, and testing.

Very likely, different pieces of this puzzle may land at different times, either in minor releases as new features or in new major version(s) if needed.

[simonmumenthaler]

[antischematic]

Could we do away with directive inheritance in favor of directive composition API?

[simonmumenthaler]

This has nothing to do with the directive composition API. The example was confusing tho. I updated the code.

[alxhub]

// by overriding the `value` member without adding the `Input` decorator it's no longer exposed as input
override value: string

Declared inputs of the base class and the derived class are merged, and there is no concept of a child component "undeclaring" an input from the base class. The input from the base class in your example is still bindable, regardless of the override: https://stackblitz.com/edit/angular-uvancs?file=src%2Fmain.ts

[simonmumenthaler]

@alxhub you're right. didn't know about this one. intelliJ no longer proposes the input in the template when it was overridden without decorator - wrong assumption from my side; sorry

[nthonymiller]

Signal-based inputs

1. Component Input binding and separating the usage of both input (read-only) and model (mutable) Signals in my opinion will lead to confusion in the community, especially the term model as it doesn't clearly describe it's intent. Maybe a more precise way would be setting a property on the option for the input itself.
   Typescript should certainly be able to infer the input functions output type based on it's parameter value.

isLoggedIn = input(false, { mutable: true });

2. Passing the Signal reference rather than the value would this be allow ? Are we passing the Signal refence to the child component or is it to be unwrapped when passed to the child component.

@Component({
  signals: true,
  selector: 'some-checkbox',
  template: `
    <p>Checked: {{ checked() }}</p>
    <button (click)="toggle()">Toggle</button>
  `,
})
export class SomeCheckbox {
  checked = input(false);
}

@Component({
  signals: true,
  selector: 'some-page',
  template: `
    <some-checkbox [checked]="isAdmin" />
  `,
})
export class SomePage {
  isAdmin = signal(false);
}

[GabrielBB]

What about mutableInput over model ?

[e-oz]

RFC already covers point 2 of your question.

[e-oz]

Discussion point 3B: Should signal-based components introduce a new syntax for two-way bindings?

model() is enough, no more magic is needed.

[ashley-hunter]

Perhaps this has been discussed elsewhere already, but is there any way we can coerce the signal inputs?

For example, currently we can do the following:

import { BooleanInput, coerceBooleanProperty } from '@angular/cdk/coercion';

...

  @Input() set selected(value: boolean) {
    this._selected = coerceBooleanProperty(value);
  }

  get selected(): boolean {
    return this._selected;
  }

  private _selected = false;

  static ngAcceptInputType_selected: BooleanInput;

This enables us to support static values in our templates:

<some-cmp selected="true" />

Are there any plans to provide support for this in signal-based components? Maybe the input function could incorporate an option?

selected = input(false, { transform: coerceBooleanProperty });

[Jordan-Hall]

Hopefully this allows to create custom input/output without having to 1 use Angular directly or 2 create complete custom solution.

[dgp1130]

Could you do:

class MyComponent {
  selected = input<boolean>();
  private _selected = computed(() => coerceBooleanProperty(this.selected()));
}

Downside here is that you can't easily "wrap" the coercion in a single symbol, you need both selected and _selected to be in scope and always use _selected within the component, which is easy to mess up.

[gioragutt]

@dgp1130 using alias on the input you could use selected for the computed

class MyComponent {
  _selected = input<boolean>(false, {alias: 'selected'});
  private selected = computed(() => coerceBooleanProperty(this._selected()));
}

You could be even more explicit with your naming:

class MyComponent {
  selectedRaw = input<boolean>(false, {alias: 'selected'});
  private selected = computed(() => coerceBooleanProperty(this.selectedRaw()));
}

[Jordan-Hall]

If Angular idea is to have function input and output. Does this open the possibility for developers to create they own input/output logic.

The current system with decorators does support any form of wrapping or custom solution, due to ngtc checking against Angular/core import system. I'm not saying I want to do this or anything, but previously I did want to try custom solution/poc of proxy or signal in version 15

[gioragutt]

Currently no. They still parse the component code to determine inputs/outputs, and they said they don't support wrapping the new methods (input/output/model/...) in custom methods.

[Jordan-Hall]

@alxhub if we are going functional why cant we wrap and make our own custom input and output. I know you check on the build but surely this will add additional benefits

[yjaaidi]

New output() API doesn't allow Observable reuse

As already mentioned by @Jordan-Hall , the new output() API doesn't allow implementations other than EventEmitter.
This is a new constraint as previously, Angular was only expecting an Observable-like which would allow such an implementation:

@Output() addressChange = this.formGroup.valueChanges.pipe(...);

which has the following advantages:

• it is declarative and requires less imperative subscription logic to other sources which would then emit using the output.
• can be lazy (if the parent component is not using the output, the observable is not subscribed to)

Custom output factory

It would be nice to add an option to output() allowing custom implementation. (e.g. source)

addressChange = output({source: () => this.formGroup.valueChanges.pipe(...)});

[pkozlowski-opensource]

@mgechev already said in Angular Master Podcast (#38) that outputs will be signal-based in the next versions.

Sounds like misunderstanding: output will not be modeled as signals (those are stream of events and conceptually not signals). The wording in the RFC is correct.

[e-oz]

Well, now I look like a liar, but you can hear it here: https://t.co/YLMJb013cc timing is 11:16 - 11:22

[alxhub]

Well, now I look like a liar, but you can hear it here: https://t.co/YLMJb013cc timing is 11:16 - 11:22

I think @pkozlowski-opensource meant it was @mgechev's misunderstanding, not yours :)

[e-oz]

@yjaaidi sorry for taking attention away from your question.
@alxhub @pkozlowski-opensource please give this question a minute of your time.

[yjaaidi]

😄 thx @e-oz

[luisfpg]

_Note: we know setting both signals: true and standalone: true is kind of boilerplate-y. We're still thinking of ways to make this more concise.

Something I've already missed with the change detection policy (we use OnPush for all components), and is even more boilerplate-y now for both standalone and signals: Why not having a project default in angular.json? So, the default can be set by project, and we don't need to specify on each component whether it will be standalone, signals or change detection policy.

Not to mention that this would ease the path for new Angular developers, as the defaults for a newly generated project could be to use standalone and signals components. This way, new devs wouldn't have to understand why they need to explicitly set something for every component, to avoid the non-recommended alternative.

[NsdHSO]

Why not having a project default in angular.json? So, the default can be set by project, and we don't need to specify on each component whether it will be standalone, signals or change detection policy.

@luisfpg I think this topic debated here

[bryanrideshark]

Can we use non-pure pipes in Signal components?

Say we have a pipe which is impure, and relies on a Change Detector Ref to propagate updates.

Can we still use this pipe in signal components?

[e-oz]

@bryanrideshark your pipe could return a signal-wrapped value.

[bryanrideshark]

@e-oz It seems like the solution remains to rewrite pipes either way. They won't "just work".

[e-oz]

still better than rewrite every template where you use this pipe ;)

[bryanrideshark]

@e-oz So the requirement to adopt signals will be:

1. Convert all component state to use signals rather than plain values
2. Convert template to use value() as opposed to value every time the value needs to be used to power the template.
3. Convert any pipe which relies on ChangeDetectorRef, to a version which does not rely on this feature and propogates change using signals instead. Develop two versions of said pipes because the components which are not yet upgraded to signals will still have to rely on the old version of the pipe. Perhaps additional template refactors can be avoided as long as the new component imports a module which only contains the signal version.

@alxhub, am I correct in my procedure for upgrading components? How would we even use a pipe which returns a signal as the result of transform?

[leo6104]

https://stackblitz.com/edit/angular-issue-49967?file=src%2Fmain.ts
I also tried to implement translate pipe with signal and it seems the pipe which return signal value doesn't updated with zone-based change detection timing. (forked from @ngx-translate/core)

I also interested in answer of the last question.

How would we even use a pipe which returns a signal as the result of transform?

[spierala]

@HyperLife1119 mentioned something interesting:

Can we have @SignalComponent ?

See the comment here: #49682 (reply in thread)

@SignalComponent, @SignalDirective

I think that could be a great idea because:

• The existing Component decorator becomes already quite loaded with all the options: signals, changeDetectionStrategy, standalone
• The SignalComponent decorator could come with nice defaults: standalone: true, signals: true. No option for ChangeDetectionStrategy
• It would be releatively clear that SignalComponent is a new concept with Signal Inputs, Signal Outputs, Signal ViewChildren, decidated lifecyle hooks etc
• It would prevent mixing everything: old and new concepts in one Component (e.g. oldschool Decorator inputs, signal inputs etc, new and old lifecycle hooks)
• It would be relatively easy to write documentation, because you have clearly separated things: Component docs can stay as is, SignalComponent would be just a new section in the docs
• Maybe SignalComponent could be more lightweight than a Component which must support old and new concepts?

Possible downsides?

• Probably, you can not incrementally add Signal APIs to existing Components (But in my opinion that is a benefit, because I am not fan of mixing old and new APIs in one component)

[spierala]

I remember we spoke about this with Standalone and I'm not sure it's the best, because if we went with @StandaloneComponent, now we add @SignalComponent, I prefer just have flags otherwise we would get

@standalone
@signal
@component

And who knows what else angular might do in the future.

You are right, that is a valid downside.

Decorators itself did not change much since Angular 2...
If the Signals thing will really become some next gen Angular / "Angular 3" then it could be the moment to add exceptionally new decorators.

If the Angular team sees Signals as the new best practice for the next 7 years then it might be worth it to add 2 new decorators.

But indeed, we have to be careful to not invent new decorators for every new feature.

[Jordan-Hall]

Good thing with decorators you can use multiple.

so to handle the "valid downside" you could have

export interface Component<signal, standalone> extends Directive {
  standalone?: boolean // why even have this flag? if you have imports then you know its standalone?
  signal?: boolean
}

export interface SignalComponent  extends Component<true, false> {}

export interface StandaloneComponent  extends Component<true, false> {}

Then for dx you can have can use either options or use all three

export @standalone() @signalComponent() @component({})

or just use the one you want to use. Complier can easily check which one it has and merge them into one.

[michaelfaith]

standalone?: boolean // why even have this flag? if you have imports then you know its standalone?

Unless your component doesn't need to import anything, but I digress.

[Jordan-Hall]

However, i can see angular doing something like this in future. In which case why not create a SignalComponent mixin to extend from.

export class SomeComponent extends Component({}) {
  // code here
}

[Jordan-Hall]

standalone?: boolean // why even have this flag? if you have imports then you know its standalone?

Unless your component doesn't need to import anything, but I digress.

the language service good enough to know if it needs a import so if not make it stanalone

[timonkrebs]

• ngDoCheck - typically this hook was used to implement custom change detection. effect is a likely (and more performant) replacement.

Why would you need a ngDoCheck substitute in signal components? This makes no sense to me. The change detection can not be influenced other than with signals. What would be the use case for a replacement of ngDoCheck in signal components? Effects are not needed in signal components!