Frontend

Shared Concepts Study Portal

Cross-cutting frontend patterns and practices
Flash Cards Practice
Frontend / Shared Concepts / S Single Responsibility Principle SRP / Quick recall Q&A

S Single Responsibility Principle SRP · Quick recall Q&A

3 min read
Mid-level3 min read
Rapid overview

Quick recall Q&A

Q: How do you recognize SRP violations in React components? A: When a component handles data fetching, validation, form state, analytics, and rendering all in one place. High line count (>200 lines), multiple useEffect hooks with different purposes, and mixing UI with business logic are red flags.
Q: How does SRP improve deploy cadence in frontend apps? A: Focused modules let teams modify one area without risk to others—changing a validation rule doesn't require retesting data fetching logic. Reduces merge conflicts and enables independent feature deployments.
Q: Can a component coordinate other components and still obey SRP? A: Yes, if its sole responsibility is composition/coordination. For example, a CheckoutFlow component can orchestrate cart, payment, and confirmation components; its responsibility is orchestration, not implementing checkout logic itself.
features/
  user-profile/
    UserProfile.tsx
    useUser.ts
    userService.ts
    userValidators.ts
Q: How does SRP influence folder structure in frontend projects? A: Group files by feature/domain, not by type. For example:

This keeps responsibilities cohesive and discoverable.

Q: What role do hooks play in SRP (React)? A: Custom hooks extract reusable logic with focused responsibilities (useUser, useAuth, useAnalytics), ensuring components stay focused on UI rendering and composition.
Q: What role do services play in SRP (Angular)? A: Services encapsulate single responsibilities (UserService for API calls, AuthService for authentication, LoggingService for logging), keeping components focused on UI coordination via dependency injection.
Q: How do you refactor SRP violations safely in React? A: Extract logic incrementally:

Add unit tests for each extracted piece.

  1. Move data fetching to custom hooks
  2. Extract validation to utility functions
  3. Move API calls to service modules
  4. Extract analytics/logging to dedicated hooks
Q: Can modules (not just components) violate SRP? A: Absolutely. A utility module that mixes date formatting, API calls, and validation also violates SRP. Break into focused modules: dateUtils.ts, apiClient.ts, validators.ts.
Q: How does SRP impact bundle size? A: Focused modules enable better tree-shaking—unused validation logic or analytics code can be eliminated if components don't import them. Mixing responsibilities makes dead code elimination harder.
  • Pure validators can be unit tested in isolation
  • Data hooks can be tested with mock APIs
  • Components can be tested with mock dependencies
  • No need to set up entire component trees to test validation logic
Q: How does SRP improve testability in frontend? A: Testing becomes easier:
Q: What tooling catches SRP issues in frontend code? A: ESLint rules (max-lines, complexity), code review checklists, and architecture tests. Tools like dependency-cruiser can enforce module boundaries.
Q: How do you communicate SRP to product teams? A: Describe it as separating concerns like a restaurant: the waiter doesn't cook (UI doesn't handle business logic), the chef doesn't serve (business logic doesn't render), the host doesn't wash dishes (coordination doesn't include implementation details).
Q: How does SRP apply to state management (Redux, Zustand, etc.)? A: Separate concerns: actions for events, reducers for state transitions, selectors for derived data, middleware for side effects. Each piece has one clear responsibility, making the state machine predictable and testable.