Forem: Alexandru Ghiura

Best Practices: React Logging and Error Handling

Alexandru Ghiura — Thu, 18 Dec 2025 16:43:02 +0000

React Logging and Error Handling Best Practices

In this guide, we'll explore battle-tested patterns for implementing production-ready logging and error handling in React applications using logzai-js library, but you can use any library.

Whether you're building a small side project or maintaining a large-scale application, these practices will help you catch bugs faster, understand user behavior better, and ship more reliable software.

Understanding the Foundation

Why Logging Matters in React

Client-side logging presents unique challenges compared to server-side logging:

Distributed Environments: Your app runs in thousands of different browsers, devices, and network conditions
Limited Visibility: Without proper instrumentation, you only see errors that get reported—most issues go unnoticed
User Context: Understanding what the user was doing when an error occurred is critical for debugging
Performance Impact: Excessive logging can slow down your app and frustrate users

The key is finding the right balance: log enough to debug effectively, but not so much that you impact performance or create noise.

The Cost of Poor Error Handling

When error handling is an afterthought, the consequences ripple through your entire organization:

Lost Revenue: Users who encounter errors often abandon their workflows—shopping carts left behind, forms never submitted
Support Burden: Your support team spends hours trying to reproduce issues with incomplete information
Development Time: Engineers waste days tracking down bugs that could have been caught in minutes with proper logging
User Trust: Frequent errors erode confidence in your product, making users less likely to return

What Makes Good Logging

Good logging isn't about quantity—it's about quality and structure:

Structured Data: Logs should be machine-readable with consistent fields (JSON, not strings)
Appropriate Levels: Use debug, info, warn, and error levels correctly
Rich Context: Include user IDs, session IDs, routes, and relevant state
Actionable Information: Every log should help you understand what happened and why
Performance-Aware: Logging should never block your UI thread

With these principles in mind, let's dive into implementation.

Setting Up LogzAI in Your React Application

Getting started with logzai-js is straightforward. First, install the package:

npm install logzai-js
# or
pnpm add logzai-js
# or
yarn add logzai-js

Next, initialize logzai in your application entry point (typically main.tsx or index.tsx):

import logzai from 'logzai-js'
import { browserPlugin } from 'logzai-js/browser'

// Initialize logzai before rendering your app
logzai.init({
  ingestToken: 'your-ingest-token',
  ingestEndpoint: 'https://ingest.logzai.com',
  serviceName: 'my-react-app',
  environment: process.env.NODE_ENV, // 'development' or 'production'
  mirrorToConsole: process.env.NODE_ENV === 'development', // See logs in console during dev
})

// Enable the browser plugin for automatic error handling
logzai.plugin('browser', browserPlugin)

What the Browser Plugin Does Automatically

The browser plugin is a powerful addition that transforms your error handling with zero additional code. Once enabled, it automatically:

Captures all JavaScript errors: Hooks into window.onerror to catch unhandled exceptions
Captures unhandled promise rejections: Monitors window.onunhandledrejection to catch async errors that slip through
Logs errors with full context: Automatically includes stack traces, error messages, and browser information
Non-blocking operation: Sends logs asynchronously without impacting your app's performance

This means even errors you didn't explicitly catch will be logged to logzai, giving you complete visibility into production issues.

Customizing the Browser Plugin

The browser plugin accepts configuration options to enhance your logs with application-specific context:

import logzai from 'logzai-js'
import { browserPlugin } from 'logzai-js/browser'
import { store } from './store'
import { selectCurrentUser, selectSelectedOrg } from './store/selectors'

// Initialize logzai
logzai.init({
  ingestToken: 'your-ingest-token',
  ingestEndpoint: 'https://ingest.logzai.com',
  serviceName: 'my-react-app',
  environment: process.env.NODE_ENV,
  mirrorToConsole: process.env.NODE_ENV === 'development',
})

// Configure browser plugin with custom options
logzai.plugin('browser', browserPlugin, {
  // Custom message formatter for errors
  messageFormatter: (error: any) => {
    return `Exception: ${error.message}`
  },

  // Context injector - automatically adds context to every log and error
  contextInjector: () => {
    const state = store.getState()
    const currentUser = selectCurrentUser(state)
    const selectedOrg = selectSelectedOrg(state)

    return {
      userId: currentUser?.id,
      userEmail: currentUser?.email,
      orgId: selectedOrg?.id,
      orgName: selectedOrg?.name,
      currentRoute: window.location.pathname,
      userAgent: navigator.userAgent,
      viewport: `${window.innerWidth}x${window.innerHeight}`,
    }
  },

  // Optional: Filter out errors you don't want to log
  errorFilter: (error: Error) => {
    // Return false to skip logging this error
    if (error.message.includes('ResizeObserver')) {
      return false // Don't log benign ResizeObserver errors
    }
    return true // Log all other errors
  },
})

Key Options:

messageFormatter: Transform how error messages appear in logs
contextInjector: Inject application state (user, org, route) into every log automatically
errorFilter: Skip logging specific errors that aren't actionable

With this setup, every error—even those you didn't anticipate—will be automatically logged with rich context about the user, their session, and the state of your application.

That's it! You're now ready to start logging with comprehensive automatic error tracking.

Logging Best Practices

1. Use Appropriate Log Levels

Understanding when to use each log level is crucial for creating a signal-to-noise ratio that actually helps you debug:

DEBUG: Use for detailed information useful during development. These logs are typically verbose and not needed in production.

// Good use of debug
const handleSearch = (query: string) => {
  logzai.debug('Search initiated', {
    query,
    timestamp: Date.now(),
    resultsCount: results.length,
  })
}

INFO: Use for important business events and normal operations you want to track.

// Good use of info
const handleCheckout = async (cartItems: CartItem[]) => {
  logzai.info('Checkout started', {
    itemCount: cartItems.length,
    totalValue: calculateTotal(cartItems),
    userId: currentUser.id,
  })

  // ... checkout logic
}

