functional

Functional Patterns

Core Principles

• No data mutation - immutable structures only
• Pure functions wherever possible
• Composition over inheritance
• No comments - code should be self-documenting
• Array methods over loops
• Options objects over positional parameters

---

Why Immutability Matters

Immutable data is the foundation of functional programming. Understanding WHY helps you embrace it:

• Predictable: Same input always produces same output (no hidden state changes)
• Debuggable: State doesn't change unexpectedly - easier to trace bugs
• Testable: No hidden mutable state makes tests straightforward
• React-friendly: React's reconciliation and memoization optimizations work correctly
• Concurrency-safe: No race conditions when data can't change

Example of the problem:

// ❌ WRONG - Mutation creates unpredictable behavior
const user = { name: "Alice", permissions: ["read"] };
grantPermission(user, "write"); // Mutates user.permissions internally
console.log(user.permissions); // ['read', 'write'] - SURPRISE! user changed

// ✅ CORRECT - Immutable approach is predictable
const user = { name: "Alice", permissions: ["read"] };
const updatedUser = grantPermission(user, "write"); // Returns new object
console.log(user.permissions); // ['read'] - original unchanged
console.log(updatedUser.permissions); // ['read', 'write'] - new version

---

Functional Light

We follow "Functional Light" principles - practical functional patterns without heavy abstractions:

What we DO:

• Pure functions and immutable data
• Composition and declarative code
• Array methods over loops
• Type safety and readonly

What we DON'T do:

• Category theory or monads
• Heavy FP libraries (fp-ts, Ramda)
• Over-engineering with abstractions
• Functional for the sake of functional

Why: The goal is maintainable, testable code - not academic purity. If a functional pattern makes code harder to understand, don't use it.