Objective
To help developers decide:
- When to show a loader (loading indicator)
- Why to show it
- What kind of loader should be shown depending on the importance of the API call
Types of API Calls Based on User Impact
1. Critical (Blocking) API Calls
These are essential operations where the app cannot move forward until the API completes.
Examples:
- User Login
- Submitting a form (e.g., payment)
- Loading data required to display the page
Expected Loader Behavior:
- Show a visible loader (e.g., full screen or component-level loader)
- Prevent the user from interacting with the app during this time
- Give a clear visual feedback that the app is “working on something”
2. Non-Critical (Non-Blocking) API Calls
These are background or secondary operations. The app can function or move forward without waiting for these calls to complete.
Examples:
- Fetching suggestions or notifications
- Sending analytics events
- Caching or syncing data in the background
Expected Loader Behavior:
- Do not block UI or user interactions
- Loader may be subtle or skipped entirely
- If needed, show a light loader (e.g., a spinner inside a component or skeleton loaders)
Best Practices for Loader Use
- Don’t overuse loaders – show them only when absolutely needed.
- Block user interactions only when required.
- Provide contextual messages with loaders (e.g., “Loading your dashboard…”).
- Avoid stacking loaders – combine or queue tasks if needed.
- Always provide feedback – especially for longer operations (>1 second).
- Minimize the impact on UX while keeping the user informed.