WARN: Use for recoverable issues or deprecated features that should be addressed but don't break functionality.

// Good use of warn
const fetchUserData = async () => {
  const cachedData = getFromCache('userData')

  if (!cachedData) {
    logzai.warn('Cache miss for user data', {
      userId: currentUser.id,
      cacheExpiry: getCacheExpiry(),
    })
    return fetchFromAPI()
  }

  return cachedData
}

ERROR: Use for unrecoverable errors that impact functionality.

// Good use of error
const saveUserSettings = async (settings: Settings) => {
  try {
    await api.updateSettings(settings)
  } catch (error) {
    logzai.error('Failed to save user settings', {
      error: error.message,
      userId: currentUser.id,
      settings,
    })
    throw error // Re-throw to let UI handle it
  }
}

2. Structure Your Logs with Context

Context transforms logs from cryptic messages into actionable insights. Compare these two approaches:

// ❌ Bad: Minimal context
logzai.info('User logged in')

// ✅ Good: Rich context
logzai.info('User logged in', {
  userId: user.id,
  email: user.email,
  loginMethod: 'oauth',
  provider: 'google',
  timestamp: Date.now(),
  previousLoginAt: user.lastLoginAt,
  daysSinceLastLogin: calculateDaysSince(user.lastLoginAt),
})

The second example gives you everything you need to understand user behavior patterns, detect anomalies, and debug issues.

Key context fields to include:

User identifiers: userId, email, sessionId
Business context: orderId, transactionId, itemId
Technical context: route, component name, action type
Temporal context: timestamps, durations, retry counts
Environmental context: browser, device, network status

3. Context Injection Pattern

As we saw in the setup section, the browser plugin's contextInjector automatically enriches all logs and errors with application context. This pattern ensures you never have to manually add context to individual log statements.

When you configure the browser plugin with a contextInjector, every log call automatically includes that context:

// Simple log call
logzai.info('Feature flag toggled', {
  featureName: 'dark-mode',
  enabled: true
})

// Automatically enriched with context from the browser plugin:
// - userId, userEmail (from Redux state)
// - orgId, orgName (from Redux state)
// - currentRoute (from window.location)
// - userAgent, viewport (from browser)

This pattern has several benefits:

Consistency: Every log has the same baseline context
DRY Principle: Write context logic once, not in every log statement
Error Context: Even automatically caught errors include this context
Zero Overhead: Context is injected at log time, not computed unnecessarily

The contextInjector is called for every log, so you can include dynamic information like the current route or selected organization that changes during the user's session.

4. Log User Actions and State Changes

Logging user interactions creates a breadcrumb trail that's invaluable for debugging:

// Component with action logging
const ProductPage = () => {
  const handleAddToCart = (product: Product) => {
    logzai.info('Product added to cart', {
      productId: product.id,
      productName: product.name,
      price: product.price,
      quantity: 1,
      source: 'product-page',
    })

    dispatch(addToCart(product))
  }

  const handleQuickView = (product: Product) => {
    logzai.debug('Quick view opened', {
      productId: product.id,
      trigger: 'hover',
    })

    setQuickViewProduct(product)
  }

  return (
    // ... component JSX
  )
}

For forms, log both submission and validation failures:

const ContactForm = () => {
  const handleSubmit = async (values: FormValues) => {
    // Validate
    const errors = validateForm(values)

    if (Object.keys(errors).length > 0) {
      logzai.warn('Form validation failed', {
        formName: 'contact',
        errors: Object.keys(errors),
        attemptNumber: submitAttempts + 1,
      })
      return
    }

    try {
      await api.submitContactForm(values)

      logzai.info('Contact form submitted successfully', {
        formName: 'contact',
        fieldsFilled: Object.keys(values),
      })
    } catch (error) {
      logzai.error('Contact form submission failed', {
        formName: 'contact',
        error: error.message,
      })
    }
  }

  return (
    // ... form JSX
  )
}

5. Performance Considerations

Logging should never slow down your app. Follow these guidelines:

Async by Default: logzai sends logs asynchronously, but avoid doing heavy computation in log statements:

// ❌ Bad: Expensive operation in log statement
logzai.debug('Component rendered', {
  largeArray: expensiveComputation(data), // Blocks UI
})

// ✅ Good: Only log what's necessary
logzai.debug('Component rendered', {
  dataSize: data.length,
})

Sampling in Production: For high-frequency events, use sampling to reduce volume:

const logScrollEvent = () => {
  // Only log 1% of scroll events
  if (Math.random() < 0.01) {
    logzai.debug('Page scrolled', {
      scrollPosition: window.scrollY,
      scrollDepth: calculateScrollDepth(),
    })
  }
}

Environment-Specific Verbosity: Use different log levels for development vs. production:

const isDevelopment = process.env.NODE_ENV === 'development'

const logComponentMount = (componentName: string) => {
  if (isDevelopment) {
    logzai.debug(`Component mounted: ${componentName}`)
  }
}

Error Handling Best Practices

1. Implement Error Boundaries

React Error Boundaries are your first line of defense against unhandled errors crashing your entire app. They catch errors in the component tree and allow you to log them and show fallback UI:

import React, { Component, ErrorInfo, ReactNode } from 'react'
import logzai from 'logzai-js/browser'

interface Props {
  children: ReactNode
  fallback?: ReactNode
}

interface State {
  hasError: boolean
  error?: Error
}

class ErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props)
    this.state = { hasError: false }
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error }
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    // Log to logzai with full context
    logzai.exception('React error boundary caught error', error, {
      errorType: 'react-error',
      componentStack: errorInfo.componentStack,
      errorMessage: error.message,
      errorStack: error.stack,
      pathname: window.location.pathname,
      timestamp: Date.now(),
    })
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback || (
        <div style={{ padding: '20px', textAlign: 'center' }}>
          <h2>Something went wrong</h2>
          <p>We've been notified and are looking into it.</p>
          <button onClick={() => window.location.reload()}>
            Reload Page
          </button>
        </div>
      )
    }

    return this.props.children
  }
}

