Separation of Concerns: UI vs. Business Logic

A component's JavaScript controller class should focus on UI concerns — reactive state, event wiring, rendering decisions. Genuine business logic — validation rules, calculations, data transformation — belongs somewhere more reusable: either an Apex service class (server-side, Lesson 2) or a plain, importable JavaScript utility module (client-side, using Module 4's import/export).

Business logic embedded directly inside a component's event handler is hard to reuse in a second component that needs the same rule, and hard to unit test in isolation from the component's rendering — a Jest test (Module 14) ends up needing to simulate a whole component just to verify a calculation that has nothing to do with rendering at all.

// Before — business logic buried inside a UI event handler
handleApplyDiscount() {
    let discount = 0;
    if (this.orderTotal > 1000) {
        discount = this.orderTotal * 0.1;
    } else if (this.orderTotal > 500) {
        discount = this.orderTotal * 0.05;
    }
    this.finalTotal = this.orderTotal - discount;
}

// discountUtils.js — reusable, independently testable
export function calculateDiscount(orderTotal) {
    if (orderTotal > 1000) return orderTotal * 0.1;
    if (orderTotal > 500) return orderTotal * 0.05;
    return 0;
}

// After — the component delegates the actual calculation
import { calculateDiscount } from './discountUtils';

handleApplyDiscount() {
    const discount = calculateDiscount(this.orderTotal);
    this.finalTotal = this.orderTotal - discount;
}

calculateDiscount can now be tested directly with plain values, reused by any other component that needs the same rule, and changed in one place rather than several.

The same principle applies to Apex controllers exposed via @AuraEnabled (Module 7) — they should stay thin, delegating real business logic to separate service classes rather than embedding it directly in the LWC-facing method. Lesson 2 covers this exact layering in depth.