Loading States
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Loading states in the CoolTools platform are designed to provide immediate visual feedback during asynchronous data fetching operations from the mobile specs API. The application utilizes a combination of global Next.js loading boundaries and component-level state management to handle transitions while fetching phone specifications, brand lists, and search results.
The system ensures that the User Interface (UI) remains responsive by employing CSS animations (specifically spinning borders) and skeleton screens. This approach mitigates perceived latency when the application performs complex operations such as retrieving detailed specifications for multiple devices or processing advanced search filters.
Architecture and Implementation
Global Loading Boundary
The application implements a root-level loading state using Next.js file-based routing conventions. The loading.tsx file defines a fallback UI that covers the entire viewport during initial route segments or page transitions.
Sources: cooltools/app/loading.tsx:1-10
Component-Level State Management
Individual pages manage their own internal loading states using React's useState hook. This allows for more granular control, such as showing specific loaders within a section of a page while keeping other parts interactive.
| Component | Loading Trigger | UI Representation |
|---|---|---|
HomePage | Initial phone list fetch | Blue animate-spin circle in Trending section |
PhonesPage | All brands/Latest phones fetch | Skeleton cards with animate-pulse |
PhoneDetailsPage | Slug-specific spec fetch | Full-screen spinner with "Loading phone details..." text |
ComparePage | Individual phone detail fetch | Small blue spinner with "Loading details..." text |
Sources: cooltools/app/page.tsx:162-166, cooltools/app/phones/page.tsx:81-93, cooltools/app/phones/[slug]/page.tsx:56-64, cooltools/app/compare/page.tsx:216-222
Data Flow and Loading Logic
The loading sequence typically follows a lifecycle where a boolean flag is toggled before and after an async API call.
This diagram illustrates the standard loading lifecycle used in the Phone Details and Browse pages to manage data retrieval from the phoneApi module.
Sources: cooltools/app/phones/[slug]/page.tsx:27-41, cooltools/app/phones/page.tsx:20-35
Implementation Patterns
Skeleton Screens
The PhonesPage uses skeleton screens to represent content that is still being loaded. This is implemented by mapping over a fixed-size array to render placeholder divs with the animate-pulse utility class.
{[...Array(8)].map((_, i) => (
<div key={i} className="bg-white dark:bg-gray-800 rounded-lg overflow-hidden shadow-lg">
<div className="w-full h-48 bg-gray-200 dark:bg-gray-700 animate-pulse"></div>
<div className="p-4 space-y-3">
<div className="h-4 bg-gray-200 dark:bg-gray-700 rounded animate-pulse"></div>
<div className="h-3 bg-gray-200 dark:bg-gray-700 rounded w-3/4 animate-pulse"></div>
</div>
</div>
))}
Sources: cooltools/app/phones/page.tsx:81-93
Search and Filter Transitions
In the ComparePage and SearchPage, specific flags like searching or isSearching are used to provide feedback during user-initiated searches. This is often combined with setTimeout or debouncing logic to prevent flickering.
This sequence shows the interaction between the search input and the loading indicator in the comparison search bar.
Sources: cooltools/app/compare/page.tsx:64-77, cooltools/app/phones/page.tsx:42-49
Technical Summary
Loading states are a critical aspect of the CoolTools user experience, ensuring that the heavy data requirements of comparing 10,000+ phone models do not result in a "frozen" interface. By leveraging animate-spin for active processing and animate-pulse for structural placeholders, the platform maintains a modern, responsive feel during data-intensive operations.
Sources: cooltools/app/loading.tsx, cooltools/app/phones/page.tsx, cooltools/app/compare/page.tsx