export default ErrorBoundary

Where to Place Error Boundaries: Wrap strategic parts of your app to isolate failures:

// App-level boundary
const App = () => (
  <ErrorBoundary>
    <Router>
      <Routes />
    </Router>
  </ErrorBoundary>
)

// Feature-level boundaries
const Dashboard = () => (
  <div>
    <ErrorBoundary fallback={<WidgetError />}>
      <RevenueWidget />
    </ErrorBoundary>

    <ErrorBoundary fallback={<WidgetError />}>
      <UsersWidget />
    </ErrorBoundary>

    <ErrorBoundary fallback={<WidgetError />}>
      <ActivityWidget />
    </ErrorBoundary>
  </div>
)

This approach ensures one broken widget doesn't take down the entire dashboard.

Note on Browser Plugin Integration: While the browser plugin automatically catches unhandled JavaScript errors and promise rejections, Error Boundaries are still essential. The browser plugin catches errors that escape React's component tree, while Error Boundaries catch errors within React components and allow you to show fallback UI. Together, they provide comprehensive error coverage:

Error Boundaries: Catch React component errors + show fallback UI + log with logzai.exception()
Browser Plugin: Catch all other JavaScript errors + unhandled promise rejections automatically

Both layers working together ensure nothing slips through the cracks.

2. Log Exceptions with Full Context

When logging exceptions, include everything needed to reproduce and debug the issue:

const fetchUserProfile = async (userId: string) => {
  try {
    const response = await api.get(`/users/${userId}`)
    return response.data
  } catch (error) {
    logzai.exception('Failed to fetch user profile', error, {
      // Error details
      errorMessage: error.message,
      errorCode: error.response?.status,

      // Request context
      userId,
      endpoint: `/users/${userId}`,

      // User context (automatically added by contextInjector)
      // - currentUserId, email
      // - orgId, orgName
      // - pathname

      // Additional debugging info
      retryCount: 0,
      timestamp: Date.now(),
    })

    throw error // Re-throw to let calling code handle
  }
}

The logzai.exception() method is specifically designed for errors and automatically extracts the stack trace and error details.

3. Handle Async Errors (Promise Rejections)

Good news: The browser plugin automatically captures unhandled promise rejections! Once you've enabled the browser plugin with logzai.plugin('browser', browserPlugin), all unhandled rejections are automatically logged with full context.

However, you should still handle promise rejections explicitly where possible for better control over error messages and recovery strategies:

const loadUserData = async () => {
  try {
    const [profile, settings, preferences] = await Promise.all([
      fetchProfile(),
      fetchSettings(),
      fetchPreferences(),
    ])

    return { profile, settings, preferences }
  } catch (error) {
    logzai.exception('Failed to load user data', error, {
      failedOperation: 'loadUserData',
      retryable: true,
    })

    // Show user-friendly error
    throw new Error('Unable to load your profile. Please try again.')
  }
}

4. API Error Handling Pattern

Centralize API error logging using interceptors. For axios:

import axios from 'axios'
import logzai from 'logzai-js/browser'

const apiClient = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
})

// Request interceptor (log outgoing requests in debug mode)
apiClient.interceptors.request.use(
  (config) => {
    if (import.meta.env.DEV) {
      logzai.debug('API request', {
        method: config.method?.toUpperCase(),
        url: config.url,
        params: config.params,
      })
    }
    return config
  },
  (error) => {
    logzai.error('API request setup failed', {
      error: error.message,
    })
    return Promise.reject(error)
  }
)

// Response interceptor (log errors)
apiClient.interceptors.response.use(
  (response) => response,
  (error) => {
    const request = error.config

    logzai.error('API request failed', {
      method: request?.method?.toUpperCase(),
      url: request?.url,
      statusCode: error.response?.status,
      statusText: error.response?.statusText,
      errorMessage: error.message,
      responseData: error.response?.data,
      requestDuration: Date.now() - request?.metadata?.startTime,
    })

    return Promise.reject(error)
  }
)

export default apiClient

For fetch API:

const fetchWithLogging = async (url: string, options?: RequestInit) => {
  const startTime = Date.now()

  try {
    const response = await fetch(url, options)

    if (!response.ok) {
      const errorData = await response.text()

      logzai.error('Fetch request failed', {
        url,
        method: options?.method || 'GET',
        statusCode: response.status,
        statusText: response.statusText,
        errorData,
        duration: Date.now() - startTime,
      })

      throw new Error(`HTTP ${response.status}: ${response.statusText}`)
    }

    return response
  } catch (error) {
    logzai.exception('Fetch request error', error, {
      url,
      method: options?.method || 'GET',
      duration: Date.now() - startTime,
    })

    throw error
  }
}

5. User-Friendly Error Messages

Always separate what you log from what you show users:

class ErrorBoundary extends Component<Props, State> {
  // ... previous code

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    // Log technical details
    logzai.exception('React error boundary caught error', error, {
      errorType: 'react-error',
      componentStack: errorInfo.componentStack,
      errorMessage: error.message,
      errorStack: error.stack,
    })
  }

  render() {
    if (this.state.hasError) {
      // Show friendly message to users
      return (
        <div className="error-container">
          <h2>Oops! Something went wrong</h2>
          <p>
            We've been notified and are working on a fix.
            In the meantime, try refreshing the page.
          </p>
          <button onClick={() => window.location.reload()}>
            Refresh Page
          </button>
        </div>
      )
    }

    return this.props.children
  }
}

Never expose stack traces, error codes, or technical jargon to end users—those belong in your logs, not your UI.

Advanced Patterns

1. Redux/State Management Integration

If you're using Redux, you can log state changes and actions with middleware:

import { Middleware } from '@reduxjs/toolkit'
import logzai from 'logzai-js/browser'

