The Modern Angular Cheat Sheet In short: The whole course, compressed into rules you can follow without working out the reasoning again. Twenty-eight lessons explained why . This one is the what — safe to follow directly, and safe to paste into a team style guide. The one-page decision table You need… Use --- --- A value you change directly A value worked out from other signals A worked-out value the user can also change Data from a server, based on signals Data from a promise Data needing RxJS operators To push a value out of Angular Waiting, cancelling, retrying, combining RxJS A value from a parent / Two-way binding To tell the parent something An element from my template / A service (v22) or A heavy, optional service A form + rules To load part of a template on demand Cleanup / Component template Start every new component from this shape: Consistent ordering makes components easy to scan, and puts values in the order they depend on each other. Naming Thing Convention Example --- --- --- Signal A noun, not , not True/false signal / / , Output What happened , — not Resource The data , not Guard The condition , Injection token ALL CAPS Mark every signal, input, output, and query — the holder never changes, only the value inside. Signals: the ten rules Signals vs RxJS The test: does the problem involve time? Sentence Tool --- --- "what is the current X?" Signal "wait until they stop typing" "cancel the previous request" "ignore new ones while busy" "run them in order" "retry if it fails" "only when it changed" "a live feed" WebSocket + RxJS The standard bridge — signals at the edges, a stream where time matters: Templates Rules: by a stable id. only for lists that never reorder, filter, or lose middle items. heavy, rarely-reached content. Never defer what is visible on first load — it causes layout shift. Always pair with , and with . Deferred dependencies must be standalone and referenced only inside deferred blocks, including no on them — otherwise they load eagerly anyway. is one-way — it never unloads. Use to show and hide. Anything you would want a test for belongs in a , not the template. Change detection Five things update an component: an input's reference changes, a template event fires, an pipe produces a value, a signal it reads changes, or is called. Nothing else. Not updating? In order of preference: 1. Make the value a ← almost always this 2. Replace the object in the parent 3. 4. — last resort, note why Zoneless readiness — all five should come back clean: Forms Remember: is the field, is its state, is the value. Rules: New forms → Signal Forms. Working forms → leave them. Lists are plain lists; totals are . There is no . Cross-field checks go on the field that is wrong, using . Map server errors back with returning field-and-error pairs. Disabled fields ARE in your data — Reactive Forms left them out. Remove them yourself if your server expects that. App setup Interceptor order: out in list order, back in reverse. Auth before retry , or retries repeat requests with no login. Never retry anything except — duplicate records under exactly the conditions nobody is watching. HTTP Need Use --- --- based on signals / / from a click , then Live feed RxJS Shared across components A service owning one resource The test: could this run twice with no harm? If not, it is not a resource. Testing Zone-based Vitest --- --- The migration commands The order cannot change: standalone → templates → signals → OnPush → zoneless. Review checklist Ten questions for any pull request: 1. Is every changeable value that drives the template a ? 2. Any / /direct assignment on a signal's value? 3. Any containing ? → should be / 4. Any containing ? → should be a resource or RxJS 5. Does every track a stable id? 6. Any still carrying a mark? 7. Is injected where an input would do? 8. Does any retry interceptor exclude non- requests? 9. Any new ? 10. Is cleanup handled by or ? The five worst mistakes, ranked Ranked by how much damage they do and how quietly they do it: # Mistake Why it is dangerous --- --- --- 1 A resource or retry on a request that changes data Creates or deletes records. Damages data, not just behaviour 2 on a list that reorders Elements reused with the wrong item's data — can save to the wrong record 3 that fetches No cancelling, so a slow old reply overwrites a newer correct one 4 Changing values instead of replacing them Invisible under — the screen simply does not update 5 Zoneless before signals everywhere; the codebase gets worse The top four share a property worth naming: none of them throw an error. That is what makes them worth learning as rules rather than discovering as bugs. Done, in four numbers Not a measure of design quality — but an honest measure of whether the three big changes landed. Recap State is signals. Worked-out values are . Worked-out-but-changeable is . Server data is . is only for leaving Angular. RxJS keeps everything involving time — waiting, cancelling, retrying, combining.…