DEV Community: Marco Quintella

Micro-frontends as a organization - Anatomy of Scale - Part I

Marco Quintella — Mon, 23 Feb 2026 20:33:42 +0000

I an modern development ecosystem, the term "Micro-frontend" (MFE) is often met with a mix of enthusiasm and skepticism. To many, it sounds like unnecessary overengineering, but to others, it's the only escape from chaos. However, technical discussion frequently ignore the elephant in the room: frontend monoliths doesn't fail because of the code, they fail because of human scale.

Focused on this premise I will explore in a series of articles why transitioning to micro-frontends is, first and foremost, an architectural decision aligned with business strategy and team topology, and is not a traffic scaling decision.

1. Monolith Entropy and Conway's Law

Software engineering is heavily governed by Conway's Law, which states that organizations design systems that mirror their own internal communication structures, in other words, the system's architecture will inevitably mirror the team's communication structure.

When you have 50 developers working in a single React or Vue repository, communication becomes the primary bottleneck. The "blast radius" of any code change can be massive. A simple tweak to the global CSS might inadvertently break the another component layouts.

Micro-frontends emerge not as an excuse to "use something different" or "use something that looks faster", but to create context boundaries. The goal is to allow the software architecture to reflect autonomous teams that own a specific business domain end-to-end (from database straight to the user interface).

2. The Common Pitfall: The Distributed Monolith

Many teams attempt to implement MFEs and end up with the worst of both worlds: the distributed monolith. This happnes when you split the code into different repositories but maintain such tight runtime and build-time coupling that no one can move one piece without moving others.

Signs you've built a Distributed Monolith:

State Coupling: Your MFE A directly reads or mutates the global state of MFE B.
Rigid Shared Dependencies: All modules strictly require the exact same version of the same UI library to function without breaking the build.
Orchestrated Deployments: You require a "release train" where five different teams must approve and synchronize their deployments simultaneously.

The true MFE architecture demands stable interface contracts. Communication between modules must happen vie standard events or APIs, never through shared memory or internal state mutation.

3. The 3 Pillars of Architectural Decision

When deciding to decompose the frontend, we must revisit these 3 critical factors:

A. Deployment Independence

This is the golden metric. Imagine Amazon found a critical issue in the payments system. The payments team must be able to deploy a fix in 5 minutes without needing to run unit test's and dependencies from other systems or asking any other team's permission. If you haven't achieved this you don't have a MFE.

B. Fault Isolation

In a monolith, an error in a minor component can cause the website to turn into a white screen across the entire application. In a MFE model, the Application Shell must be resistant and isolate the failure. If one modules fails, the rest of the application must remain fully operational.

C. Incremental Technological Evolution

The frontend landscape ages rapidly. MFEs allow you to migrate parts of the application to new technologies without the need for a big rewrite, which is notoriously the biggest productivity killer in large enterprises.

4. The Cost of Abstraction

There is no free lunch in software architecture. Deep technical maturity requires acknowledging the trade-offs:

Performance Overhead: Loading multiples JavaScript bundles can increase the Time To Interactive (TTI). Strategies like Module Federation and careful shared dependency management at the orchestration level are vital.
Design Consistency: It demands a highly mature, versioned Design System, Without it every MFE will feature a slightly different "shade of that color".
Cognitive Load: Developers now need to understand how the App Shell orchestrates routing and how MFEs are dynamically injected into the DOM.

When should you take the leap?

The decision to adopt MFEs should be driven by pain, not hype. If your team is small and ships fast, ignore this architecture entirely. It adds a layer of operational complexity that only pays off when the scaling the all the teams workflow into a monolith becomes unbearable.

In the next article I will step out of theory into Granularity. How do you define these cutting lines? Why diving "components" is a rookie mistake, and how dividing by "business domains" can save your project.

The hidden dangers of AI-generated code in modern web frameworks

Marco Quintella — Thu, 17 Jul 2025 02:39:42 +0000

Understanding the vibecoding phenomenon

Vibecoding represents a fundamental shift in how applications get built. Instead of writing code line by line, developers now prompt AI systems to generate entire applications. While this approach promises rapid development, it introduces significant risks that many teams overlook.

The term "vibecoding emerged from the practice of relying entirely on AI to create applications based on natural language descriptions. Tools like GitHub Copilot, ChatGPT, and Claude can now generate complete Next.js and Nuxt applications from simple prompts. This creates a dangerous illusion of competence.

Modern AI code generators excel at producing functional code that appears correct at first glance. They can scaffold entire applications, implement authentication systems, and create database schemas. However, this surface-level functionality masks deeper problems that emerge during real-world usage.

The appeal is obvious. A developer can describe an e-commerce platform and receive a working application within hours instead of weeks. This speed comes at a cost that many don't realize until it's too late.

Technical debt accumulation in AI-generated applications

AI-generated applications suffer from architectural problems that compound over time. These systems often produce code that works immediately but fails to follow established patterns and best practices.

In Next.js applications, AI frequently generates components without proper separation of concerns. You might find API routes mixed with component logic, or database queries embedded directly in React components. This creates tightly coupled code that's difficult to test and maintain.

Nuxt applications face similar issues. AI generators often create pages with hardcoded data instead of using proper state management. They might implement authentication using localStorage instead of secure HTTP-only cookies, or skip proper error boundaries entirely.

The real problem emerges when teams try to scale these applications. What worked for a simple blog becomes unmanageable when adding user authentication, payment processing, or real-time features. The technical debt accumulates rapidly.

Common patterns in AI-generated code include:

Inconsistent naming conventions across files
Missing error handling for API calls
Hardcoded configuration values
Lack of proper TypeScript types
No consideration for testing strategies

This debt becomes expensive to pay off. Refactoring AI-generated code often requires understanding the entire application structure, which can be nearly impossible when the original logic wasn't designed by humans.

Security vulnerabilities in AI-generated code

Security represents the most critical risk in AI-generated applications. These systems often produce code that appears functional but contains serious security flaws that attackers can exploit.

AI generators frequently implement authentication using insecure patterns. In Next.js applications, you might find JWT tokens stored in localStorage instead of secure HTTP-only cookies. This makes applications vulnerable to XSS attacks that can steal user sessions.

Nuxt applications face similar authentication issues. AI might generate authentication middleware that doesn't properly validate tokens or implement session management incorrectly. This can lead to unauthorized access to protected routes.

Database security is another major concern. AI-generated code often includes SQL queries without proper parameterization, creating SQL injection vulnerabilities. Even when using ORMs, the generated code might not properly sanitize user inputs.

Common security issues in AI-generated applications:

Vulnerability Type	AI-Generated Pattern	Risk Level
XSS Attacks	Unsanitized user input in components	High
SQL Injection	Raw SQL queries without parameters	Critical
Authentication Bypass	Weak token validation	High
CSRF Attacks	Missing CSRF tokens	Medium
Information Disclosure	Error messages exposing system details	Medium

The problem compounds when AI generates API endpoints without proper input validation. A simple contact form might accept any input without sanitization, allowing attackers to inject malicious scripts or execute server-side code.

These vulnerabilities often go undetected during initial testing because the application appears to function correctly. The security flaws only become apparent when malicious actors discover and exploit them.

Performance and scalability issues

Performance problems plague AI-generated applications from the start. These systems focus on functionality over optimization, creating applications that work but perform poorly under real-world conditions.

Next.js applications suffer from inefficient data fetching patterns. AI might generate components that fetch data on every render instead of using proper caching strategies. This leads to unnecessary API calls and slow page loads.

Server-side rendering implementation often gets botched. AI generators might create pages that render everything on the client side, missing the performance benefits of SSR. Or they might implement SSR incorrectly, causing hydration mismatches and poor user experience.

Nuxt applications face similar performance issues. AI-generated code might not properly utilize Nuxt's built-in optimization features like automatic code splitting or image optimization. Components might be unnecessarily large, increasing bundle sizes.

Common performance problems include:

Memory leaks from improper cleanup in useEffect hooks
Unnecessary re-renders due to missing dependency arrays
Large bundle sizes from importing entire libraries
Inefficient database queries without proper indexing
Missing caching strategies for API responses

The scalability issues become apparent when applications need to handle increased traffic. What works for 10 users fails completely with 1000 concurrent users. Database connections might not be properly managed, leading to connection pool exhaustion.

These performance problems often require complete architectural changes to fix. The cost of optimization can exceed the original development time, making AI-generated applications expensive in the long run.

Maintenance and debugging challenges

Maintaining AI-generated applications becomes a nightmare for development teams. The code might work initially, but when problems arise, debugging becomes nearly impossible due to the lack of human understanding behind the implementation.

Documentation is virtually non-existent in AI-generated code. While AI can generate comments, these often describe what the code does rather than why certain decisions were made. This makes it difficult for developers to understand the business logic and make informed changes.

Debugging AI-generated applications requires reverse-engineering the original intent. When a bug appears, developers must trace through complex dependency chains that weren't designed with human comprehension in mind. The lack of consistent patterns makes this process time-consuming and error-prone.

Next.js applications suffer from component complexity. AI might generate deeply nested components with multiple responsibilities, making it difficult to isolate and fix issues. State management often becomes convoluted, with data flowing through unexpected paths.

Nuxt applications face similar maintenance challenges. AI-generated middleware might have unclear logic, and the relationship between pages, components, and stores can be confusing. Error handling might be inconsistent across different parts of the application.

The debugging process becomes even more challenging when multiple AI tools have been used. Different generators might use different conventions, creating a patchwork of styles that's difficult to navigate.

Common maintenance issues include:

Inconsistent error handling across components
Unclear data flow between different parts of the application
Missing logging for debugging purposes
Complex dependency relationships that are hard to trace
Lack of unit tests to verify functionality

When bugs do get fixed, the solutions often introduce new problems because developers don't fully understand the original architecture. This creates a cycle of technical debt that becomes increasingly expensive to manage.

The long-term cost of maintaining AI-generated applications often exceeds the initial development savings. Teams spend more time debugging and fixing issues than they would have spent building the application properly from the start.

Mastering Nuxt's New Data Layer: A Complete Developer's Guide

Marco Quintella — Fri, 23 May 2025 01:12:24 +0000

The Nuxt data layer has undergone a revolutionary transformation, bringing developers five game-changing features that will fundamentally change how you handle data in your applications. Gone are the days of wrestling with complex state management patterns – Nuxt's new data layer is here to make your development experience smoother, more intuitive, and significantly more powerful.

In this comprehensive guide, we'll dive deep into each new feature with practical examples, real-world scenarios, and best practices that will transform you from a data layer novice to a master. Whether you're building a simple blog or a complex enterprise application, these features will become your new best friends.

1. Reactive Server State with Enhanced `$fetch`

The enhanced $fetch utility is perhaps the most exciting addition to Nuxt's arsenal. It's not just about making HTTP requests anymore – it's about creating a seamless bridge between your server and client with built-in reactivity.

Basic Enhanced Fetching

Let's start with a simple example that demonstrates the power of reactive server state:

<template>
  <div class="user-profile">
    <div v-if="pending" class="loading-spinner">
      <div class="spinner"></div>
      <p>Loading user profile...</p>
    </div>

    <div v-else-if="error" class="error-container">
      <h3>Oops! Something went wrong</h3>
      <p>{{ error.message }}</p>
      <button @click="refresh()" class="retry-btn">Try Again</button>
    </div>

    <div v-else class="profile-content">
      <img :src="data?.avatar" :alt="`${data?.name}'s avatar`" />
      <h2>{{ data?.name }}</h2>
      <p>{{ data?.email }}</p>
      <div class="stats">
        <span>Posts: {{ data?.postsCount }}</span>
        <span>Followers: {{ data?.followersCount }}</span>
      </div>
    </div>
  </div>