const logzaiMiddleware: Middleware = () => (next) => (action) => {
  // Only log in development or for specific action types
  if (
    import.meta.env.DEV ||
    ['auth/login', 'auth/logout', 'user/update'].includes(action.type)
  ) {
    logzai.debug('Redux action dispatched', {
      kind: 'redux',
      type: action.type,
      payload: action.payload,
      timestamp: Date.now(),
    })
  }

  return next(action)
}

// Add to your store configuration
export const store = configureStore({
  reducer: rootReducer,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(logzaiMiddleware),
})

When to Use: Enable this in production only for critical actions to avoid log spam. Use it freely in development for debugging.

2. Route Change Logging

Track user navigation to understand user journeys:

import { useEffect } from 'react'
import { useLocation } from 'react-router-dom'
import logzai from 'logzai-js/browser'

const RouteLogger = () => {
  const location = useLocation()

  useEffect(() => {
    logzai.info('Route changed', {
      pathname: location.pathname,
      search: location.search,
      hash: location.hash,
      timestamp: Date.now(),
    })
  }, [location])

  return null
}

// Use in your app
const App = () => (
  <Router>
    <RouteLogger />
    <Routes>
      {/* your routes */}
    </Routes>
  </Router>
)

3. Custom Hooks for Logging

Create reusable hooks to standardize logging patterns:

import { useCallback } from 'react'
import { useLocation } from 'react-router-dom'
import logzai from 'logzai-js/browser'

// Hook for logging user actions
export const useLogAction = () => {
  const location = useLocation()

  return useCallback((action: string, context?: Record<string, any>) => {
    logzai.info(action, {
      ...context,
      pathname: location.pathname,
      timestamp: Date.now(),
    })
  }, [location])
}

// Usage in components
const ShoppingCart = () => {
  const logAction = useLogAction()

  const handleCheckout = () => {
    logAction('Checkout initiated', {
      itemCount: cartItems.length,
      totalValue: calculateTotal(cartItems),
    })

    // ... checkout logic
  }

  return (
    // ... component JSX
  )
}

4. Error Recovery Strategies

Build error boundaries that can recover from errors:

interface Props {
  children: ReactNode
  maxRetries?: number
}

interface State {
  hasError: boolean
  error?: Error
  retryCount: number
}

class RecoverableErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props)
    this.state = { hasError: false, retryCount: 0 }
  }

  static getDerivedStateFromError(error: Error): Partial<State> {
    return { hasError: true, error }
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    logzai.exception('Recoverable error boundary caught error', error, {
      errorType: 'react-error',
      componentStack: errorInfo.componentStack,
      retryCount: this.state.retryCount,
      maxRetries: this.props.maxRetries || 3,
    })
  }

  handleRetry = () => {
    const { maxRetries = 3 } = this.props
    const newRetryCount = this.state.retryCount + 1

    if (newRetryCount <= maxRetries) {
      logzai.info('Error boundary retry attempt', {
        retryCount: newRetryCount,
        maxRetries,
      })

      this.setState({
        hasError: false,
        error: undefined,
        retryCount: newRetryCount
      })
    } else {
      logzai.warn('Error boundary max retries reached', {
        retryCount: newRetryCount,
        maxRetries,
      })
    }
  }

  render() {
    const { hasError, retryCount } = this.state
    const { maxRetries = 3 } = this.props

    if (hasError) {
      return (
        <div className="error-container">
          <h2>Something went wrong</h2>
          {retryCount < maxRetries ? (
            <>
              <p>Would you like to try again?</p>
              <button onClick={this.handleRetry}>
                Try Again ({maxRetries - retryCount} attempts remaining)
              </button>
            </>
          ) : (
            <>
              <p>We've exhausted retry attempts. Please refresh the page.</p>
              <button onClick={() => window.location.reload()}>
                Refresh Page
              </button>
            </>
          )}
        </div>
      )
    }

    return this.props.children
  }
}

This pattern is useful for components that might fail due to temporary issues (network glitches, race conditions, etc.).

Production Checklist

Before deploying your logging and error handling to production, verify these items:

Configuration

[ ] Use environment-specific ingest tokens (different for dev/staging/prod)
[ ] Set environment field correctly based on NODE_ENV
[ ] Configure appropriate log levels (debug in dev, info/warn/error in prod)
[ ] Set mirrorToConsole to false in production
[ ] Enable browser plugin with logzai.plugin('browser', browserPlugin)
[ ] Configure contextInjector to include user, org, and route context
[ ] Set up errorFilter to exclude benign errors (ResizeObserver, etc.)

Testing

[ ] Test error boundaries with intentionally thrown errors
[ ] Verify browser plugin captures unhandled JavaScript errors automatically
[ ] Test that unhandled promise rejections are logged by the browser plugin
[ ] Verify logs appear in logzai dashboard with correct context
[ ] Verify contextInjector is working (check logs include userId, orgId, route)
[ ] Test errorFilter excludes errors you want to skip
[ ] Check that sensitive data is NOT being logged

Monitoring

[ ] Set up alerts for high error rates
[ ] Create dashboards for key metrics (error rates by route, user actions)
[ ] Configure notification channels (email, Slack, PagerDuty)
[ ] Review logs regularly to identify patterns

Privacy & Security

[ ] Never log passwords, tokens, or API keys
[ ] Sanitize PII (email, phone, address) before logging
[ ] Review data retention policies
[ ] Ensure compliance with GDPR/CCPA if applicable

Performance

[ ] Verify bundle size impact (logzai-js is ~15KB gzipped)
[ ] Use log sampling for high-frequency events
[ ] Avoid logging large objects or arrays
[ ] Profile your app to ensure logging doesn't impact performance

Common Pitfalls to Avoid

Over-Logging

Logging every single action creates noise that obscures real issues:

// ❌ Bad: Too much noise
const MyComponent = () => {
  logzai.debug('MyComponent rendering')
  logzai.debug('Props received', props)
  logzai.debug('State initialized')

  const handleClick = () => {
    logzai.debug('Button clicked')
    logzai.debug('State before update', state)
    setState(newState)
    logzai.debug('State after update', newState)
  }

  logzai.debug('MyComponent render complete')
  return <button onClick={handleClick}>Click me</button>
}

