Design Patterns by Purpose: The Strategy Pattern in Frontend Life (Part 3)

You've tamed structure (Module) and domesticated creation (Factory). Next up: behavior.

Consider a payment processor that needs different personalities (credit card, PayPal, crypto, bank transfer, gift card). Left alone, it turns into an if/else hydra. The Strategy Pattern trims that chaos: you define a small, stable interface for the operation (say process, validate, or charge) and pass in interchangeable implementations at runtime. Call sites stay consistent; only the strategy changes. Result: fewer branches, cleaner tests, and new variants without touching the core. Swap, don't sprawl.

Cat Behaviors: The Furry Problem

Meet Cat, our base class.
Now the variants: StreetCat, HouseCat, ManekiNeko, HelloKitty (famously… silent).

Hard-coding eat(), meow(), and move() into Cat breaks half the family—some behave differently, some don’t meow at all. Copy-pasting those methods into every subclass? Hairball city.

Enter Strategy: pull -> eat, sound, and move into small, swappable objects with the same interface. Compose each cat with the behaviors it actually needs at runtime. New cat? Meet RoboCat—USB-C-powered, doesn’t eat, outputs a synthetic meow, and yes, it flies. You just plug in eatBehavior: none, soundBehavior: synth, and moveBehavior: thrusters. No base-class surgery, no if/else hairballs—just composition that feels like a firmware upgrade.

A real-world pass: CollapsiblePanel with pluggable behaviors

Time to leave the cat café and touch UI. The panel’s structure stays boring on purpose; the behavior gets swapped in.

You ship a solid CollapsiblePanel, and suddenly it’s everywhere. Marketing wants color + sparkle on click. Settings wants non-clickable panels. The dashboard wants panels sorted by priority. Sound familiar? This is where the Strategy Pattern earns its keep: don’t fork your component or stuff it with if/else. Make it behavior-agnostic and accept tiny “strategies” for clicks, sorting—whatever you need.

Think of it this way: the panel is the car; strategies are the drivers. The car exposes the wheel and pedals; the driver decides how to drive. Your panel exposes markup and state; strategies decide what to do.

You can create small strategy functions for different behaviors:

// Strategy objects
const clickStrategies = {
 colorSparkle: {
   onClick: (id) => addSparkleEffect(id),
   getStyle: (id) => ({ backgroundColor: 'lightblue', transition: 'all 0.3s' })
 },
 disabled: {
   onClick: () => {}, // No-op
   getStyle: () => ({ opacity: 0.6, pointerEvents: 'none' })
 }
};

const sortStrategies = {
  priority: (panels) => [...panels].sort((a, b) => a.priority - b.priority),
  alphabetical: (panels) => [...panels].sort((a, b) => a.title.localeCompare(b.title)),
};


// The panel stays behavior-agnostic
const CollapsiblePanel = ({ id, title, children, clickStrategy = clickStrategies.disabled }) => {
 return (
   <div>
     <div 
       onClick={() => clickStrategy.onClick(id)}
       style={clickStrategy.getStyle(id)}
       className="panel-header"
     >
       {title}
     </div>
     <div className="panel-content">{children}</div>
   </div>
 );
};

// Usage
<CollapsiblePanel 
 id="marketing" 
 title="Campaign Results"
 clickStrategy={clickStrategies.colorSparkle} 
/>

<CollapsiblePanel 
 id="dashboard"
 title="Web Traffic"
 clickStrategy={clickStrategies.disabled} 
/>

Before You If/Else

When you feel an if (type === 'special') coming on, pause. Ask: “Could this be a strategy instead?” If yes, extract a tiny function, pass it in, and keep your component calm. Future-you (and your team) will thank you when requirements change again next sprint.

Gotchas

No default strategy? Give your component a safe fallback (e.g., disabled behavior) so it never crashes when someone forgets to pass one in.

Testing panic? Don’t test every combo :)

Over-strategizing? Not every if deserves a strategy. A quick inline check is fine when there are only one or two cases and they won’t grow - extract them when you actually need the third variation.

When NOT to use Strategy:

• Simple toggles (theme.dark ? 'dark' : 'light')
• One-off customizations that won't grow
• Performance-critical paths (strategy dispatch has overhead)

When Strategy shines:

• Multiple implementations of the same interface
• Runtime behavior switching
• Plugin architectures
• Algorithm families that need to be swappable

Final Thoughts

Strategy is the gateway drug to plugin architectures. Mastering this helps you build micro-frontends, extensible design systems, and even frameworks that don't lock you into their opinions. Your components become platforms, not just UI blocks.

Posting in case it helps someone.