</template>

<script setup lang="ts">
interface User {
  id: number
  name: string
  email: string
  avatar: string
  postsCount: number
  followersCount: number
}

interface UserResponse {
  user: User
  lastUpdated: string
}

const route = useRoute()
const userId = computed(() => route.params.id as string)

// The magic happens here - reactive server state!
const { data, pending, error, refresh } = await $fetch<UserResponse>(`/api/users/${userId.value}`, {
  key: `user-${userId.value}`,
  server: true,
  default: () => null,
  transform: (response: UserResponse) => response.user,
  onResponse({ response }) {
    console.log('Fresh data received:', response._data)
  },
  onResponseError({ error }) {
    console.error('Failed to fetch user:', error)
  }
})

// Watch for route changes and automatically refetch
watch(userId, (newId) => {
  if (newId) {
    refresh()
  }
})
</script>

What makes this special? The enhanced $fetch automatically handles loading states, error states, and provides reactive data that updates across your entire application. The key parameter ensures proper caching and deduplication – if another component requests the same user, it won't make a duplicate request.

Advanced Conditional Fetching

Sometimes you need more control over when your data fetches. Here's how to implement conditional fetching with dependency tracking:

<template>
  <div class="dashboard">
    <div class="filters">
      <select v-model="selectedCategory" class="category-select">
        <option value="">All Categories</option>
        <option value="tech">Technology</option>
        <option value="design">Design</option>
        <option value="business">Business</option>
      </select>

      <input 
        v-model="searchQuery" 
        type="text" 
        placeholder="Search articles..."
        class="search-input"
      />

      <label class="checkbox-container">
        <input v-model="includeUnpublished" type="checkbox" />
        Include unpublished articles
      </label>
    </div>

    <div v-if="shouldFetch" class="articles-container">
      <ArticleCard 
        v-for="article in articles" 
        :key="article.id" 
        :article="article"
      />

      <div v-if="articlesLoading" class="loading-more">
        Loading more articles...
      </div>
    </div>

    <div v-else class="no-search">
      <p>Enter a search term or select a category to see articles</p>
    </div>
  </div>
</template>

<script setup lang="ts">
interface Article {
  id: number
  title: string
  excerpt: string
  category: string
  published: boolean
  createdAt: string
}

interface ArticlesResponse {
  articles: Article[]
  total: number
  hasMore: boolean
}

const selectedCategory = ref<string>('')
const searchQuery = ref<string>('')
const includeUnpublished = ref<boolean>(false)

// Computed property to determine if we should fetch
const shouldFetch = computed(() => 
  selectedCategory.value !== '' || searchQuery.value.trim() !== ''
)

// Debounced search query to avoid excessive API calls
const debouncedSearchQuery = refDebounced(searchQuery, 300)

// Build query parameters reactively
const queryParams = computed(() => ({
  category: selectedCategory.value,
  search: debouncedSearchQuery.value,
  includeUnpublished: includeUnpublished.value,
  limit: 20
}))

// Conditional fetching with reactive dependencies
const { 
  data: articlesData, 
  pending: articlesLoading, 
  error: articlesError 
} = await $fetch<ArticlesResponse>('/api/articles', {
  key: 'filtered-articles',
  query: queryParams,
  server: false, // Client-side only for dynamic filtering
  default: () => ({ articles: [], total: 0, hasMore: false }),
  // Only fetch when we have search criteria
  skip: () => !shouldFetch.value
})

const articles = computed(() => articlesData.value?.articles || [])

// Reset search when category changes
watch(selectedCategory, () => {
  searchQuery.value = ''
})
</script>

This example demonstrates how the new data layer intelligently handles conditional fetching. The skip function prevents unnecessary requests, while the reactive queryParams automatically trigger refetches when dependencies change.

2. Advanced Caching and Invalidation

The new caching system is a developer's dream come true. It provides granular control over cache behavior while maintaining simplicity for common use cases.

Smart Cache Management

<template>
  <div class="blog-post">
    <article v-if="post" class="post-content">
      <header>
        <h1>{{ post.title }}</h1>
        <div class="meta">
          <span>By {{ post.author.name }}</span>
          <time :datetime="post.publishedAt">{{ formatDate(post.publishedAt) }}</time>
          <span class="reading-time">{{ post.readingTime }} min read</span>
        </div>
      </header>

      <div class="content" v-html="post.content"></div>

      <footer class="post-footer">
        <div class="tags">
          <span v-for="tag in post.tags" :key="tag" class="tag">
            #{{ tag }}
          </span>
        </div>

        <div class="actions">
          <button @click="toggleLike" :class="{ liked: isLiked }" class="like-btn">
            ❤️ {{ post.likesCount + (isLiked ? 1 : 0) }}
          </button>
          <button @click="sharePost" class="share-btn">Share</button>
        </div>
      </footer>
    </article>

    <section class="comments-section">
      <h3>Comments ({{ comments?.length || 0 }})</h3>
      <CommentForm @comment-added="handleNewComment" />
      <CommentList :comments="comments" />
    </section>
  </div>
</template>

<script setup lang="ts">
interface Author {
  id: number
  name: string
  avatar: string
}

interface BlogPost {
  id: number
  title: string
  content: string
  excerpt: string
  author: Author
  publishedAt: string
  readingTime: number
  tags: string[]
  likesCount: number
}

interface Comment {
  id: number
  content: string
  author: string
  createdAt: string
}

const route = useRoute()
const postSlug = route.params.slug as string

// Long-term caching for post content (rarely changes)
const { data: post } = await $fetch<BlogPost>(`/api/posts/${postSlug}`, {
  key: `post-${postSlug}`,
  server: true,
  // Cache for 1 hour - posts don't change often
  maxAge: 60 * 60,
  // Stale-while-revalidate: serve stale content while fetching fresh data
  swr: true,
  headers: {
    'Cache-Control': 'public, max-age=3600, stale-while-revalidate=86400'
  }
})

// Short-term caching for dynamic content (comments)
const { 
  data: comments, 
  refresh: refreshComments 
} = await $fetch<Comment[]>(`/api/posts/${postSlug}/comments`, {
  key: `comments-${postSlug}`,
  server: false,
  // Shorter cache for dynamic content
  maxAge: 5 * 60, // 5 minutes
  default: () => []
})

// Client-side state for interactions
const isLiked = ref(false)

// Handle new comment with cache invalidation
const handleNewComment = async (newComment: Comment) => {
  // Optimistically update the UI
  comments.value = [...(comments.value || []), newComment]

  // Invalidate and refresh comments cache
  await clearNuxtData(`comments-${postSlug}`)
  await refreshComments()

  // Also invalidate related caches
  await clearNuxtData('recent-comments')
  await clearNuxtData('user-activity')
}

const toggleLike = async () => {
  const wasLiked = isLiked.value

  // Optimistic update
  isLiked.value = !wasLiked

  try {
    await $fetch(`/api/posts/${postSlug}/like`, {
      method: wasLiked ? 'DELETE' : 'POST'
    })

    // Invalidate post cache to reflect new like count
    await clearNuxtData(`post-${postSlug}`)
  } catch (error) {
    // Revert optimistic update on error
    isLiked.value = wasLiked
    console.error('Failed to toggle like:', error)
  }
}

const sharePost = async () => {
  if (navigator.share && post.value) {
    await navigator.share({
      title: post.value.title,
      text: post.value.excerpt,
      url: window.location.href
    })
  }
}

const formatDate = (dateString: string) => {
  return new Date(dateString).toLocaleDateString('en-US', {
    year: 'numeric',
    month: 'long',
    day: 'numeric'
  })
}
</script>

Cache Strategy Breakdown:

Post content: Long cache duration with stale-while-revalidate for performance
Comments: Shorter cache with immediate invalidation on updates
Optimistic updates: Immediate UI feedback with rollback on errors

Global Cache Invalidation Patterns

Here's how to implement sophisticated cache invalidation patterns for complex applications:

<template>
  <div class="admin-dashboard">
    <nav class="admin-nav">
      <button 
        v-for="tab in tabs" 
        :key="tab.id"
        @click="activeTab = tab.id"
        :class="{ active: activeTab === tab.id }"
        class="nav-tab"
      >
        {{ tab.label }}
        <span v-if="tab.badge" class="badge">{{ tab.badge }}</span>
      </button>
    </nav>

    <main class="admin-content">
      <UsersPanel v-if="activeTab === 'users'" @user-updated="handleUserUpdate" />
      <PostsPanel v-if="activeTab === 'posts'" @post-published="handlePostPublish" />
      <SettingsPanel v-if="activeTab === 'settings'" @settings-changed="handleSettingsChange" />
    </main>
  </div>
</template>

<script setup lang="ts">
interface CacheInvalidationEvent {
  type: 'user' | 'post' | 'settings'
  action: 'create' | 'update' | 'delete' | 'publish'
  entityId?: string | number
  affectedCaches: string[]
}

const activeTab = ref<'users' | 'posts' | 'settings'>('users')

const tabs = computed(() => [
  { id: 'users', label: 'Users', badge: pendingUsers.value },
  { id: 'posts', label: 'Posts', badge: draftPosts.value },
  { id: 'settings', label: 'Settings' }
])

// Global cache invalidation strategy
class CacheInvalidationManager {
  private static patterns: Record<string, string[]> = {
    'user-update': [
      'users-*',
      'user-{id}',
      'user-posts-{id}',
      'dashboard-stats',
      'recent-activity'
    ],
    'post-publish': [
      'posts-*',
      'post-{id}',
      'author-posts-*',
      'category-posts-*',
      'homepage-featured',
      'sitemap'
    ],
    'settings-change': [
      'app-config',
      'theme-settings',
      'navigation-menu',
      'footer-content'
    ]
  }

  static async invalidate(event: CacheInvalidationEvent): Promise<void> {
    const cacheKey = `${event.type}-${event.action}`
    const patterns = this.patterns[cacheKey] || []

    console.log(`🗑️ Invalidating caches for: ${cacheKey}`)

    for (const pattern of patterns) {
      let resolvedPattern = pattern

      // Replace placeholders with actual values
      if (event.entityId) {
        resolvedPattern = pattern.replace('{id}', String(event.entityId))
      }

      // Handle wildcard patterns
      if (resolvedPattern.includes('*')) {
        await this.invalidatePattern(resolvedPattern)
      } else {
        await clearNuxtData(resolvedPattern)
      }
    }
  }

  private static async invalidatePattern(pattern: string): Promise<void> {
    const prefix = pattern.replace('*', '')

    // Get all cached keys and invalidate matching ones
    if (process.client) {
      const nuxtData = nuxtApp.ssrContext?.nuxtData || {}
      const matchingKeys = Object.keys(nuxtData).filter(key => 
        key.startsWith(prefix)
      )

      for (const key of matchingKeys) {
        await clearNuxtData(key)
      }
    }
  }
}

// Event handlers with intelligent cache invalidation
const handleUserUpdate = async (userId: number) => {
  await CacheInvalidationManager.invalidate({
    type: 'user',
    action: 'update',
    entityId: userId,
    affectedCaches: []
  })

  // Trigger UI updates
  await refreshNuxtData('dashboard-stats')
}

const handlePostPublish = async (postId: number) => {
  await CacheInvalidationManager.invalidate({
    type: 'post',
    action: 'publish',
    entityId: postId,
    affectedCaches: []
  })

  // Show success notification
  showNotification('Post published successfully! 🎉')
}

const handleSettingsChange = async () => {
  await CacheInvalidationManager.invalidate({
    type: 'settings',
    action: 'update',
    affectedCaches: []
  })
}