Instead, log meaningful events:

// ✅ Good: Signal over noise
const MyComponent = () => {
  const handleClick = () => {
    logzai.info('Important action triggered', {
      actionType: 'submit-form',
      formData: sanitizedData,
    })
    setState(newState)
  }

  return <button onClick={handleClick}>Click me</button>
}

Under-Logging

The opposite problem: not logging enough context to be useful:

// ❌ Bad: Not enough context
logzai.error('API call failed')

// ✅ Good: Actionable context
logzai.error('API call failed', {
  endpoint: '/api/users',
  method: 'POST',
  statusCode: 500,
  errorMessage: error.message,
  requestId: response.headers['x-request-id'],
})

Synchronous Logging in Hot Paths

Don't perform expensive operations in frequently-called code:

// ❌ Bad: Expensive operation in render
const ProductList = ({ products }) => {
  logzai.debug('Rendering products', {
    products: products.map(p => ({ // Expensive!
      id: p.id,
      name: p.name,
      fullDetails: JSON.stringify(p), // Very expensive!
    }))
  })

  return <div>{/* render products */}</div>
}

// ✅ Good: Log only what's necessary
const ProductList = ({ products }) => {
  logzai.debug('Rendering products', {
    productCount: products.length,
    firstProductId: products[0]?.id,
  })

  return <div>{/* render products */}</div>
}

Logging Sensitive Data

Never log passwords, tokens, credit cards, or other sensitive information:

// ❌ Bad: Logging sensitive data
logzai.info('User logged in', {
  email: user.email,
  password: user.password, // NEVER DO THIS!
  creditCard: user.paymentMethod.cardNumber, // NEVER DO THIS!
})

// ✅ Good: Sanitized logging
logzai.info('User logged in', {
  userId: user.id,
  email: user.email,
  hasPaymentMethod: !!user.paymentMethod,
  loginMethod: 'password',
})

Ignoring Error Boundaries

Don't let errors crash your entire app:

// ❌ Bad: No error boundary
const App = () => (
  <Router>
    <Routes>
      <Route path="/" element={<Dashboard />} />
      {/* One error here crashes everything */}
    </Routes>
  </Router>
)

// ✅ Good: Strategic error boundaries
const App = () => (
  <ErrorBoundary>
    <Router>
      <Routes>
        <Route path="/" element={
          <ErrorBoundary fallback={<DashboardError />}>
            <Dashboard />
          </ErrorBoundary>
        } />
      </Routes>
    </Router>
  </ErrorBoundary>
)

Generic Error Messages

Don't make debugging harder with vague errors:

// ❌ Bad: Generic error
throw new Error('Something went wrong')

// ✅ Good: Specific error
throw new Error(
  `Failed to load user profile: ${error.message} (User ID: ${userId})`
)

Conclusion

Implementing robust logging and error handling in React applications isn't optional—it's essential for building reliable, maintainable software. Let's recap the key takeaways:

Enable the browser plugin for automatic error capture—it catches JavaScript errors and promise rejections with zero extra code
Use structured logging with rich context via the contextInjector to make logs searchable and actionable
Implement error boundaries at strategic points to prevent cascading failures and show fallback UI
Log at appropriate levels to maintain signal-to-noise ratio
Handle specific errors explicitly for better control, while the browser plugin catches everything else
Separate technical logs from user-facing messages to maintain good UX
Test your error handling to ensure it works when things go wrong
Monitor and alert on error patterns to catch issues proactively

Charts in Vue3

Alexandru Ghiura — Fri, 21 May 2021 13:36:34 +0000

Hello 👋 !

Today I want to talk about charts, more specifically charts in Vue 3.

Recently I had to add some charts to my latest project so I had to find a good library that will allow me to do this easily & fast.

I already used D3 multiple times and considered an industry-standard, but I wanted something more simple for the start that could still offer me some customization if I want to do that in the future.

After some research this were my top 3 candidates:

D3
ApexCharts
Chart.js

The issue I had with ApexCharts & Chart.js was that you need to use a library that is a wrapper for the core library plus the configuration for the charts was cumbersome and I had problems trying to do any kind of customization.

I was expecting to find a library like Recharts where you compose components to write your chart and the rendering part is handled by the framework, in my case by Vue, but I couldn’t find it.

This made me choose D3. The problem here was that I had to write a lot of code to get simple charts so I decided to write a new chart library for Vue 3.

Hello, Vue3-Charts

The library is called Vue3-Charts and it is build with 3 core concepts in mind:

💡 Intuitive
🔌 Extensible
📦 Extremely easy to use

The core idea is: If you want a simple chart, the library should be very intuitive and easy to use but if you need more complicated layers and customization the library should provide that too.

To do that the library is build with this in mind and everything is a layer or a widget.

The library comes with some built-in layers (Line, Bar, Area, etc…) but you can easily write your own layers using the power of Vue3 composition API. Check this example in the documentation.

Here is a simple responsive LineChart:

<template>
  <Responsive class="w-full">
    <template #main="{ width }">
      <Chart :size="{ width, height: 420 }" :data="data">
        <template #layers>
          <Line :dataKeys="['name', 'pl']" />
        </template>
      </Chart>
    </template>
  </Responsive>
</template>

<script lang="ts">
  import { defineComponent, ref } from 'vue'
  import { Responsive, Chart, Line } from 'vue3-charts'
  import { plByMonth } from '@/data'

  export default defineComponent({
  name: 'LineChart',
  components: { Responsive, Chart, Line },
  setup() {
    const data = ref(plByMonth)
    const direction = ref('horizontal')
    const margin = ref({
      left: 10,
      top: 20,
      right: 20,
      bottom: 10
    })

    return { data, direction, margin }
  }
  })
</script>

As you can see you just write Vue components to build your charts simple and easy to read.

