Skip to content

STYLING_STRATEGY.md

Latest commit

 

History

History
150 lines (110 loc) · 3.75 KB

STYLING_STRATEGY.md

File metadata and controls

150 lines (110 loc) · 3.75 KB

OG Image Styling Strategy

Current Approach: Style Objects

We've implemented a style objects approach that provides the best balance of maintainability and simplicity for OG image generation.

✅ Benefits of Current Approach

  1. No Dependencies: Works immediately with Vercel OG
  2. Type Safety: Full TypeScript support
  3. Reusability: Shared style objects across components
  4. Performance: No runtime overhead
  5. Maintainability: Centralized design system

📁 Structure

src/config/
├── constants.ts    # Colors, dimensions, paths
└── styles.ts       # Reusable style objects

🎨 Usage Example

import { styles } from '../config/styles';

// Before (inline styles)
<div style={{
  display: 'flex',
  gap: '40px',
  padding: '40px',
  background: 'linear-gradient(-22deg, #5b23e1 0%, #a22feb 100%)',
}}>

// After (style objects)
<div style={styles.header}>

Future Options

Option 1: CSS Classes (Not Recommended)

Pros:

  • Clean JSX
  • Familiar CSS syntax

Cons:

  • Requires CSS file management
  • Need to ensure CSS is available in OG context
  • Potential for style conflicts
  • More complex build setup

Option 2: Emotion CSS-in-JS (Consider Later)

Pros:

  • Design system consistency with web app
  • Type-safe styles
  • Component-based styling
  • Reusable theme

Cons:

  • Additional bundle size (~15-20KB)
  • Build complexity
  • Runtime overhead
  • SSR compatibility concerns

Recommendation: Stick with Style Objects

For your OG image generator, continue with the style objects approach for these reasons:

🎯 Perfect for the Use Case

  1. OG Images are Simple: Limited styling needs compared to full web apps
  2. Performance Critical: Every KB matters for edge computing
  3. Self-Contained: No external dependencies to manage
  4. Reliable: Works consistently across all environments

🚀 When to Consider Emotion

Only consider adding Emotion if:

  1. Design System Grows: You need complex theming/variants
  2. Component Library Integration: You want to share components with web app
  3. Team Preference: Developers strongly prefer CSS-in-JS
  4. Bundle Size Acceptable: The 15-20KB overhead is acceptable

📈 Migration Path

If you decide to add Emotion later:

  1. Phase 1: Keep style objects, add Emotion alongside
  2. Phase 2: Gradually migrate components to Emotion
  3. Phase 3: Remove style objects once migration is complete

Best Practices

✅ Do

  • Use style objects for common patterns
  • Keep styles close to components
  • Use TypeScript for type safety
  • Document design tokens in constants

❌ Don't

  • Mix inline styles with style objects
  • Duplicate styles across components
  • Use magic numbers (use constants)
  • Over-abstract simple styles

Example: Adding New Styles

// src/config/styles.ts
export const styles = {
  // ... existing styles
  
  // New component styles
  card: {
    background: '#FFF',
    borderRadius: '12px',
    padding: '24px',
    boxShadow: '0 4px 12px rgba(0, 0, 0, 0.1)',
  },
  
  // Variant styles
  cardVariants: {
    primary: {
      background: 'linear-gradient(-22deg, #5b23e1 0%, #a22feb 100%)',
      color: '#FFF',
    },
    secondary: {
      background: '#F5F5F5',
      color: '#333',
    },
  },
} as const;

Conclusion

The current style objects approach is optimal for OG image generation. It provides:

  • ✅ Maintainability through reusable styles
  • ✅ Performance with zero overhead
  • ✅ Reliability with no external dependencies
  • ✅ Type Safety with full TypeScript support

Recommendation: Continue with style objects. Only consider Emotion if you need complex theming or want to share components with your web app.