// Fetch dashboard stats with caching
const { data: pendingUsers } = await $fetch<number>('/api/admin/users/pending-count', {
  key: 'pending-users-count',
  maxAge: 30, // 30 seconds cache
  default: () => 0
})

const { data: draftPosts } = await $fetch<number>('/api/admin/posts/draft-count', {
  key: 'draft-posts-count',
  maxAge: 30,
  default: () => 0
})
</script>

This sophisticated caching system automatically handles complex invalidation scenarios, ensuring your data stays fresh while maximizing performance.

3. Cross-Component Data Synchronization

One of the most powerful features is automatic data synchronization across components. No more prop drilling or complex state management!

Real-time Shopping Cart Example

<!-- ProductCard.vue -->
<template>
  <div class="product-card">
    <img :src="product.image" :alt="product.name" />
    <div class="product-info">
      <h3>{{ product.name }}</h3>
      <p class="price">${{ product.price }}</p>
      <p class="description">{{ product.description }}</p>

      <div class="product-actions">
        <div class="quantity-controls">
          <button 
            @click="decrementQuantity" 
            :disabled="quantity <= 0"
            class="qty-btn"
          >
            -
          </button>
          <span class="quantity">{{ quantity }}</span>
          <button @click="incrementQuantity" class="qty-btn">+</button>
        </div>

        <button 
          @click="addToCart" 
          :disabled="quantity === 0"
          class="add-to-cart-btn"
        >
          Add to Cart
        </button>
      </div>
    </div>
  </div>
</template>

<script setup lang="ts">
interface Product {
  id: number
  name: string
  price: number
  description: string
  image: string
  stock: number
}

interface Props {
  product: Product
}

const props = defineProps<Props>()
const quantity = ref(1)

// Access shared cart data - automatically synced across all components!
const { data: cartData, refresh: refreshCart } = await $fetch('/api/cart', {
  key: 'user-cart',
  server: false,
  default: () => ({ items: [], total: 0, count: 0 })
})

const addToCart = async () => {
  if (quantity.value <= 0) return

  try {
    // Add to cart on server
    await $fetch('/api/cart/add', {
      method: 'POST',
      body: {
        productId: props.product.id,
        quantity: quantity.value
      }
    })

    // The magic: refresh cart data and ALL components using this data will update!
    await refreshCart()

    // Reset quantity
    quantity.value = 1

    // Show success feedback
    showCartNotification(`Added ${props.product.name} to cart!`)

  } catch (error) {
    console.error('Failed to add to cart:', error)
    showErrorNotification('Failed to add item to cart')
  }
}

const incrementQuantity = () => {
  if (quantity.value < props.product.stock) {
    quantity.value++
  }
}

const decrementQuantity = () => {
  if (quantity.value > 0) {
    quantity.value--
  }
}
</script>

<!-- CartSidebar.vue -->
<template>
  <div class="cart-sidebar" :class="{ open: isOpen }">
    <header class="cart-header">
      <h2>Shopping Cart</h2>
      <button @click="closeCart" class="close-btn">✕</button>
    </header>

    <div v-if="cartItems.length === 0" class="empty-cart">
      <p>Your cart is empty</p>
      <button @click="closeCart" class="continue-shopping">
        Continue Shopping
      </button>
    </div>

    <div v-else class="cart-content">
      <div class="cart-items">
        <CartItem 
          v-for="item in cartItems" 
          :key="item.id"
          :item="item"
          @quantity-changed="handleQuantityChange"
          @remove="handleRemoveItem"
        />
      </div>

      <footer class="cart-footer">
        <div class="cart-summary">
          <div class="summary-row">
            <span>Subtotal:</span>
            <span>${{ cartData?.subtotal?.toFixed(2) }}</span>
          </div>
          <div class="summary-row">
            <span>Tax:</span>
            <span>${{ cartData?.tax?.toFixed(2) }}</span>
          </div>
          <div class="summary-row total">
            <span>Total:</span>
            <span>${{ cartData?.total?.toFixed(2) }}</span>
          </div>
        </div>

        <button @click="proceedToCheckout" class="checkout-btn">
          Proceed to Checkout
        </button>
      </footer>
    </div>
  </div>
</template>

<script setup lang="ts">
interface CartItem {
  id: number
  productId: number
  name: string
  price: number
  quantity: number
  image: string
}

interface CartData {
  items: CartItem[]
  subtotal: number
  tax: number
  total: number
  count: number
}

const isOpen = defineModel<boolean>()

// Same cart data as ProductCard - automatically synchronized!
const { data: cartData, refresh: refreshCart } = await $fetch<CartData>('/api/cart', {
  key: 'user-cart', // Same key = same cached data
  server: false,
  default: () => ({ items: [], subtotal: 0, tax: 0, total: 0, count: 0 })
})

const cartItems = computed(() => cartData.value?.items || [])

const handleQuantityChange = async (itemId: number, newQuantity: number) => {
  try {
    await $fetch('/api/cart/update', {
      method: 'PUT',
      body: { itemId, quantity: newQuantity }
    })

    // Refresh cart data - updates everywhere automatically!
    await refreshCart()

  } catch (error) {
    console.error('Failed to update quantity:', error)
  }
}

const handleRemoveItem = async (itemId: number) => {
  try {
    await $fetch(`/api/cart/remove/${itemId}`, {
      method: 'DELETE'
    })

    await refreshCart()

  } catch (error) {
    console.error('Failed to remove item:', error)
  }
}

const proceedToCheckout = () => {
  navigateTo('/checkout')
}

const closeCart = () => {
  isOpen.value = false
}
</script>

<!-- CartIcon.vue (in header) -->
<template>
  <button @click="openCart" class="cart-icon-btn">
    <div class="cart-icon">
      🛒
      <span v-if="itemCount > 0" class="cart-badge">
        {{ itemCount }}
      </span>
    </div>
  </button>
</template>

<script setup lang="ts">
// Same cart data - automatically shows updated count from any cart interaction!
const { data: cartData } = await $fetch('/api/cart', {
  key: 'user-cart', // Same key again!
  server: false,
  default: () => ({ items: [], total: 0, count: 0 })
})

const itemCount = computed(() => cartData.value?.count || 0)

const openCart = () => {
  // Emit event to open cart sidebar
  emit('open-cart')
}
</script>

What's magical here? All three components use the same cache key ('user-cart'), so when one component updates the cart data, ALL components automatically reflect the changes. No manual synchronization needed!

4. Optimistic Updates with Rollback

Optimistic updates make your app feel lightning-fast by updating the UI immediately, then syncing with the server in the background.

Social Media Post Interaction

<template>
  <article class="social-post">
    <header class="post-header">
      <img :src="post.author.avatar" :alt="post.author.name" class="avatar" />
      <div class="author-info">
        <h3>{{ post.author.name }}</h3>
        <time>{{ formatTimeAgo(post.createdAt) }}</time>
      </div>
    </header>

    <div class="post-content">
      <p>{{ post.content }}</p>
      <img v-if="post.image" :src="post.image" alt="Post image" />
    </div>

    <footer class="post-actions">
      <button 
        @click="toggleLike" 
        :class="{ liked: isLiked, loading: likeLoading }"
        class="action-btn like-btn"
        :disabled="likeLoading"
      >
        {{ isLiked ? '❤️' : '🤍' }} {{ displayLikeCount }}
      </button>

      <button 
        @click="toggleBookmark" 
        :class="{ bookmarked: isBookmarked, loading: bookmarkLoading }"
        class="action-btn bookmark-btn"
        :disabled="bookmarkLoading"
      >
        {{ isBookmarked ? '🔖' : '📑' }} {{ isBookmarked ? 'Saved' : 'Save' }}
      </button>

      <button @click="sharePost" class="action-btn share-btn">
        🔗 Share
      </button>
    </footer>

    <!-- Comments section with optimistic updates -->
    <section class="comments-section">
      <div class="comment-form">
        <textarea 
          v-model="newComment" 
          placeholder="Write a comment..."
          class="comment-input"
          @keydown.meta.enter="submitComment"
        ></textarea>
        <button 
          @click="submitComment" 
          :disabled="!newComment.trim() || commentSubmitting"
          class="submit-comment-btn"
        >
          {{ commentSubmitting ? 'Posting...' : 'Post Comment' }}
        </button>
      </div>

      <div class="comments-list">
        <Comment 
          v-for="comment in displayComments" 
          :key="comment.id"
          :comment="comment"
          :is-optimistic="comment.isOptimistic"
          @delete="handleDeleteComment"
        />
      </div>
    </section>
  </article>
</template>

<script setup lang="ts">
interface Author {
  id: number
  name: string
  avatar: string
}

interface SocialPost {
  id: number
  content: string
  image?: string
  author: Author
  createdAt: string
  likesCount: number
  commentsCount: number
}

interface Comment {
  id: number | string // Can be temp ID for optimistic updates
  content: string
  author: Author
  createdAt: string
  isOptimistic?: boolean // Flag for optimistic comments
}

interface Props {
  post: SocialPost
}

const props = defineProps<Props>()
const user = await getCurrentUser() // Assume this gets current user

// Reactive state for interactions
const isLiked = ref(false)
const isBookmarked = ref(false)
const likeLoading = ref(false)
const bookmarkLoading = ref(false)
const commentSubmitting = ref(false)
const newComment = ref('')

// Optimistic state management
const optimisticLikes = ref(0)
const optimisticComments = ref<Comment[]>([])

// Fetch initial interaction state
const { data: interactions } = await $fetch(`/api/posts/${props.post.id}/interactions`, {
  key: `post-interactions-${props.post.id}`,
  default: () => ({ liked: false, bookmarked: false })
})

// Fetch comments with caching
const { data: comments, refresh: refreshComments } = await $fetch<Comment[]>(
  `/api/posts/${props.post.id}/comments`,
  {
    key: `post-comments-${props.post.id}`,
    default: () => []
  }
)

// Initialize state from server data
onMounted(() => {
  isLiked.value = interactions.value?.liked || false
  isBookmarked.value = interactions.value?.bookmarked || false
})

// Computed properties for display
const displayLikeCount = computed(() => 
  props.post.likesCount + optimisticLikes.value
)

const displayComments = computed(() => [
  ...(comments.value || []),
  ...optimisticComments.value
])

// Optimistic like toggle with rollback
const toggleLike = async () => {
  if (likeLoading.value) return

  likeLoading.value = true
  const wasLiked = isLiked.value
  const originalCount = props.post.likesCount

  // Optimistic update
  isLiked.value = !wasLiked
  optimisticLikes.value = wasLiked ? -1 : 1

  try {
    await $fetch(`/api/posts/${props.post.id}/like`, {
      method: wasLiked ? 'DELETE' : 'POST'
    })

    // Success: commit optimistic changes
    props.post.likesCount = originalCount + optimisticLikes.value
    optimisticLikes.value = 0

    // Update cached interactions
    await refreshNuxtData(`post-interactions-${props.post.id}`)

  } catch (error) {
    // Rollback optimistic update
    isLiked.value = wasLiked
    optimisticLikes.value = 0

    console.error('Failed to toggle like:', error)
    showErrorNotification('Failed to update like status')
  } finally {
    likeLoading.value = false
  }
}

// Optimistic bookmark toggle
const toggleBookmark = async () => {
  if (bookmarkLoading.value) return

  bookmarkLoading.value = true
  const wasBookmarked = isBookmarked.value

  // Optimistic update
  isBookmarked.value = !wasBookmarked

  try {
    await $fetch(`/api/posts/${props.post.id}/bookmark`, {
      method: wasBookmarked ? 'DELETE' : 'POST'
    })

    showSuccessNotification(
      wasBookmarked ? 'Removed from bookmarks' : 'Added to bookmarks'
    )

  } catch (error) {
    // Rollback
    isBookmarked.value = wasBookmarked

    console.error('Failed to toggle bookmark:', error)
    showErrorNotification('Failed to update bookmark status')
  } finally {
    bookmarkLoading.value = false
  }
}