The library is still in progress but you can check the documentation here:
https://vue3charts.org/

And the GitHub repository here:
https://github.com/ghalex/vue3-charts

If you have any suggestions please let me know.

Thank you so much for reading!

If there is anything I can do to help, please reach out on my Twitter @ghalex and check out my blog for more articles.

Have a nice day!

State Management in Vue 3

Alexandru Ghiura — Mon, 07 Dec 2020 20:33:48 +0000

Hello 👋 ! Today we will talk about state management.

Because my article about the problems I encountered switching from Vue 2 to Vue 3 was quite popular, I decided to continue writing about my journey to switch to Vue 3 and tell you about my experience in choosing a State Management library in Vue 3.

With the new Vue 3 composition API, the options you have for state management are expanding a lot and some of the libraries I will mention here are pretty cool 💅, you will see.

But, before we continue 🙌 keep in mind this is my personal preference and I am not saying one is better than the other. I will just show you the top 4 libraries I considered for my project when I switched to Vue 3. Plus I wanted to list them here so I can easily 🔍 find them in the future.

Vue 3 State Management libraries:

Pinia
Your own
Harlem
Vuex

Let’s take each one and talk a little bit about it and of course, see 🤩 some code.

1. Pinia

My favorite one and the one I plan to give a try in the future. Currently, the project is experimental, and the goal of the project if you read the description on GitHub is to show what a Store could be like using the composition API.

Let’s see a store example before we can talk more about the pros and cons of this library:

// store/projects.js
import { defineStore } from 'pinia'

const URL = 'some API URL here'

export const useProjects = defineStore({
  id: 'projects',
  state: () => ({
    projects: [],
    loading: false
  }),
  getters: {
    doneProjects() {
      return this.projects.map(p => p.isDone)
    }
  },
  actions: {
    async fetchAll() {
      try {
        this.loading = true
        this.projects = await (await fetch(url)).json()
        this.loading = false
      } catch (err) {
        // handle error here
      }
    }
  }
})

And use it in a .vue file:

<template>
  <div v-if="projects.loading">
    <div v-for="project in projects.doneProjects" :key="project.id">
      <div>{{ project.name }}</div>
    </div>
  </div>
  <div v-else>loading</div>
</template>

<script>
import { onMounted } from 'vue'
import { useProjects } from '@/store/projects'

export default {
  setup() {
    const projects = useProjects()

    onMounted(() => {
      projects.fetchAll()
    })

    return {
      projects
    }
  }
}
</script>

👍 What I like:

no actions, just methods
very simple to use and the code looks clean
no more mutations, this is the big one for me 🥳
works great with Typescript and has Autocomplete
DevTools support
SSR support ⚙️

👎 What I don’t like:

you don’t have time travel
the project is still experimental
you can mutate the state by directly change something

🤔 Conclusion:

Pinia has some great ideas 💡 and personally, I like all of them. It is clean and straightforward to use plus composing stores and using the $patch method to update state is something that I really like.

Here is the link to the repository give it a try and leave a comment with what you think about it.

2. Your own state management

This is what I currently use. With the addition of Composition API to Vue 3, you can easily build your own state management.

Here is an example:

// store/projects.js

import { reactive, toRefs } from "vue"
const url = 'some API URL here'

const state = reactive({
    projects: [],
    loading: true
});

export default function useProjects() {
    const fetchAll = async () => {
        state.loading = true
        state.projects = await (await fetch(url)).json()
        state.loading = false
    }

    const doneProjects = compute(
        () => state.projects.map(p => p.isDone)
    )

    return {
        ...toRefs(state),
        doneProjects,
        fetchAll
    }
}

And then you can use the hook useProjects in any .vue file like this:

<template>
    <div v-if="loading">
      <div v-for="project in projects" :key="project.id">
        <div>{{ project.name }}</div>
      </div>
    </div>
    <div v-else>loading</div>
</template>
<script>
    import { onMounted } from 'vue'
    import { useProjects } from '@/store/projects'

    export default {
        setup() {
            const {
                loading,
                projects,
                fetchAll
            } = useProjects()

            onMounted(() => {
                 fetchAll()  
            })

            return {
                loading,
                projects
            }
        }
    }
</script>

👍 What I like:

very simple to implement and use
very simple to test
code is reusable, you can copy-paste it
works great with Typescript

👎 What I don’t like:

you don’t have time travel
the state is not immutable, you can edit parts of the state
no DevTools

🤔 Conclusion:

This solution is a good choice when your project is not very big and the team is relatively small. Another instance when you can choose this solution is when you want to prototype something or you just need to build an MVP

The best thing here is that you can easily upgrade to another solution if you decide so.

3. Harlem

Harlem is a simple, unopinionated, lightweight, and extensible state management for Vue 3. It’s selling point is that it will not impose any standards or conventions on your codebase (which I don’t agree with) and is very lightweight (around 1KB)

Let’s try to write our example using Harlem.

import { createStore } from '@harlem/core'
const url = 'some API URL here'
const STATE = {
  projects: [],
  loading: false
}

const { getter, mutation, ...store } = createStore('projects', STATE)

export const state = store.state

// getters
export const doneProjects = getter('doneProjects', state => state.projects.map(p => p.isDone))

// Mutations
export const setLoading = mutation('setProjects', (state, payload) => {
  state.loading = payload
})

export const setProjects = mutation('setProjects', (state, payload) => {
  state.projects = payload
})

// actions
export async function fetchAll() {
  try {
    setLoading(true)
    const projects = await (await fetch(url)).json()

    setProjects(projects)
    setLoading(false)
  } catch (err) {
    // handle error here
  }
}

And then here is the .vue file:

<template>
  <div v-if="loading">
    <div v-for="project in doneProjects" :key="project.id">
      <div>{{ project.name }}</div>
    </div>
  </div>
  <div v-else>loading</div>
</template>

