English for Angular Signals Developers

Angular’s signals API introduced a new reactive vocabulary — signal, computed, effect — that overlaps in spirit with terms from other frameworks but has its own precise meaning within Angular’s change detection model, so using them loosely in a code review muddies what’s actually being proposed.

Key Vocabulary

Signal — a reactive, readable wrapper around a value that notifies consumers when it changes, created with signal() and read by calling it as a function. “Convert this component’s local state to a signal so the template updates automatically without a manual change detection trigger.”

Computed signal — a read-only signal whose value is derived from other signals and recalculated automatically whenever its dependencies change. “Instead of recalculating the total in the template, define it as a computed signal so it updates only when the cart signal actually changes.”

Effect — a function that runs automatically in response to signal changes, typically used for side effects like logging or syncing with external systems rather than for deriving values. “Don’t use an effect to update another signal — that’s what computed is for. Reserve effects for things like writing to local storage.”

Zoneless change detection — an Angular mode that relies on signals to know exactly when to re-render, removing the need for Zone.js to patch async APIs and detect changes globally. “Once the whole component tree is signal-based, we can opt into zoneless change detection and drop the Zone.js polyfill entirely.”

Signal input — a component input declared with input() that behaves as a signal, letting the component react to changes in parent-provided values without lifecycle hooks like ngOnChanges. “Migrate this @Input() to a signal input — it removes the need for ngOnChanges just to react to the value changing.”

Common Phrases

• “Is this value a plain signal, or should it actually be computed from something else?”
• “Are we using an effect here to derive state, or is it strictly a side effect like logging?”
• “Does this component still depend on Zone.js, or can it run under zoneless change detection?”
• “Should this be a signal input, or does the parent never actually update this value after init?”
• “Is the computed signal re-running more often than expected — are its dependencies too broad?”

Example Sentences

Reviewing a pull request: “This effect is writing to another signal, which usually means it should be a computed signal instead — effects are for side effects, not derived state.”

Explaining a migration: “We migrated the cart component’s @Input() properties to signal inputs, which let us drop the ngOnChanges hook entirely since the signals themselves notify the template.”

Debugging unexpected re-renders: “The computed signal is recalculating on every keystroke because it depends on the whole form group signal instead of just the one field it actually needs.”

Professional Tips

• Say signal and computed signal as distinct terms — conflating them in a discussion makes it unclear whether a value is source-of-truth state or a derived value.
• Reserve effect for side effects, and call it out explicitly in review if someone is using it to update state — that’s a common Angular signals anti-pattern worth naming precisely.
• Mention zoneless specifically when discussing performance or bundle size wins — it’s a distinct migration milestone, not just “using signals.”
• Use signal input rather than “reactive input” — it’s the framework’s actual API name and avoids ambiguity with other reactivity systems.

Practice Exercise

1. Explain the difference between a signal and a computed signal in one sentence.
2. Describe what an effect should and shouldn’t be used for.
3. Write a sentence explaining what zoneless change detection removes the need for.

Navigating Nuance: Precision in Technical Communication

The core of mastering Angular Signals – understanding reactivity, derived data, and side effects – is only half the battle. Equally crucial is communicating clearly and effectively with your team. As a non-native English speaker, you’ll likely find subtle differences in phrasing and expectations that can impact code reviews, sprint planning, or even just daily Slack conversations. It’s not simply about knowing the definitions of “reactive” or “computed”; it’s about how those concepts are discussed within a professional development context.

One common area where misunderstandings arise is around describing changes in signals. Instead of saying something like, “The signal changed,” which is vague and doesn’t convey the why, aim for more specific language. For example, you might say, “The userPreferences signal updated due to a new value received from the backend API,” or, if explaining a change to another developer, “I’ve modified the isLoading signal within the effect to reflect the asynchronous operation of fetching data.” Focusing on cause and effect is paramount. Pay attention to how your teammates describe their reasoning – are they using terms like “trigger,” “dependency,” or “propagation”? Understanding these connections will improve both your comprehension and your ability to articulate your own ideas. Don’t be afraid to ask for clarification; a quick question like, “Could you elaborate on the dependency chain for this effect?” can prevent significant rework later.

Another key area is framing feedback during code reviews. Instead of simply saying “This needs fixing,” try something more constructive and descriptive. Consider phrases like, “I noticed that the userRole signal isn’t being updated when the backend responds with a new role. Perhaps we should consider adding a debounce to the effect that updates this signal?” or, even better, “The current implementation doesn’t fully utilize the Signal’s reactivity capabilities; could we explore leveraging the computed property to derive the isAuthorized flag based on userRole?”. These suggestions demonstrate you’ve thought critically about the code and its potential implications.

Finally, when writing PR descriptions, be concise but informative. Avoid jargon where possible and explain why a change was made. A good example: “This PR addresses an issue where the cartTotal signal wasn’t correctly reflecting changes in the product quantities. Added a dependency on the productQuantity signal within the computed value to ensure accurate updates.”

import { Signal, computed } from '@angular/core';

export interface Product {
  id: number;
  price: number;
  quantity: number;
}

export const cartTotal = computed<number>((): number => {
  const products: Product[] = [ /* ... product data ... */ ];
  return products.reduce((sum, product) => sum + product.price * product.quantity, 0);
});

This example demonstrates the use of computed to derive a value based on other signals. When discussing this with colleagues, you might say, “The cartTotal signal is dynamically calculated using the productQuantity signal and its corresponding product prices.” Understanding these building blocks is key to effective communication around Angular Signals.