// Optimistic comment submission
const submitComment = async () => {
  if (!newComment.value.trim() || commentSubmitting.value) return

  commentSubmitting.value = true
  const tempId = `temp-${Date.now()}`
  const commentContent = newComment.value.trim()

  // Create optimistic comment
  const optimisticComment: Comment = {
    id: tempId,
    content: commentContent,
    author: user.value,
    createdAt: new Date().toISOString(),
    isOptimistic: true
  }

  // Add to optimistic comments immediately
  optimisticComments.value.push(optimisticComment)
  newComment.value = '' // Clear input immediately

  try {
    const savedComment = await $fetch<Comment>(`/api/posts/${props.post.id}/comments`, {
      method: 'POST',
      body: { content: commentContent }
    })

    // Remove optimistic comment and refresh real comments
    optimisticComments.value = optimisticComments.value.filter(c => c.id !== tempId)
    await refreshComments()

    // Update post comments count
    props.post.commentsCount++

    showSuccessNotification('Comment posted successfully!')

  } catch (error) {
    // Remove failed optimistic comment
    optimisticComments.value = optimisticComments.value.filter(c => c.id !== tempId)
    newComment.value = commentContent // Restore comment text

    console.error('Failed to post comment:', error)
    showErrorNotification('Failed to post comment. Please try again.')
  } finally {
    commentSubmitting.value = false
  }
}

const handleDeleteComment = async (commentId: number) => {
  // Find comment in real comments
  const commentIndex = comments.value?.findIndex(c => c.id === commentId)
  if (commentIndex === -1) return

  const deletedComment = comments.value[commentIndex]

  // Optimistically remove from UI
  comments.value.splice(commentIndex, 1)
  props.post.commentsCount--

  try {
    await $fetch(`/api/comments/${commentId}`, {
      method: 'DELETE'
    })

    showSuccessNotification('Comment deleted')

  } catch (error) {
    // Rollback: restore deleted comment
    comments.value.splice(commentIndex, 0, deletedComment)
    props.post.commentsCount++

    console.error('Failed to delete comment:', error)
    showErrorNotification('Failed to delete comment')
  }
}

const sharePost = async () => {
  const shareData = {
    title: `Post by ${props.post.author.name}`,
    text: props.post.content.substring(0, 100) + '...',
    url: `${window.location.origin}/posts/${props.post.id}`
  }

  if (navigator.share) {
    await navigator.share(shareData)
  } else {
    await navigator.clipboard.writeText(shareData.url)
    showSuccessNotification('Link copied to clipboard!')
  }
}

const formatTimeAgo = (dateString: string) => {
  const now = new Date()
  const date = new Date(dateString)
  const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000)

  if (diffInSeconds < 60) return 'Just now'
  if (diffInSeconds < 3600) return `${Math.floor(diffInSeconds / 60)}m ago`
  if (diffInSeconds < 86400) return `${Math.floor(diffInSeconds / 3600)}h ago`
  return `${Math.floor(diffInSeconds / 86400)}d ago`
}
</script>

This example showcases the power of optimistic updates. Users see immediate feedback while the app handles server synchronization in the background, with automatic rollback on failures.

5. Server-Side State Hydration

The final piece of the puzzle is seamless server-side state hydration. Your app starts with data already loaded, no loading spinners on first render!

E-commerce Product Catalog with SSR

<!-- pages/products/index.vue -->
<template>
  <div class="products-page">
    <header class="page-header">
      <h1>Our Products</h1>
      <p>Discover amazing products tailored just for you</p>
    </header>

    <aside class="filters-sidebar">
      <ProductFilters 
        v-model:category="selectedCategory"
        v-model:price-range="priceRange"
        v-model:brands="selectedBrands"
        :available-categories="categories"
        :available-brands="brands"
        @filters-changed="handleFiltersChange"
      />
    </aside>

    <main class="products-main">
      <div class="products-toolbar">
        <div class="results-info">
          <span>{{ totalProducts }} products found</span>
        </div>

        <div class="sort-controls">
          <select v-model="sortBy" class="sort-select">
            <option value="relevance">Most Relevant</option>
            <option value="price-low">Price: Low to High</option>
            <option value="price-high">Price: High to Low</option>
            <option value="rating">Highest Rated</option>
            <option value="newest">Newest First</option>
          </select>
        </div>
      </div>

      <div v-if="productsLoading" class="loading-state">
        <ProductSkeleton v-for="n in 12" :key="n" />
      </div>

      <div v-else class="products-grid">
        <ProductCard 
          v-for="product in products" 
          :key="product.id"
          :product="product"
          @add-to-cart="handleAddToCart"
          @quick-view="handleQuickView"
        />
      </div>

      <div v-if="hasMoreProducts" class="load-more-section">
        <button 
          @click="loadMoreProducts" 
          :disabled="loadingMore"
          class="load-more-btn"
        >
          {{ loadingMore ? 'Loading...' : 'Load More Products' }}
        </button>
      </div>
    </main>
  </div>
</template>

<script setup lang="ts">
interface Product {
  id: number
  name: string
  price: number
  originalPrice?: number
  rating: number
  reviewCount: number
  image: string
  category: string
  brand: string
  inStock: boolean
}

interface ProductsResponse {
  products: Product[]
  total: number
  page: number
  hasMore: boolean
  categories: string[]
  brands: string[]
}

interface ProductFilters {
  category: string[]
  priceRange: [number, number]
  brands: string[]
  sortBy: string
  page: number
}

// SEO and meta tags
useHead({
  title: 'Premium Products - Your Store',
  meta: [
    { name: 'description', content: 'Discover our curated collection of premium products with fast shipping and great prices.' }
  ]
})

// URL-based filter state
const route = useRoute()
const router = useRouter()

// Initialize filters from URL params
const selectedCategory = ref<string[]>(
  route.query.category ? String(route.query.category).split(',') : []
)
const priceRange = ref<[number, number]>([
  Number(route.query.minPrice) || 0,
  Number(route.query.maxPrice) || 1000
])
const selectedBrands = ref<string[]>(
  route.query.brands ? String(route.query.brands).split(',') : []
)
const sortBy = ref<string>(String(route.query.sort) || 'relevance')
const currentPage = ref<number>(Number(route.query.page) || 1)

// Computed filter object
const filters = computed<ProductFilters>(() => ({
  category: selectedCategory.value,
  priceRange: priceRange.value,
  brands: selectedBrands.value,
  sortBy: sortBy.value,
  page: currentPage.value
}))

// SERVER-SIDE HYDRATION: This runs on server AND client
const { 
  data: productsData, 
  pending: productsLoading,
  refresh: refreshProducts 
} = await $fetch<ProductsResponse>('/api/products', {
  key: 'products-catalog',
  // This ensures the data is fetched on server-side
  server: true,
  // Default data structure to prevent hydration mismatches
  default: () => ({
    products: [],
    total: 0,
    page: 1,
    hasMore: false,
    categories: [],
    brands: []
  }),
  // Reactive query parameters
  query: computed(() => ({
    category: selectedCategory.value.join(','),
    minPrice: priceRange.value[0],
    maxPrice: priceRange.value[1],
    brands: selectedBrands.value.join(','),
    sort: sortBy.value,
    page: currentPage.value,
    limit: 24
  })),
  // Transform response for easier use
  transform: (response: ProductsResponse) => {
    return {
      ...response,
      products: response.products.map(product => ({
        ...product,
        discountPercentage: product.originalPrice 
          ? Math.round(((product.originalPrice - product.price) / product.originalPrice) * 100)
          : 0
      }))
    }
  }
})

// Extract computed properties from server data
const products = computed(() => productsData.value?.products || [])
const totalProducts = computed(() => productsData.value?.total || 0)
const categories = computed(() => productsData.value?.categories || [])
const brands = computed(() => productsData.value?.brands || [])
const hasMoreProducts = computed(() => productsData.value?.hasMore || false)

// Load more products state
const loadingMore = ref(false)
const allProducts = ref<Product[]>([])

// Initialize all products with server data
onMounted(() => {
  allProducts.value = [...products.value]
})

// Handle filter changes with URL sync
const handleFiltersChange = useDebounceFn(async () => {
  // Update URL without page reload
  await router.push({
    query: {
      ...route.query,
      category: selectedCategory.value.length ? selectedCategory.value.join(',') : undefined,
      minPrice: priceRange.value[0] !== 0 ? priceRange.value[0] : undefined,
      maxPrice: priceRange.value[1] !== 1000 ? priceRange.value[1] : undefined,
      brands: selectedBrands.value.length ? selectedBrands.value.join(',') : undefined,
      sort: sortBy.value !== 'relevance' ? sortBy.value : undefined,
      page: undefined // Reset page when filters change
    }
  })

  // Reset pagination
  currentPage.value = 1
  allProducts.value = []

  // Refresh products with new filters
  await refreshProducts()
  allProducts.value = [...products.value]
}, 300)

// Load more products (pagination)
const loadMoreProducts = async () => {
  if (loadingMore.value || !hasMoreProducts.value) return

  loadingMore.value = true
  currentPage.value++

  try {
    const moreProducts = await $fetch<ProductsResponse>('/api/products', {
      query: {
        ...filters.value,
        page: currentPage.value
      }
    })

    // Append new products to existing list
    allProducts.value.push(...moreProducts.products)

    // Update hasMore flag
    productsData.value = {
      ...productsData.value!,
      hasMore: moreProducts.hasMore,
      page: currentPage.value
    }

  } catch (error) {
    console.error('Failed to load more products:', error)
    currentPage.value-- // Revert page increment
  } finally {
    loadingMore.value = false
  }
}

// Cart functionality
const handleAddToCart = async (product: Product) => {
  try {
    await $fetch('/api/cart/add', {
      method: 'POST',
      body: { productId: product.id, quantity: 1 }
    })

    // Refresh cart data across the app
    await refreshNuxtData('user-cart')

    showSuccessNotification(`${product.name} added to cart!`)
  } catch (error) {
    showErrorNotification('Failed to add product to cart')
  }
}

const handleQuickView = (product: Product) => {
  // Open quick view modal
  navigateTo(`/products/${product.id}?modal=true`)
}

// Watch for route changes (back/forward navigation)
watch(
  () => route.query,
  (newQuery) => {
    // Update local state from URL
    selectedCategory.value = newQuery.category ? String(newQuery.category).split(',') : []
    selectedBrands.value = newQuery.brands ? String(newQuery.brands).split(',') : []
    sortBy.value = String(newQuery.sort) || 'relevance'
    priceRange.value = [
      Number(newQuery.minPrice) || 0,
      Number(newQuery.maxPrice) || 1000
    ]
  },
  { immediate: false }
)
</script>

Dynamic Product Page with Related Products