<script>
import { onMounted, computed } from 'vue'
import useProjects from '@/store/projects'
import { state, doneProjects, fetchAll } from '@/stores/projects'

export default {
  setup() {
    const loading = computed(() => state.loading)

    onMounted(() => {
      fetchAll()
    })

    return {
      loading,
      doneProjects
    }
  }
}
</script>

👍 What I like:

immutable state
it is extensible using plugins
DevTools support
SSR support ⚙️

👎 What I don’t like:

I don’t like the idea of actions & mutations 😢
the code is verbose as you can see in the example it takes a lot more lines of code for the same example
not easy to change to other options

🤔 Conclusion:

This looks like a nice project but from my point of view, it doesn’t add too much compared to Vuex. Plus if you check the first two examples you can see it is very easy to switch from one option to another but if you go with this choice I see lots of changes to do if you decide to switch.

But if mutations 🤐 are something that you like and you really need time travel then, here is the link to the repository give it a try and leave a comment with what you think about it.

4. Vuex

Vuex is still a solid choice as a state management library. With the release of version 4.0, it is very close to previous examples.

Let’s write the above example using Vuex 4.0

import { createStore } from 'vuex'

export const store = createStore({
  state: {
    projects: [],
    loading: false
  },
  mutations: {
    setProjects(state, payload) {
      state.projects = payload
    },
    setLoading(state, payload) {
      state.loading = payload
    }
  },
  getters: {
    doneProjects(state) {
      return state => state.projects.map(p => p.isDone)
    }
  },
  actions: {
    async fetchAll({ commit }) {
      try {
        commit('setLoading', true)
        const projects = await (await fetch(url)).json()

        commit('setProjects', projects)
        commit('setLoading', false)
      } catch (err) {
        // handle error here
      }
    }
  }
})

And then in any .vue file to access the store within the setup hook, you can call the useStore function

<template>
  <div v-if="loading">
    <div v-for="project in doneProjects" :key="project.id">
      <div>{{ project.name }}</div>
    </div>
  </div>
  <div v-else>loading</div>
</template>

<script>
import { onMounted, computed } from 'vue'
import { useStore } from 'vuex'

export default {
  setup() {
    const store = useStore()

    onMounted(() => {
      store.dispatch('fetchAll')
    })

    return {
      loading: computed(() => store.state.loading),
      doneProjects: computed(() => store.getters.doneProjects)
    }
  }
}

👍 What I like:

the new useStore hook
the removal of the global typings for this.$store
DevTools support
SSR support ⚙️
time travel
immutable state

👎 What I don’t like:

I don’t like the mutations 😢 a lot of extra code to write
the code is verbose as you can see in the example
not easy to change to other options
I don’t like to write again computed props to export my getters I don’t like how you compose stores (modules)

🤔 Conclusion:

The new Vuex 4.0 made some good improvements but still, you need to write a lot of code for simple operations.

Plus getting the entire store and then export some parts of it using computed props is a lot of extra work I need to do and I am too lazy to do that 😜

You can find the repository here

Final words

As you can see there are lots of options to choose from. Depending on what are your preference and your constraints you can choose the proper library to manage your state.

I wanted to mention V-Bucket too, but I found it to be the same as Vuex and could not found any unique feature that I could show.

Let me know in the comments what state management library are you using.

Thank you so much for reading!

If there is anything I can do to help, please reach out. Check out my blog for more articles or follow me on Twitter @ghalex

Have a nice day!

My top 3 problems switching to Vue 3:

using v-model on custom components
using filters in my template
using external components

1. Using v-model on custom components

In Vue 2 if you wanted to have support for v-model in your custom component all you had to do is emit an input event. Let me show you an example, let’s say we have a DatePicker component:

<DatePicker v-model="date"></DatePicker>

<!-- In Vue2, would be shorthand for:-->
<DatePicker :value="date" @input="date = $event" />

As you can see v-model="date" is transformed into :value="date" @input="date = $event". So as long as you use the value and emit an input event in your custom component everything should be fine.

By the way, the date model looks like this:

const date = {
  month: 05,
  year: 2020
}

Pretty simple, but if you convert to Vue 3 this will not work anymore.

Don’t get me wrong, I like the new way v-model works. I think is a great improvement, but the above code will not trigger any error and it is kind of hard to debug if you don’t know that v-model works differently in Vue 3.

You can read more here about why they change it and how to use v-model, but the short version is that you need to emit the update:[modelName] event, not an input event, and use modelName in your custom component, not value.

Let’s me show you this on the DatePicker component we created above:

<DatePicker v-model="date"></DatePicker>

<!-- would be shorthand for: -->
<DatePicker
  :modelValue="date"
  @update:modelValue="date = $event"
/>

The advantage here, after you know about this change is that you can use multiple v-model’s:

// two v-model attributes
<DatePicker v-model:month="date.month" v-model:year"date.year"></DatePicker>

The syntax looks like this: (image from Vue 3 documentation)

2. Using filters in my template

In Vue 3 filters are removed! This was not so hard to fix, but going throw all my files 🥵 and change the filters took some time.

The fact that the pipe of the filter conflicts with the Javascript bitwise operator means that expressions with filters are not valid. That’s why the recommendation is using a method instead.

// Vue 2 Syntax
{{ name | firstLetterUp }}

// Vue 3 Alternative
{{ firstLetterUp(name) }}

The drawback of this is that chaining multiple methods is not that elegant as chaining multiple filters.

// Vue 2 Syntax
msg | uppercase | reverse

// Vue 3 Alternative
reverse(uppercase(msg))

3. Using external components, Global API

It is a common practice for most components to register using global API, especially plugins use Vue.use to register.

The problem here is that as the global API is no longer available in Vue 3 the Vue.use method will cease to work and make most of the components break.

This can be a big problem if you have lots of external components in your application because you need to wait for the author to support Vue 3.

Me personally, I had to fork some of the components and made the change myself.

Conclusion

These are the top 3 🤕 problems I encountered, I had a few small ones but not important enough to include here.

