SOLID is five object-oriented design principles for maintainable, loosely-coupled code. Know each — and be ready to map them to frontend/React, since that's the real test.

The five

S — Single Responsibility Principle. A class/module/component should have one reason to change — one job. Frontend: a component that fetches data, manages form state, and renders a chart is doing three jobs — split it; extract logic into custom hooks.

O — Open/Closed Principle. Software should be open for extension, closed for modification — add behavior without editing existing code. Frontend: a Button you extend via props and composition (variant, children, render props) instead of editing its internals for every new case.

L — Liskov Substitution Principle. Subtypes must be substitutable for their base type without breaking expectations. Frontend: a custom <Input> wrapper should honor the standard input contract (accept value/onChange, forward refs) — a consumer swapping it in shouldn't get surprised. Component variants should keep a consistent contract.

I — Interface Segregation Principle. Don't force clients to depend on interfaces they don't use — prefer small, focused interfaces. Frontend: don't give a component a giant 20-prop interface; keep prop APIs minimal and focused, split big components.

D — Dependency Inversion Principle. Depend on abstractions, not concretions; high-level modules shouldn't depend on low-level details. Frontend: a component depends on a data-fetching abstraction (a hook, an injected service, Context) — not directly on axios or a specific endpoint — so it's testable and swappable.

The point of them

They all push toward the same goals: low coupling, high cohesion, easy to change, easy to test. They're guidelines, not laws — applying them dogmatically leads to over-abstraction. Use judgment.

The honest caveat

SOLID is OOP-rooted; frontend is increasingly functional/component-based. The spirit — focused units, extension over modification, depend on abstractions — translates well; the literal OOP framing less so. A senior says this rather than reciting class-based examples.

The framing

"Single Responsibility — one reason to change; in React, focused components and extracting logic into hooks. Open/Closed — extend via props and composition, don't modify internals. Liskov — variants and wrappers honor a consistent, substitutable contract. Interface Segregation — small, focused prop APIs, not 20-prop monoliths. Dependency Inversion — depend on a data abstraction like a hook or Context, not directly on axios. They all serve low coupling and testability — but they're guidelines, and since they're OOP-rooted, I apply the spirit to component-based frontend rather than the literal class framing."