<!-- pages/products/[id].vue -->
<template>
  <div class="product-page">
    <nav class="breadcrumb">
      <NuxtLink to="/products">Products</NuxtLink>
      <span>/</span>
      <NuxtLink :to="`/products?category=${product?.category}`">
        {{ product?.category }}
      </NuxtLink>
      <span>/</span>
      <span>{{ product?.name }}</span>
    </nav>

    <main class="product-main">
      <section class="product-gallery">
        <ProductImageGallery :images="product?.images || []" />
      </section>

      <section class="product-info">
        <header class="product-header">
          <h1>{{ product?.name }}</h1>
          <div class="rating">
            <StarRating :rating="product?.rating || 0" />
            <span>({{ product?.reviewCount }} reviews)</span>
          </div>
        </header>

        <div class="price-section">
          <span class="current-price">${{ product?.price }}</span>
          <span v-if="product?.originalPrice" class="original-price">
            ${{ product.originalPrice }}
          </span>
          <span v-if="discountPercentage > 0" class="discount-badge">
            {{ discountPercentage }}% OFF
          </span>
        </div>

        <div class="product-options">
          <ProductVariants 
            v-if="product?.variants"
            v-model:selected="selectedVariant"
            :variants="product.variants"
          />

          <div class="quantity-section">
            <label>Quantity:</label>
            <QuantitySelector v-model="quantity" :max="product?.stock || 0" />
          </div>
        </div>

        <div class="action-buttons">
          <button 
            @click="addToCart" 
            :disabled="!product?.inStock || addingToCart"
            class="add-to-cart-btn primary"
          >
            {{ addingToCart ? 'Adding...' : 'Add to Cart' }}
          </button>

          <button @click="buyNow" class="buy-now-btn secondary">
            Buy Now
          </button>

          <button @click="toggleWishlist" class="wishlist-btn">
            {{ isInWishlist ? '❤️' : '🤍' }}
          </button>
        </div>

        <div class="product-details">
          <ProductTabs 
            :description="product?.description"
            :specifications="product?.specifications"
            :reviews="reviews"
            :shipping-info="shippingInfo"
          />
        </div>
      </section>
    </main>

    <section class="related-products">
      <h2>You might also like</h2>
      <div class="related-grid">
        <ProductCard 
          v-for="relatedProduct in relatedProducts" 
          :key="relatedProduct.id"
          :product="relatedProduct"
          size="compact"
        />
      </div>
    </section>
  </div>
</template>

<script setup lang="ts">
interface ProductVariant {
  id: number
  name: string
  value: string
  priceModifier: number
}

interface DetailedProduct {
  id: number
  name: string
  price: number
  originalPrice?: number
  rating: number
  reviewCount: number
  description: string
  specifications: Record<string, string>
  images: string[]
  category: string
  brand: string
  inStock: boolean
  stock: number
  variants?: ProductVariant[]
}

interface Review {
  id: number
  author: string
  rating: number
  comment: string
  createdAt: string
}

const route = useRoute()
const productId = route.params.id as string

// SERVER-SIDE HYDRATION: Product data loaded on server
const { data: product } = await $fetch<DetailedProduct>(`/api/products/${productId}`, {
  key: `product-${productId}`,
  server: true, // Ensures SSR
  default: () => null
})

// Handle 404 case
if (!product.value) {
  throw createError({
    statusCode: 404,
    statusMessage: 'Product not found'
  })
}

// SEO optimization with product data
useHead({
  title: `${product.value.name} - Your Store`,
  meta: [
    { name: 'description', content: product.value.description },
    { property: 'og:title', content: product.value.name },
    { property: 'og:description', content: product.value.description },
    { property: 'og:image', content: product.value.images[0] },
    { property: 'product:price:amount', content: String(product.value.price) },
    { property: 'product:price:currency', content: 'USD' }
  ]
})

// SERVER-SIDE HYDRATION: Related products and reviews
const [{ data: relatedProducts }, { data: reviews }, { data: shippingInfo }] = await Promise.all([
  $fetch<Product[]>(`/api/products/${productId}/related`, {
    key: `related-products-${productId}`,
    server: true,
    default: () => []
  }),
  $fetch<Review[]>(`/api/products/${productId}/reviews`, {
    key: `product-reviews-${productId}`,
    server: true,
    default: () => []
  }),
  $fetch(`/api/shipping-info`, {
    key: 'shipping-info',
    server: true,
    default: () => ({ estimatedDays: '3-5', cost: 'Free over $50' })
  })
])

// Reactive state
const selectedVariant = ref<ProductVariant | null>(null)
const quantity = ref(1)
const addingToCart = ref(false)
const isInWishlist = ref(false)

// Computed properties
const discountPercentage = computed(() => {
  if (!product.value?.originalPrice) return 0
  return Math.round(((product.value.originalPrice - product.value.price) / product.value.originalPrice) * 100)
})

const finalPrice = computed(() => {
  let price = product.value?.price || 0
  if (selectedVariant.value) {
    price += selectedVariant.value.priceModifier
  }
  return price
})

// Check wishlist status on mount
onMounted(async () => {
  try {
    const wishlistStatus = await $fetch(`/api/wishlist/status/${productId}`)
    isInWishlist.value = wishlistStatus.inWishlist
  } catch (error) {
    // User not logged in or other error
    isInWishlist.value = false
  }
})

// Cart functionality
const addToCart = async () => {
  if (!product.value || addingToCart.value) return

  addingToCart.value = true

  try {
    await $fetch('/api/cart/add', {
      method: 'POST',
      body: {
        productId: product.value.id,
        quantity: quantity.value,
        variantId: selectedVariant.value?.id
      }
    })

    // Refresh cart data globally
    await refreshNuxtData('user-cart')

    showSuccessNotification(`${product.value.name} added to cart!`)

  } catch (error) {
    showErrorNotification('Failed to add product to cart')
  } finally {
    addingToCart.value = false
  }
}

const buyNow = async () => {
  await addToCart()
  if (!addingToCart.value) {
    navigateTo('/checkout')
  }
}

const toggleWishlist = async () => {
  const wasInWishlist = isInWishlist.value

  // Optimistic update
  isInWishlist.value = !wasInWishlist

  try {
    await $fetch(`/api/wishlist/${productId}`, {
      method: wasInWishlist ? 'DELETE' : 'POST'
    })

    showSuccessNotification(
      wasInWishlist ? 'Removed from wishlist' : 'Added to wishlist'
    )

  } catch (error) {
    // Rollback optimistic update
    isInWishlist.value = wasInWishlist
    showErrorNotification('Failed to update wishlist')
  }
}
</script>

The Server-Side Hydration Magic:

No Loading Spinners: Data is fetched on the server, so users see content immediately
SEO Optimized: Search engines see fully rendered content with proper meta tags
Performance: Critical data loads with the initial HTML, non-critical data can load asynchronously
Error Handling: 404 errors are handled server-side before the page renders

Advanced Patterns and Best Practices

Custom Data Layer Composables

Create reusable composables for common data patterns:

// composables/useApiResource.ts
interface UseApiResourceOptions<T> {
  key: string
  endpoint: string
  server?: boolean
  transform?: (data: any) => T
  default?: () => T
  dependencies?: ComputedRef<any>[]
}

export function useApiResource<T>(options: UseApiResourceOptions<T>) {
  const {
    key,
    endpoint,
    server = true,
    transform,
    default: defaultValue,
    dependencies = []
  } = options

  // Create reactive endpoint URL
  const apiEndpoint = computed(() => {
    let url = endpoint

    // Replace placeholders with dependency values
    dependencies.forEach((dep, index) => {
      url = url.replace(`{${index}}`, String(dep.value))
    })

    return url
  })

  // Use enhanced $fetch with all the bells and whistles
  const {
    data,
    pending,
    error,
    refresh
  } = $fetch<T>(apiEndpoint, {
    key: computed(() => `${key}-${dependencies.map(d => d.value).join('-')}`),
    server,
    default: defaultValue,
    transform,
    // Automatically refresh when dependencies change
    watch: dependencies
  })

  // Enhanced refresh with error handling
  const safeRefresh = async () => {
    try {
      await refresh()
    } catch (error) {
      console.error(`Failed to refresh ${key}:`, error)
      throw error
    }
  }

  // Invalidate related caches
  const invalidate = async (pattern?: string) => {
    await clearNuxtData(pattern || key)
  }

  return {
    data: readonly(data),
    pending: readonly(pending),
    error: readonly(error),
    refresh: safeRefresh,
    invalidate
  }
}

// Usage in components:
const userId = computed(() => route.params.id)
const { data: user, pending, refresh } = useApiResource({
  key: 'user-profile',
  endpoint: '/api/users/{0}',
  dependencies: [userId],
  transform: (response) => response.user
})

Data Synchronization Across Tabs

Implement cross-tab synchronization for real-time updates:

// composables/useCrossTabSync.ts
export function useCrossTabSync(key: string) {
  const channel = new BroadcastChannel(`nuxt-data-${key}`)

  // Listen for updates from other tabs
  channel.addEventListener('message', (event) => {
    if (event.data.type === 'DATA_UPDATE') {
      // Refresh data in current tab
      refreshNuxtData(key)
    }
  })

  // Broadcast updates to other tabs
  const broadcast = (data: any) => {
    channel.postMessage({
      type: 'DATA_UPDATE',
      key,
      data,
      timestamp: Date.now()
    })
  }

  // Cleanup on unmount
  onUnmounted(() => {
    channel.close()
  })

  return { broadcast }
}

Conclusion: Mastering the New Data Layer

Nuxt's revolutionary data layer transforms how we think about data management in modern web applications. These five features work together to create a seamless, performant, and developer-friendly experience:

Reactive Server State eliminates the complexity of manual state synchronization
Advanced Caching provides intelligent performance optimization without the headaches
Cross-Component Synchronization removes the need for complex state management libraries
Optimistic Updates create lightning-fast user experiences with automatic rollback
Server-Side Hydration ensures perfect SEO and instant page loads

The examples in this guide demonstrate real-world scenarios where these features shine. From e-commerce platforms to social media applications, the new data layer adapts to your needs while maintaining simplicity and performance.

Key Takeaways for Implementation:

Always use meaningful cache keys for proper deduplication
Implement optimistic updates for better user experience
Leverage server-side hydration for critical above-the-fold content
Use conditional fetching to avoid unnecessary requests
Create reusable composables for common patterns
Implement proper error handling and rollback strategies

The future of Nuxt development is here, and it's more powerful and intuitive than ever. Embrace these new data layer features, and watch your applications become faster, more reliable, and easier to maintain. Your users will thank you, and your future self will too!

Happy coding with Nuxt's incredible new data layer! 🚀

The Art of Props Management in Vue 3: Lessons from E-commerce Architecture

Marco Quintella — Tue, 20 May 2025 15:00:00 +0000

In the sprawling world of multi-brand e-commerce platforms, where a single codebase powers numerous storefronts, component communication becomes an intricate dance. Imagine a digital mall where every shop has its own facade, but behind the scenes, they share the same foundational infrastructure. This is the reality for many large e-commerce operations today.

As a developer navigating this complex landscape, mastering Vue's props system isn't just helpful, it's ESSENTIAL. Let's explore how to elegantly handle props in Vue 3 using TypeScript and the Composition API, drawing from real-world e-commerce scenarios.

The Props Journey: From Parent to Child

In a multi-brand e-commerce platform, props travel like products through a supply chain. They originate from a source and make their way through various components until they reach their final destination. Understanding this journey is the first step in becoming a props master.

Basic Props in Vue 3 with TypeScript

Let's start with a product card component, a fundamental element in any e-commerce site:

<script setup lang="ts">
// ProductCard.vue
defineProps<{
  product: {
    id: string;
    name: string;
    price: number;
    imageUrl: string;
    brand: string;
    isOnSale?: boolean;
  };
  showRating?: boolean;
  theme?: 'light' | 'dark' | 'branded';
}>();
</script>

<template>
  <div class="product-card" :class="theme">
    <img :src="product.imageUrl" :alt="product.name" />
    <h3>{{ product.name }}</h3>
    <p class="price" :class="{ 'on-sale': product.isOnSale }">
      ${{ product.price.toFixed(2) }}
    </p>
    <p class="brand">{{ product.brand }}</p>
    <star-rating v-if="showRating" :product-id="product.id" />
  </div>
</template>

In this example, we have a product card that can be customized based on the brand's requirements. The theme prop allows for different visual styles, while showRating toggles the visibility of the rating component.