However, I am curious what were your top problems switching to Vue 3? Please let me know in the comments?

Thank you so much for reading!

If there is anything I can do to help, please reach out. Check out my blog for more articles or follow me on Twitter @ghalex

Have a nice day!

Feature: Vue 3 script setup

Alexandru Ghiura — Fri, 16 Oct 2020 19:27:15 +0000

I have been doing a lot of Vue.js in the last 6 months and I need to say Vue is awesome.

I am coming from “React ❤️ world” but with the release of Vue 3 and composition API, writing code in Vue or writing code in React is pretty much the same.

What I want to share today is a RFC that will bring even more love for Vue from React world.

Welcome `script setup`

What is <script setup> ? What are we talking about here ?

We talk about a compile step for <script /> tag to improve the authoring experience when using the Composition API inside Single File Components.

Lot’s of words 😄, let me give you an example. Let’s say we have this component:

<template>
  <button @click="inc">{{ count }}</button>
</template>

<script>
import { ref } from 'vue'

export default {
  setup() {
    const count = ref(0)
    const inc = () => count.value++

    return {
      count,
      inc,
    }
  },
}
</script>

As you can see we have our count ref and we export it to the <template /> by return it in the setup() method.

This is pretty clear when you have few exports or one function but when the component becomes bigger and you have 10 exports or more that return becomes BIG 🤯 pretty fast.

This is where <script setup /> can help, you don’t need to return anything or use setup function. The code looks much cleaner and nice.

<template>
  <button @click="inc">{{ count }}</button>
</template>

<script setup>
  import { ref } from 'vue'

  export const count = ref(0)
  export const inc = () => count.value++
</script>

Isn’t that a piece of beauty ? ❤️ 🤩 🥳

Just export what you use in template using export keyword and you are done.

With Typescript

But what convinced me to use this and made me love this even more is the integration with Typescript, look at next example and how you define your props:

<template>
  <button>{{ computedMsg }}</button>
</template>

<script setup="props" lang="ts">
import { computed } from 'vue'

declare const props: {
  msg: string
}

export const computedMsg = computed(() => props.msg + '!!!')
</script>

Look at those props 🤩

If you want to lean more on what is supported and how to use this please check the official page where you can find easy to read examples for all cases.

Thank you so much for reading!

If there is anything I can do to help, please reach out. Check out my blog for more articles.

Have a nice day!

JavaScript Optional Chaining

Alexandru Ghiura — Sat, 10 Oct 2020 13:42:50 +0000

I love 💓 “syntactic sugar” and I have been waiting to use this for a long time. Finally, optional chaining is Stage 4 (read more about JS stages) and more importantly it is available in TypeScript from (3.7).

What is optional Chaining

Optional chaining is a process for querying and calling properties, methods on an optional that might currently be null or undefined.

Let me give you an example.

// Let's say we have this object
const person = { name: undefined }

// This will give you an error
// TypeError: Cannot read property 'fname' of undefined
const fname = person.name.fname

To be safe that person exists and person.name exists we would use logical expressions like this:

const person = { name: undefined }
const fname = person && person.name && person.name.fname

But as you can see you need to write a lot of code and if the property you need to access is even deeper in the object your logical expression will be even longer.

The optional chaining operator aims to solve this problem. All you need to write is 👇👇👇

const fname = person?.name?.fname
console.log(fname) // undefined

This will check person and person.name and if one of them is undefined will return undefined.

If you want to learn more about it the proposal page is a great place to start.

How to use the Operator

The operator does not work with Node.js out of the box just yet but you can use it with Babel (setup Babel), add this plugin @babel/plugin-proposal-optional-chaining to .babelrc plugins and you are good to go.

Thank you so much for reading!

If there is anything I can do to help, please reach out. Check out my blog for more articles.

Have a nice day!

Forem: Alexandru Ghiura

Best Practices: React Logging and Error Handling

React Logging and Error Handling Best Practices

Understanding the Foundation

Why Logging Matters in React

The Cost of Poor Error Handling

What Makes Good Logging

Setting Up LogzAI in Your React Application

What the Browser Plugin Does Automatically

Customizing the Browser Plugin

Logging Best Practices

1. Use Appropriate Log Levels

2. Structure Your Logs with Context

3. Context Injection Pattern

4. Log User Actions and State Changes

5. Performance Considerations

Error Handling Best Practices

1. Implement Error Boundaries

2. Log Exceptions with Full Context

3. Handle Async Errors (Promise Rejections)

4. API Error Handling Pattern

5. User-Friendly Error Messages

Advanced Patterns

1. Redux/State Management Integration

2. Route Change Logging

3. Custom Hooks for Logging

4. Error Recovery Strategies

Production Checklist

Configuration

Testing

Monitoring

Privacy & Security

Performance

Common Pitfalls to Avoid

Over-Logging

Under-Logging

Synchronous Logging in Hot Paths

Logging Sensitive Data

Ignoring Error Boundaries

Generic Error Messages

Conclusion

Charts in Vue3

Hello, Vue3-Charts

Thank you so much for reading!

State Management in Vue 3

Vue 3 State Management libraries:

1. Pinia

👍 What I like:

👎 What I don’t like:

🤔 Conclusion:

2. Your own state management

👍 What I like:

👎 What I don’t like:

🤔 Conclusion:

3. Harlem

👍 What I like:

👎 What I don’t like:

🤔 Conclusion:

4. Vuex

👍 What I like:

👎 What I don’t like:

🤔 Conclusion:

Final words

Thank you so much for reading!

Top problems I got switching to Vue 3

My top 3 problems switching to Vue 3:

1. Using v-model on custom components

2. Using filters in my template

3. Using external components, Global API

Conclusion

Thank you so much for reading!

Feature: Vue 3 script setup

Welcome script setup

With Typescript

Thank you so much for reading!

JavaScript Optional Chaining

What is optional Chaining

How to use the Operator

Thank you so much for reading!

Welcome `script setup`