angular-ui-patterns
Modern Angular UI patterns for loading states, error handling, and data display. Use when building UI components, handling async data, or managing component states.
Angular UI Patterns
Skill Overview
Angular UI Patterns provides best practices for UI state management in modern Angular applications, covering a complete solution for loading states, error handling, empty-state design, and user interaction feedback.
Applicable Scenarios
-
When building Angular UI components Component development scenarios that need common UI patterns such as loading states, error messages, and empty-data displays.
-
When handling asynchronous data Asynchronous operations that require displaying loading and error states, such as fetching data from APIs, form submissions, and file uploads.
-
When managing component state Scenarios using Signals to manage reactive state that need correct handling of loading, error, success, empty, and other states.
Core Features
-
Loading state patterns Provides clear guidelines on when to use skeletons versus spinners, avoiding stale UI flicker and ensuring loading states are shown only when there is no data.
-
Error handling tiers Defines four layers of error handling strategy: field-level inline errors, recoverable toast notifications, page-level error banners, and full-screen error states.
-
Control flow best practices Use Angular 17+ new syntax like @if/@else, @for/@empty, and @defer to implement conditional rendering, list rendering, and progressive loading.
FAQs
When should I use a skeleton instead of a spinner?
Use skeletons when the content shape is known, such as initial page loads for lists or card layouts. Use spinners when the content shape is unknown or the operation has a small scope, such as actions inside a modal, button submissions, or inline operations.
How do you use Angular @defer?
@defer is used to lazily load non-critical content to improve first-page load performance. The basic usage wraps content in an @defer block and can be combined with @placeholder, @loading, and @error. Common triggers include on viewport (when entering the viewport), on idle (when the browser is idle), and on timer (after a delay).
How do you prevent users from clicking the submit button multiple times?
During asynchronous operations, bind the button's disabled attribute to true and display a spinner or the text "Submitting..." inside the button. Also manage the submit state with a Signal in the component and ensure the state is correctly reset in a try-finally block.