The Props Cascade: When Components Go Deep

Now, imagine we're building a product listing page. We have multiple levels of components:

ProductListingPage (contains multiple product categories)
ProductCategory (contains multiple product rows)
ProductRow (contains multiple product cards)
ProductCard (displays individual product)

Each level needs to pass certain props down to its children. This is where props management becomes crucial.

The Prop-Drilling Problem

Consider this scenario: we need to pass a currency setting from the top-level component down to the product cards. The traditional approach would be:

<script setup lang="ts">
// ProductListingPage.vue
const currency = ref('USD');
</script>

<template>
  <product-category 
    v-for="category in categories" 
    :key="category.id" 
    :category="category" 
    :currency="currency"
  />
</template>

<script setup lang="ts">
// ProductCategory.vue
defineProps<{
  category: { id: string; name: string; products: Product[] };
  currency: string;
}>();
</script>

<template>
  <product-row 
    v-for="(row, index) in productRows" 
    :key="index" 
    :products="row" 
    :currency="currency"
  />
</template>

<script setup lang="ts">
// ProductRow.vue
defineProps<{
  products: Product[];
  currency: string;
}>();
</script>

<template>
  <product-card 
    v-for="product in products" 
    :key="product.id" 
    :product="product" 
    :currency="currency"
  />
</template>

<script setup lang="ts">
// ProductCard.vue (updated)
defineProps<{
  product: Product;
  currency: string;
  showRating?: boolean;
  theme?: 'light' | 'dark' | 'branded';
}>();
</script>

<template>
  <div class="product-card" :class="theme">
    <!-- ... -->
    <p class="price" :class="{ 'on-sale': product.isOnSale }">
      {{ formatPrice(product.price, currency) }}
    </p>
    <!-- ... -->
  </div>
</template>

This approach, known as "prop drilling," quickly becomes unwieldy. The currency prop must pass through ProductCategory and ProductRow even though these components don't use it themselves.

Elegant Solutions for Props Management

1. Using Provide/Inject for Deep Props

One of the most elegant solutions to avoid prop drilling is using Vue's provide and inject features:

<script setup lang="ts">
// ProductListingPage.vue
import { provide, ref } from 'vue';

const currency = ref('USD');
// The provide key should be a symbol in real applications for type safety
provide('currency', currency);
</script>

<template>
  <product-category 
    v-for="category in categories" 
    :key="category.id" 
    :category="category"
  />
</template>

Then, in the ProductCard.vue component:

<script setup lang="ts">
import { inject } from 'vue';

defineProps<{
  product: Product;
  showRating?: boolean;
  theme?: 'light' | 'dark' | 'branded';
}>();

// TypeScript might need a default value or type assertion
const currency = inject('currency', ref('USD'));
</script>

With this approach, intermediate components like ProductCategory and ProductRow don't need to be aware of the currency prop at all.

2. TypeScript Enhancements for Provide/Inject

To make this approach more robust with TypeScript, we can create a type-safe system:

// types.ts
import { InjectionKey, Ref } from 'vue';

export interface EcommerceConfig {
  currency: Ref<string>;
  priceDisplay: Ref<'withTax' | 'withoutTax'>;
  theme: Ref<'light' | 'dark' | 'branded'>;
}

export const EcommerceConfigKey: InjectionKey<EcommerceConfig> = Symbol('EcommerceConfig');

Then in our root component:

<script setup lang="ts">
import { provide, ref } from 'vue';
import { EcommerceConfigKey } from './types';

const config = {
  currency: ref('USD'),
  priceDisplay: ref('withTax' as const),
  theme: ref('light' as const)
};

provide(EcommerceConfigKey, config);
</script>

And in child components:

<script setup lang="ts">
import { inject } from 'vue';
import { EcommerceConfigKey } from './types';

const { currency, theme } = inject(EcommerceConfigKey)!;
</script>

This pattern is especially valuable in multi-brand e-commerce platforms, where brand-specific settings need to be accessible throughout the component tree.

3. Props Destructuring with Defaults

For direct props usage, Vue 3's Composition API allows for elegant destructuring with defaults:

<script setup lang="ts">
// BrandProductCard.vue
import { computed } from 'vue';

interface Props {
  product: Product;
  showRating?: boolean;
  theme?: 'light' | 'dark' | 'branded';
  brandAccentColor?: string;
}

const props = withDefaults(defineProps<Props>(), {
  showRating: false,
  theme: 'light',
  brandAccentColor: '#e91e63'
});

const cardStyle = computed(() => ({
  '--accent-color': props.brandAccentColor
}));
</script>

<template>
  <div class="product-card" :class="theme" :style="cardStyle">
    <!-- Component content -->
  </div>
</template>

4. Creating Intermediate Components for Props Grouping

When dealing with complex UI elements that require many props, it's often beneficial to create intermediate components that group related props together:

<script setup lang="ts">
// ProductPricing.vue
defineProps<{
  regularPrice: number;
  salePrice?: number;
  currency: string;
  showTax: boolean;
  taxRate?: number;
}>();
</script>

<template>
  <div class="product-pricing">
    <span v-if="salePrice" class="original-price">{{ formatPrice(regularPrice, currency) }}</span>
    <span class="current-price">
      {{ formatPrice(salePrice || regularPrice, currency) }}
    </span>
    <span v-if="showTax" class="tax-info">
      {{ taxRate ? `Includes ${taxRate}% tax` : 'Tax included' }}
    </span>
  </div>
</template>

This specialized component can now be used within the ProductCard component:

<script setup lang="ts">
// ProductCard.vue (simplified)
defineProps<{
  product: Product;
  showTax: boolean;
  currency: string;
}>();
</script>

<template>
  <div class="product-card">
    <!-- Other product info -->
    <product-pricing
      :regular-price="product.price"
      :sale-price="product.salePrice"
      :currency="currency"
      :show-tax="showTax"
      :tax-rate="product.taxRate"
    />
  </div>
</template>

This approach creates logical groupings of props, making the component structure clearer and more maintainable.

Advanced Props Patterns for E-commerce Scenarios

1. Dynamic Props for Multi-brand Customization

In a multi-brand environment, different brands might require different variations of the same component. We can use computed props to handle this:

<script setup lang="ts">
// DynamicProductCard.vue
import { computed } from 'vue';
import { useStoreConfig } from '@/composables/useStoreConfig';

const props = defineProps<{
  product: Product;
  brandId: string;
}>();

// Get store-specific configuration
const storeConfig = useStoreConfig(props.brandId);

// Compute the correct theme based on brand settings
const cardTheme = computed(() => {
  if (storeConfig.value.useDarkMode) return 'dark';
  if (storeConfig.value.useCustomBranding) return 'branded';
  return 'light';
});

// Determine whether to show the product's rating based on brand preference
const shouldShowRating = computed(() => {
  return storeConfig.value.showProductRatings && product.hasRatings;
});
</script>

<template>
  <product-card
    :product="product"
    :theme="cardTheme"
    :show-rating="shouldShowRating"
  />
</template>

This pattern allows for brand-specific customization without cluttering the component's public API.

2. Props Validation and Transformation

For complex e-commerce applications, validating and transforming props becomes increasingly important:

<script setup lang="ts">
// PriceDisplay.vue
import { computed } from 'vue';

interface Props {
  amount: number;
  currency: string;
  format?: 'standard' | 'compact';
}

const props = defineProps<Props>();

// Validate the currency format
const validCurrency = computed(() => {
  const supportedCurrencies = ['USD', 'EUR', 'GBP', 'CAD', 'AUD'];
  return supportedCurrencies.includes(props.currency) ? props.currency : 'USD';
});

// Transform and format the price
const formattedPrice = computed(() => {
  const options = {
    style: 'currency',
    currency: validCurrency.value,
    notation: props.format === 'compact' ? 'compact' as const : 'standard' as const
  };

  return new Intl.NumberFormat(navigator.language, options).format(props.amount);
});
</script>

<template>
  <span class="price">{{ formattedPrice }}</span>
</template>

This component not only displays prices but also validates and normalizes its input props, ensuring consistent behavior across the platform.

3. Using Props for Feature Flagging

In complex e-commerce systems, feature flags are common. Props can be used to implement this pattern:

<script setup lang="ts">
// CheckoutButton.vue
defineProps<{
  productId: string;
  // Feature flags
  enableOneClickCheckout?: boolean;
  enableSaveForLater?: boolean;
  enableWishlist?: boolean;
}>();

// Component logic that adjusts based on enabled features
</script>

<template>
  <div class="checkout-actions">
    <button class="add-to-cart">Add to Cart</button>

    <button 
      v-if="enableOneClickCheckout" 
      class="one-click-checkout"
    >
      Buy Now
    </button>

    <button 
      v-if="enableSaveForLater" 
      class="save-for-later"
    >
      Save for Later
    </button>

    <button 
      v-if="enableWishlist" 
      class="add-to-wishlist"
    >
      Add to Wishlist
    </button>
  </div>
</template>

This approach allows different brands or markets to enable or disable features based on their specific requirements.

Best Practices for Props in Large E-commerce Applications

1. Create Props Interfaces and Types

For complex components, create dedicated interface files:

// types/product-card.types.ts
export interface ProductCardProps {
  product: Product;
  showRating?: boolean;
  theme?: 'light' | 'dark' | 'branded';
  enableQuickView?: boolean;
  enableWishlist?: boolean;
}

// Then in your component
import { ProductCardProps } from '@/types/product-card.types';

defineProps<ProductCardProps>();

This approach centralizes prop definitions and makes them reusable across components.

2. Use Composables for Complex Props Logic

When prop handling logic becomes complex, extract it into composables:

// composables/useProductDisplay.ts
import { computed, ComputedRef } from 'vue';
import type { Product } from '@/types';

interface ProductDisplayOptions {
  product: Product;
  currency: string;
  showTax: boolean;
}

export function useProductDisplay(options: ProductDisplayOptions) {
  const formattedPrice = computed(() => {
    // Price formatting logic
    return formatPrice(options.product.price, options.currency);
  });

  const displayName = computed(() => {
    // Product name formatting logic
    return options.product.brand 
      ? `${options.product.brand} - ${options.product.name}`
      : options.product.name;
  });

  const taxInfo = computed(() => {
    // Tax display logic
    if (!options.showTax) return null;
    // Calculate and return tax information
  });

  return {
    formattedPrice,
    displayName,
    taxInfo
  };
}

// In your component
const { formattedPrice, displayName, taxInfo } = useProductDisplay({
  product: props.product,
  currency: props.currency,
  showTax: props.showTax
});

This pattern keeps components clean and focused on rendering, while complex business logic lives in dedicated composables.

3. Document Props with JSDoc

Documentation is essential in large teams. Use JSDoc to document your props:

<script setup lang="ts">
/**
 * Product Card component for displaying product information
 * @prop {Product} product - The product data object
 * @prop {boolean} [showRating=false] - Whether to display product ratings
 * @prop {'light'|'dark'|'branded'} [theme='light'] - Visual theme for the card
 * @prop {string} [currency='USD'] - Currency code for price display
 */
defineProps<{
  product: Product;
  showRating?: boolean;
  theme?: 'light' | 'dark' | 'branded';
  currency?: string;
}>();
</script>

This documentation helps other developers understand your component's API without digging into the implementation.

Conclusion: The Art of Props Mastery

In large e-commerce platforms that power multiple brands, effective props management is both an art and a science. By leveraging Vue 3's modern features like the Composition API, TypeScript integration, and provide/inject pattern, we can create component architectures that are both powerful and maintainable.

Remember these key takeaways:

Use provide/inject for deeply nested props and application-wide settings
Create specialized intermediate components to group related props
Leverage TypeScript for type safety and better developer experience
Extract complex prop handling logic into composables
Document your component APIs thoroughly

