Signal-based Inputs and Outputs

A signal input, declared as value = input<number>(0) (with a default) or value = input.required<number>() (mandatory, enforced by the type system — accessing it before Angular has set it is a compile-time impossibility, not just a runtime risk), is read exactly like any other Signal, by calling it as a function. This means a signal input can be fed directly into a computed() or watched by an effect() using the exact same dependency-tracking mechanism as any other Signal, without needing ngOnChanges at all to react to changes — a computed() that reads a signal input automatically recalculates whenever that input changes, which is a much more direct replacement for what ngOnChanges used to be needed for.

output() is a lighter-weight replacement for @Output() = new EventEmitter(): it's created via value = output<T>(), emits through the same .emit(value) method call, and is still consumed identically from a parent template via the parenthesis event-binding syntax — but it's no longer literally an EventEmitter/Subject wrapper the way the decorator-based version was, which slightly simplifies its internal type and semantics.

A thoughtful interview answer notes that input()/output() don't replace @Input()/@Output() outright — both are fully supported and can coexist in the same codebase — but new code, especially in components that otherwise lean on signals for internal state, benefits from using the signal-based versions throughout for a more consistent, uniformly-reactive component model.