By mastering these patterns, you'll be well-equipped to build scalable, maintainable component systems that can support multiple brands and evolving business requirements in the complex world of e-commerce.

Comprehensive Guide to Pinia for State Management in Vue.js

Marco Quintella — Sat, 17 May 2025 20:54:36 +0000

The first time I encountered state management in Vue, I was overwhelmed. I was building a simple dashboard application that had grown from a weekend project into something much more complex. Components were passing props six levels deep, and emitting events that would get lost in the hierarchy. I remember thinking, "There has to be a better way."

That's when I discovered Vuex. It felt like finding an oasis in the desert. But as time passed and my projects grew more complex, I started to feel the pain points. The boilerplate code, the mutations that seemed redundant, the TypeScript support that always felt a bit bolted on rather than built-in.

Then came Pinia, and it was like a breath of fresh air. In this article, I want to share my journey with Pinia, how it transformed my approach to state management in Vue, and why it might just change yours too.

The Evolution of State Management in Vue

When I first started with Vue, I did what most of us do - I used component state and props. For small applications, this works wonderfully. Vue's reactivity system is elegant and intuitive. But as my applications grew, this approach started to crumble.

I still remember the day I implemented Vuex on a team project. It was revolutionary for us. Suddenly, we had a central source of truth for our application state. Components could access what they needed without complex prop drilling or event bubbling. But Vuex came with its own challenges.

"Why do I need to define a mutation just to update a simple counter?" a teammate once asked me. I didn't have a good answer beyond "that's just how Vuex works." The separation between mutations and actions often felt artificial, especially to team members coming from other frameworks.

Enter Pinia. Created by Eduardo San Martin Morote (a Vue core team member), Pinia reimagined what state management in Vue could be. The name "Pinia" comes from the Spanish word "piña" (pineapple), reflecting how its modular stores connect together, much like the segments of a pineapple.

Why Pinia Won My Heart

The first time I refactored a Vuex store to Pinia, I was shocked at how much code I deleted. Gone were the repetitive mutations that simply assigned values to state. Gone was the constant switching between files to trace how a single state change flowed through the system.

Simplicity: Less Code, More Joy

Let me show you what I mean. Here's a simple counter store in Vuex:

// Vuex store
export default {
  state: {
    count: 0
  },
  getters: {
    doubleCount: state => state.count * 2
  },
  mutations: {
    INCREMENT(state) {
      state.count++
    },
    DECREMENT(state) {
      state.count--
    }
  },
  actions: {
    increment({ commit }) {
      commit('INCREMENT')
    },
    decrement({ commit }) {
      commit('DECREMENT')
    }
  }
}

And here's the same thing in Pinia:

// Pinia store
import { defineStore } from 'pinia'

export const useCounterStore = defineStore('counter', {
  state: () => ({
    count: 0
  }),
  getters: {
    doubleCount: (state) => state.count * 2
  },
  actions: {
    increment() {
      this.count++
    },
    decrement() {
      this.count--
    }
  }
})

Not only is it less code, but it's also more intuitive. No more committing mutations from actions - you just update the state directly. This was a game-changer for our team's productivity and for onboarding new developers.

TypeScript: A Match Made in Heaven

If you've ever tried to add TypeScript to a Vuex project, you know it can be... challenging. I spent countless hours wrestling with complex type definitions and store accessors that never quite felt right.

Pinia, on the other hand, was built with TypeScript in mind from day one. The first time I saw perfect autocompletion in my IDE for a Pinia store, I almost cried with joy. Every property, getter, and action was properly typed without any additional work on my part.

For example, defining a typed store in Pinia feels natural:

interface User {
  id: number;
  name: string;
  email: string;
}

export const useUserStore = defineStore('user', {
  state: () => ({
    user: null as User | null,
    isLoading: false
  }),
  actions: {
    async fetchUser(id: number) {
      this.isLoading = true;
      try {
        this.user = await api.getUser(id);
      } finally {
        this.isLoading = false;
      }
    }
  }
});

The TypeScript support isn't just nice-to-have; it's a productivity booster. The number of runtime errors we caught at compile time after switching to Pinia was remarkable.

Modular by Design: Breaking Down the Monolith

One of my biggest frustrations with large Vuex applications was the tendency to create a monolithic store. Yes, Vuex has modules, but they always felt like an afterthought.

Pinia embraces modularity from the ground up. Each store is defined and imported separately, which leads to better code organization and, crucially, better tree-shaking. Unused stores won't be included in your production bundle, which can lead to significant size reductions.

I still remember when I reorganized our main application store from a single Vuex store with modules to separate Pinia stores. The bundle size decreased by nearly 15%, and the application felt noticeably snappier.

Getting Started: My First Pinia Store

Let me walk you through setting up Pinia in a project, just as I did when I first discovered it.

Installation: Quick and Painless

Adding Pinia to a Vue project is straightforward:

npm install pinia
# or if you're a yarn person like me
yarn add pinia

Then, in your main.js file, you create a Pinia instance and install it as a plugin:

import { createApp } from 'vue'
import { createPinia } from 'pinia'
import App from './App.vue'

const app = createApp(App)
const pinia = createPinia()

app.use(pinia)
app.mount('#app')

That's it! No complex configuration, no boilerplate. Just install, create, and use.

Creating My First Store: A Revelation

The first store I created with Pinia was for user authentication. Authentication state is often complex, with multiple related pieces of data (user details, tokens, loading states) and asynchronous actions (login, logout, token refresh).

Here's how I structured it:

// stores/auth.js
import { defineStore } from 'pinia'
import api from '@/api/auth'

export const useAuthStore = defineStore('auth', {
  state: () => ({
    user: null,
    token: localStorage.getItem('auth_token'),
    isLoading: false,
    error: null
  }),

  getters: {
    isAuthenticated: (state) => !!state.token && !!state.user,
    username: (state) => state.user?.username || 'Guest'
  },

  actions: {
    async login(credentials) {
      this.isLoading = true;
      this.error = null;

      try {
        const { user, token } = await api.login(credentials);
        this.user = user;
        this.token = token;
        localStorage.setItem('auth_token', token);
        return user;
      } catch (error) {
        this.error = error.message;
        throw error;
      } finally {
        this.isLoading = false;
      }
    },

    logout() {
      this.user = null;
      this.token = null;
      localStorage.removeItem('auth_token');
    }
  }
});

Using this store in a component was equally simple:

<template>
  <div>
    <div v-if="isLoading">Loading...</div>
    <form v-else-if="!isAuthenticated" @submit.prevent="handleLogin">
      <input v-model="email" placeholder="Email" />
      <input v-model="password" placeholder="Password" type="password" />
      <div v-if="error" class="error">{{ error }}</div>
      <button type="submit">Login</button>
    </form>
    <div v-else>
      <p>Welcome, {{ username }}!</p>
      <button @click="logout">Logout</button>
    </div>
  </div>
</template>

<script>
import { ref } from 'vue'
import { useAuthStore } from '@/stores/auth'
import { storeToRefs } from 'pinia'

export default {
  setup() {
    const authStore = useAuthStore();
    const { isAuthenticated, username, error, isLoading } = storeToRefs(authStore);
    const { login, logout } = authStore;

    const email = ref('');
    const password = ref('');

    async function handleLogin() {
      try {
        await login({
          email: email.value,
          password: password.value
        });
        // Success! Maybe redirect or show a welcome message
      } catch (err) {
        // Error handling is already in the store
      }
    }

    return {
      email,
      password,
      handleLogin,
      logout,
      isAuthenticated,
      username,
      error,
      isLoading
    };
  }
}
</script>

Notice the storeToRefs function? That's another gem from Pinia. It lets you destructure store properties while keeping their reactivity, something that wouldn't work with a plain object destructure.

The Composition API and Pinia: A Perfect Match

When Vue 3 introduced the Composition API, it changed how I structured my components. Instead of the options API (data, computed, methods), I could organize code by feature rather than by type.

Pinia embraced this philosophy wholeheartedly with the setup store syntax. This was a revelation for me - I could define stores using the same Composition API functions I was already using in components.

Here's how I refactored our counter store using the setup syntax:

import { defineStore } from 'pinia'
import { ref, computed } from 'vue'

export const useCounterStore = defineStore('counter', () => {
  // State
  const count = ref(0)

  // Getters
  const doubleCount = computed(() => count.value * 2)

  // Actions
  function increment() {
    count.value++
  }

  function decrement() {
    count.value--
  }

  return {
    count,
    doubleCount,
    increment,
    decrement
  }
})

This approach felt so natural and consistent with how I was already writing Vue 3 components. The first time I showed this to my team, there was a collective "aha" moment. The learning curve for new team members practically disappeared - if you know the Composition API, you know how to write Pinia stores.

Real-World Pinia: Building a Task Management App

Let me share a real-world example from a project I worked on - a task management application for internal team use. This application had multiple interconnected pieces of state:

Tasks with various properties (title, description, due date, assignee, etc.)
User authentication and profiles
UI state (filters, sorting, theme preferences)

In the past, I might have crammed all of this into a single Vuex store with modules. With Pinia, I naturally separated these concerns into distinct stores.

The Task Store: Heart of the Application

The task store managed all task-related data and operations:

// stores/taskStore.js
import { defineStore } from 'pinia'
import { useUserStore } from './userStore'
import api from '@/api/tasks'

export const useTaskStore = defineStore('tasks', {
  state: () => ({
    tasks: [],
    isLoading: false,
    error: null
  }),

  getters: {
    completedTasks: (state) => state.tasks.filter(task => task.completed),
    pendingTasks: (state) => state.tasks.filter(task => !task.completed),

    getTaskById: (state) => (id) => {
      return state.tasks.find(task => task.id === id)
    },

    tasksByAssignee: (state) => {
      const grouped = {};
      for (const task of state.tasks) {
        const assigneeId = task.assigneeId;
        if (!grouped[assigneeId]) {
          grouped[assigneeId] = [];
        }
        grouped[assigneeId].push(task);
      }
      return grouped;
    }
  },

  actions: {
    async fetchTasks() {
      this.isLoading = true;
      this.error = null;

      try {
        const tasks = await api.getTasks();
        this.tasks = tasks;
      } catch (error) {
        this.error = error.message;
        console.error('Failed to fetch tasks:', error);
      } finally {
        this.isLoading = false;
      }
    },

    async addTask(taskData) {
      const userStore = useUserStore();

      if (!userStore.isAuthenticated) {
        throw new Error('You must be logged in to add a task');
      }

      // Add the current user as the creator
      const enrichedTask = {
        ...taskData,
        creatorId: userStore.user.id,
        createdAt: new Date().toISOString()
      };

      this.isLoading = true;

      try {
        const newTask = await api.createTask(enrichedTask);
        this.tasks.push(newTask);
        return newTask;
      } catch (error) {
        this.error = error.message;
        throw error;
      } finally {
        this.isLoading = false;
      }
    },

    async toggleTaskCompletion(taskId) {
      const task = this.getTaskById(taskId);

      if (!task) {
        throw new Error(`Task with ID ${taskId} not found`);
      }

      const updatedTask = {
        ...task,
        completed: !task.completed,
        completedAt: !task.completed ? new Date().toISOString() : null
      };

      try {
        await api.updateTask(taskId, updatedTask);

        // Update local state
        const index = this.tasks.findIndex(t => t.id === taskId);
        this.tasks[index] = updatedTask;
      } catch (error) {
        this.error = error.message;
        throw error;
      }
    }
  }
});

Notice how this store interacts with the user store? This is one of my favorite aspects of Pinia - stores can easily use other stores. The task store needs user information when creating tasks, and it can simply import and use the user store.

Using the Task Store in Components

With this store defined, using it in components became straightforward:

<template>
  <div class="task-list">
    <div v-if="isLoading" class="loading">Loading tasks...</div>

    <div v-else-if="error" class="error">{{ error }}</div>

    <div v-else>
      <div v-for="task in displayedTasks" :key="task.id" class="task-item">
        <input 
          type="checkbox" 
          :checked="task.completed" 
          @change="toggleTaskCompletion(task.id)" 
        />
        <span :class="{ completed: task.completed }">{{ task.title }}</span>
        <span class="assignee">
          Assigned to: {{ getUserName(task.assigneeId) }}
        </span>
      </div>

      <div v-if="displayedTasks.length === 0" class="empty-state">
        No tasks found. Add your first task to get started!
      </div>
    </div>

    <button @click="openAddTaskModal" class="add-task-btn">
      Add New Task
    </button>
  </div>
</template>

<script>
import { computed } from 'vue'
import { storeToRefs } from 'pinia'
import { useTaskStore } from '@/stores/taskStore'
import { useUserStore } from '@/stores/userStore'
import { useUIStore } from '@/stores/uiStore'

export default {
  setup() {
    const taskStore = useTaskStore();
    const userStore = useUserStore();
    const uiStore = useUIStore();

    // Extract reactive properties
    const { tasks, isLoading, error } = storeToRefs(taskStore);
    const { taskFilter } = storeToRefs(uiStore);

    // Load tasks when component mounts
    taskStore.fetchTasks();

    // Computed property for filtered tasks
    const displayedTasks = computed(() => {
      if (taskFilter.value === 'completed') {
        return taskStore.completedTasks;
      } else if (taskFilter.value === 'pending') {
        return taskStore.pendingTasks;
      }
      return tasks.value;
    });

    // Helper function to get user names
    function getUserName(userId) {
      return userStore.getUserById(userId)?.name || 'Unassigned';
    }

    function openAddTaskModal() {
      uiStore.openModal('addTask');
    }

    return {
      displayedTasks,
      isLoading,
      error,
      toggleTaskCompletion: taskStore.toggleTaskCompletion,
      getUserName,
      openAddTaskModal
    };
  }
}
</script>

What I love about this approach is how clean the component remains even while using multiple stores. Each store handles its own domain, and the component simply consumes what it needs.

The DevTools Experience: Time Travel Debugging

One of my favorite "wow" moments with Pinia came when I discovered its integration with Vue DevTools. Unlike Vuex, which had its own DevTools panel, Pinia slots right into the Vue DevTools with even more features.

The first time I used time-travel debugging with Pinia, it saved me hours of head-scratching. We had a complex sequence of actions updating multiple stores, and a bug was causing inconsistent state. With time-travel debugging, I could:

Step back through each state change
Inspect the exact sequence of actions
See how each action affected the state
Pinpoint exactly where the bug was occurring

Being able to edit state in real-time through the DevTools was also a game-changer for development speed. Need to test how a component behaves with different state configurations? Just change it in the DevTools without touching your code.

Advanced Techniques: Evolving with Pinia

As our applications grew more complex, I discovered more advanced techniques with Pinia that became essential to our workflow.

Subscribing to Store Changes

One pattern we frequently used was subscribing to store changes for side effects like persistence:

import { useTaskStore } from '@/stores/taskStore'

export default {
  setup() {
    const taskStore = useTaskStore();

    // Save tasks to localStorage whenever they change
    taskStore.$subscribe((mutation, state) => {
      localStorage.setItem('tasks', JSON.stringify(state.tasks));
    });

    return { taskStore };
  }
}

This was particularly useful for implementing persistent state across page reloads without having to manually save after every action.

Creating Custom Plugins

As our application matured, we started creating custom Pinia plugins to add functionality across all stores. One of my favorites was a simple logging plugin:

export function piniaLogger({ store }) {
  store.$subscribe((mutation, state) => {
    console.log(`[${store.$id}] ${mutation.type}`, {
      mutation,
      state
    });
  });
}

// In main.js
import { piniaLogger } from './plugins/piniaLogger'
const pinia = createPinia()
pinia.use(piniaLogger)

This logged every state change across all stores, which was invaluable for debugging complex interactions.

Another useful plugin we created was for handling API error patterns consistently:

export function piniaErrorHandler({ store }) {
  const originalActions = {};

  // Store original action implementations
  for (const action in store.$actions) {
    originalActions[action] = store[action];

    // Replace with wrapped version
    store[action] = async function(...args) {
      store.error = null;

      try {
        return await originalActions[action].apply(this, args);
      } catch (error) {
        store.error = formatErrorMessage(error);

        // Centralized error reporting
        reportErrorToMonitoring(error, {
          store: store.$id,
          action,
          args
        });

        throw error;
      }
    };
  }
}

This plugin wrapped all actions in every store with consistent error handling, ensuring we never forgot to handle errors and that they were formatted consistently throughout the application.

Testing with Pinia: A Pleasant Surprise

Writing tests for Vuex stores had always been a pain point. With Pinia, testing became significantly easier. Here's how I approached testing our task store:

import { setActivePinia, createPinia } from 'pinia'
import { useTaskStore } from '@/stores/taskStore'
import api from '@/api/tasks'

// Mock the API
jest.mock('@/api/tasks')

describe('Task Store', () => {
  let store;

  beforeEach(() => {
    // Create a fresh Pinia instance for each test
    setActivePinia(createPinia());
    store = useTaskStore();
  });

  test('fetches tasks and updates state', async () => {
    // Setup mock response
    const mockTasks = [
      { id: 1, title: 'Test Task 1', completed: false },
      { id: 2, title: 'Test Task 2', completed: true }
    ];
    api.getTasks.mockResolvedValue(mockTasks);

    // Initial state
    expect(store.tasks).toEqual([]);
    expect(store.isLoading).toBe(false);

    // Call the action
    await store.fetchTasks();

    // Verify loading state changed during the operation
    expect(api.getTasks).toHaveBeenCalled();

    // Verify final state
    expect(store.tasks).toEqual(mockTasks);
    expect(store.isLoading).toBe(false);
    expect(store.error).toBeNull();
  });

  test('handles API errors correctly', async () => {
    // Setup mock to throw error
    const errorMessage = 'Network error';
    api.getTasks.mockRejectedValue(new Error(errorMessage));

    // Call the action
    await store.fetchTasks();

    // Verify error state
    expect(store.tasks).toEqual([]);
    expect(store.isLoading).toBe(false);
    expect(store.error).toBe(errorMessage);
  });
});

Testing components that use Pinia stores also became simpler with the @pinia/testing package:

import { mount } from '@vue/test-utils'
import { createTestingPinia } from '@pinia/testing'
import TaskList from '@/components/TaskList.vue'
import { useTaskStore } from '@/stores/taskStore'

test('Task list displays tasks correctly', async () => {
  // Create a component with mocked Pinia
  const wrapper = mount(TaskList, {
    global: {
      plugins: [
        createTestingPinia({
          initialState: {
            tasks: {
              tasks: [
                { id: 1, title: 'Test Task', completed: false }
              ],
              isLoading: false,
              error: null
            }
          }
        })
      ]
    }
  });

  // Get store after mounting component
  const taskStore = useTaskStore();

  // Verify component displays task
  expect(wrapper.text()).toContain('Test Task');

  // Verify store actions are mocked
  expect(taskStore.fetchTasks).toHaveBeenCalledTimes(1);
});

This approach allowed us to pre-populate store state for component tests, ensuring components rendered correctly with different state configurations.

Migrating from Vuex: A Team's Journey

When we decided to migrate our main application from Vuex to Pinia, I expected resistance. Changes to core architecture usually cause friction. To my surprise, the team was enthusiastic after seeing a small proof-of-concept.

Our migration strategy was incremental:

Install Pinia alongside Vuex
Migrate one module at a time, starting with the simplest
Update components to use the new Pinia stores
Eventually remove Vuex completely

The process was surprisingly smooth. The most challenging part was updating components that relied heavily on Vuex mapping helpers. For those, we used Pinia's own mapping utilities:

import { mapStores, mapState, mapActions } from 'pinia'
import { useUserStore } from '@/stores/user'
import { useTaskStore } from '@/stores/task'

export default {
  computed: {
    ...mapStores([useUserStore, useTaskStore]),
    ...mapState(useUserStore, ['user', 'isAuthenticated']),
    ...mapState(useTaskStore, {
      pendingTasks: store => store.tasks.filter(t => !t.completed)
    })
  },
  methods: {
    ...mapActions(useTaskStore, ['fetchTasks', 'addTask'])
  }
}

This provided a familiar API for developers accustomed to Vuex while we gradually transitioned to the more modern Composition API approach.

Performance Optimizations: Scaling with Pinia

As our application grew to tens of thousands of users, we needed to optimize performance. Pinia proved excellent for performance tuning with a few key techniques.

Batching Updates

When making multiple state changes, we used the $patch method to batch them together:

// Instead of individual updates
taskStore.isLoading = false;
taskStore.error = null;
taskStore.tasks = response.data;

// Batch updates
taskStore.$patch({
  isLoading: false,
  error: null,
  tasks: response.data
});

This reduced the number of reactive updates and re-renders, resulting in smoother performance, especially for operations affecting many state properties.

Optimizing Getters

We discovered that some of our getters were causing performance bottlenecks. For instance, a getter that filtered and processed a large array of tasks was running more often than necessary:

// Original inefficient getter
const tasksByDate = (state) => {
  console.log('Running expensive computation'); // Running too often!

  // Expensive operation
  return state.tasks.reduce((grouped, task) => {
    const date = new Date(task.dueDate).toDateString();
    if (!grouped[date]) {
      grouped[date] = [];
    }
    grouped[date].push(task);
    return grouped;
  }, {});
};

We refactored such getters to use memoization patterns:

import { defineStore } from 'pinia'
import { computed } from 'vue'

export const useTaskStore = defineStore('tasks', () => {
  const tasks = ref([]);

  // Computed with dependency tracking
  const tasksByDate = computed(() => {
    console.log('Running expensive computation'); // Now runs only when tasks change

    return tasks.value.reduce((grouped, task) => {
      const date = new Date(task.dueDate).toDateString();
      if (!grouped[date]) {
        grouped[date] = [];
      }
      grouped[date].push(task);
      return grouped;
    }, {});
  });

  return {
    tasks,
    tasksByDate
  };
});

This ensures the expensive computation only runs when the tasks actually change, not on every access of the getter.

Conclusion: Why Pinia Is Here to Stay

Looking back on my journey with Pinia, it's clear why it has become Vue's recommended state management solution. It combines the best aspects of Vuex with modern patterns that align perfectly with Vue 3's philosophy.

The benefits I've experienced firsthand include:

Less boilerplate: No more mutations, just direct state updates
TypeScript excellence: First-class type support that actually works
Modular design: Multiple stores without the namespace awkwardness
DevTools integration: Time-travel debugging and state inspection
Composition API harmony: Setup stores align perfectly with modern Vue

For new projects, I don't even consider alternatives anymore - Pinia is my default choice. For existing Vuex projects, the migration path is clear and well worth the effort.

If you're on the fence about trying Pinia, my advice is simple: give it a shot on your next feature or small project. I think you'll find, as I did, that it transforms your development experience for the better.

Where to Learn More

If this article has sparked your interest in Pinia, here are some resources I've found invaluable:

Official Pinia Documentation - Clear, comprehensive, and full of examples
Vue.js Courses - Offers excellent Pinia-specific tutorials
Pinia GitHub Repository - For those who like to learn from source code
Vue Discord Community - Great for asking Pinia questions

Happy coding, and may your state management be ever painless!