Deck 16 - React App Architecture / Component API Design

Question 1

Deck 16 - React App Architecture / Component API Design (objective)

Answer 1

Goal: design and review React app architecture like a senior: boundaries, state placement, data flow, component APIs, and maintainable patterns.
You learn: what/why (under the hood), common anti-patterns, and evaluator-grade review wording.
Output style: PASS/PARTIAL/FAIL + 2-3 issues + fix approach.

Question 2

Mental model: separation of concerns (UI vs domain vs data).

Answer 2

UI components render and handle interactions.
Domain logic (rules/transforms) should be testable without React.
Data layer handles fetching/caching/serialization at boundaries.

Question 3

Mental model: boundaries reduce blast radius.

Answer 3

Well-defined boundaries make changes local.
Examples: API client boundary, feature modules, component boundaries.

Question 4

Mental model: colocate state by ownership.

Answer 4

State should live at the lowest common ancestor of the components that need it.
Avoid lifting too high (prop drilling) and too low (duplicated state).

Question 5

Mental model: derived state should be computed, not stored.

Answer 5

If you can derive it from props/state, compute it (useMemo when needed).
Storing derived state causes sync bugs and extra effects.

Question 6

Mental model: single source of truth.

Answer 6

Avoid duplicate sources for the same truth (server cache + local copy + URL state).
Pick the authority and derive others from it.

Question 7

Mental model: state types - server vs client vs UI.

Answer 7

Server state: fetched data, cached (React Query).
Client state: local app state (auth, preferences).
UI state: transient (open modal, input text).

Question 8

Mental model: push side effects to the edges.

Answer 8

Keep components mostly pure.
Do IO in hooks/services; keep rendering code deterministic.

Question 9

Mental model: dependencies flow down, events flow up.

Answer 9

Data and configuration typically flow down via props/context.
User actions bubble up via callbacks or state updates.

Question 10

Mental model: composition over inheritance.

Answer 10

React encourages composing components and hooks.
Avoid class inheritance patterns; prefer composition and render props/children patterns when needed.

Question 11

Mental model: component API should prevent invalid states.

Answer 11

Use prop types/unions to make misuse hard.
Example: Button with href vs onClick - enforce correct combinations.

Question 12

Mental model: stable public interfaces matter.

Answer 12

Treat shared components as public APIs.
Breaking changes ripple across app; document and version patterns if needed.

Question 13

Mental model: measure complexity as you design.

Answer 13

Complexity increases with props count, conditional branches, and cross-cutting concerns.
Split responsibilities rather than growing ‘god components’.

Question 14

Mental model: file/module organization by feature.

Answer 14

Feature folders reduce coupling vs type-based folders.
Example: features/orders/* with components, hooks, api, tests together.

Question 15

Mental model: avoid global context for everything.

Answer 15

Context is great for truly global concerns.
Overuse causes rerenders, coupling, and hidden dependencies.

Question 16

Mental model: a ‘container/presenter’ split is a tool, not a rule.

Answer 16

Containers handle data and state; presenters render.
Use when it reduces complexity; do not force it everywhere.

Question 17

Mental model: state machines for complex flows.

Answer 17

For multi-step flows (auth, checkout), model states explicitly.
Prevents impossible UI states and makes logic testable.

Question 18

Mental model: URL as state (when appropriate).

Answer 18

Filters/search/sort/pagination often belong in URL for shareability.
Avoid putting everything in URL (sensitive data, huge payloads).

Question 19

Mental model: the cost of prop drilling vs context vs store.

Answer 19

Prop drilling is explicit but noisy.
Context reduces plumbing but can hide dependencies.
Stores (Redux) are powerful for complex shared state; avoid for trivial UI state.

Question 20

Mental model: performance is architecture too.

Answer 20

Bad boundaries cause unnecessary rerenders.
Design for predictable render graphs and stable props.

Question 21

Pattern: lift state to lowest common ancestor (rule).

Answer 21

If two siblings need to coordinate, lift state to their parent.
If only one component needs it, keep it local.

Question 22

Pattern: avoid syncing props into state.

Answer 22

Copying props to state creates stale bugs.
Prefer deriving from props or use controlled patterns.

Question 23

Pattern: controlled vs uncontrolled component API.

Answer 23

Controlled: value + onChange from parent.
Uncontrolled: internal state with defaultValue.
Provide both only when necessary; document behavior.

Question 24

Pattern: expose events, not internals.

Answer 24

Component APIs should communicate via callbacks (onSelect, onSubmit).
Avoid exposing internal refs/state unless needed (imperative handle).

Question 25

Pattern: useContext for truly global config.

Answer 25

Theme, i18n, auth session, feature flags. Avoid putting frequently changing values in context unless optimized.

Question 26

Pattern: split contexts by update frequency.

Answer 26

Separate read-only config context from rapidly changing state context. Why: reduces rerender fan-out.

Question 27

Pattern: reducer for complex local state.

Answer 27

useReducer helps when transitions are complex or related. Prefer over many related useState calls; model actions and state transitions.

Question 28

Pattern: domain logic outside components.

Answer 28

Put transforms/formatters/validators in utils/domain modules. Why: testable, reusable, avoids rerender hazards.

Question 29

Pattern: dependency injection via props for testability.

Answer 29

Inject services (api client) or functions for unit testing. Avoid hard-coding globals that are hard to mock.

Question 30

Pattern: error boundaries for crash containment.

Answer 30

Wrap risky areas to prevent whole app crash. Provide fallback UI and logging.

Question 31

Pattern: module boundaries (feature slices).

Answer 31

Keep feature-level routing, API calls, and components together. Expose minimal surface area; avoid cross-feature imports.

Question 32

Pattern: avoid circular dependencies.

Answer 32

Circular imports cause runtime undefined and bundler quirks. Fix by extracting shared code into a lower-level module.

Question 33

Pattern: standardize component layering.

Answer 33

Examples: ui/ (pure), components/ (composed), features/ (business), pages/ (route-level). Consistency makes reviews faster.

Question 34

Pattern: composition via children and slots.

Answer 34

Accept children or render props for flexible layouts. Prefer over prop explosion when adding optional UI regions.

Question 35

Pattern: use 'variants' not booleans for styling.

Answer 35

Use variant: 'primary'|'secondary' rather than many booleans. Prevents invalid combinations and keeps API stable.

Question 36

Pattern: keep side effects in hooks.

Answer 36

Move fetch/subscriptions/timers into hooks. Components remain pure and easier to reason about.

Question 37

Pattern: choose state store only when needed.

Answer 37

Redux/Zustand/Context: use for cross-cutting client state. Do not use store for server cache (use React Query) or trivial UI toggles.

Question 38

Pattern: normalize shared data when needed.

Answer 38

For large entities referenced in many places, normalized caches reduce duplication. But avoid premature normalization for small apps.

Question 39

Pattern: prefer explicit data flow over magic.

Answer 39

Avoid hidden coupling via global singletons. Explicit props/context makes dependencies visible to reviewers.

Question 40

Pattern: document contracts with types.

Answer 40

Define public prop types, action types, and API response types. Types are part of the architecture contract.

Question 41

Gotcha: prop drilling 8 levels deep. ``` ```

Answer 41

PARTIAL - Excessive drilling increases coupling. Consider lifting only where needed, extracting a feature component, or using context/store for truly shared state.

Question 42

Gotcha: copying props into state. ``` function Comp({ value }: { value: string }) { const [v, setV] = useState(value); // ... } ```

Answer 42

FAIL - State can go stale when props change. Prefer controlled component (use value directly) or handle prop changes explicitly with derived logic.

Question 43

Gotcha: boolean soup API. ``` type Props = { primary?: boolean; secondary?: boolean; danger?: boolean }; ```

Answer 43

PARTIAL - Invalid combinations possible. Use a variant union and restrict allowed combinations.

Question 44

Gotcha: mixing server and UI state (duplicate source).

Answer 44

FAIL - Duplicating server data into local state causes drift and bugs. Use server cache as source of truth and derive UI views from it.

Question 45

Gotcha: context used for fast-changing values.

Answer 45

PARTIAL - Large rerender fan-out. Split context, memoize provider values, or move hot state closer to consumers.

Question 46

Gotcha: giant component with fetching + rendering + transforms. ``` function Page() { // fetch // parse // map // format // render table + modals + forms } ```

Answer 46

PARTIAL - Hard to test and review. Split into: data hook + domain transforms + presentational components.

Question 47

Gotcha: component API exposes internal state shape.

Answer 47

PARTIAL - Leaky abstraction. Expose intent-based props/events instead of internal implementation details.

Question 48

Gotcha: passing unstable inline objects causing rerenders. ``` ```

Answer 48

PARTIAL - New object each render can bust memoization. Memoize or move constants outside render.

Question 49

Gotcha: using index as key for dynamic list.

Answer 49

FAIL - Can cause state bugs on reordering/inserts. Use stable unique keys from data.

Question 50

Gotcha: imperative DOM manipulation instead of state.

Answer 50

PARTIAL - Bypasses React rendering model and can desync UI. Prefer state-driven UI; use refs only for escape hatches.

Question 51

Gotcha: custom hook doing too much.

Answer 51

PARTIAL - Hooks should have a clear responsibility. Split into smaller hooks and compose them.

Question 52

Gotcha: hidden cross-feature import.

Answer 52

PARTIAL - Importing deep internals of another feature increases coupling. Export a public API from the feature root.

Question 53

Gotcha: no error boundary for risky subtree.

Answer 53

PARTIAL - Unhandled errors can crash entire app. Add error boundary around isolated sections and log/report.

Question 54

Gotcha: context provider value not memoized. ``` ```

Answer 54

PARTIAL - New value object triggers rerenders. Wrap value in useMemo or separate stable actions from changing state.

Question 55

Gotcha: callback prop name mismatch (API clarity).

Answer 55

PARTIAL - Inconsistent naming (onClick vs handleClick) confuses consumers. Prefer 'onX' for events; keep conventions consistent.

Question 56

Gotcha: prop named 'data' with unclear shape.

Answer 56

PARTIAL - Low clarity. Use specific names (users, orders) and strong types to communicate contract.

Question 57

Gotcha: duplicated validation logic in multiple components.

Answer 57

PARTIAL - Move validation to domain/util module or shared schema. Single source reduces drift.

Question 58

Gotcha: storing derived data in state. ``` const [fullName, setFullName] = useState(first + ' ' + last); ```

Answer 58

FAIL - Derived state can drift. Compute fullName from first/last (memoize if expensive).

Question 59

Gotcha: mixing navigation concerns into leaf components.

Answer 59

PARTIAL - Makes component less reusable. Prefer passing href or action callback from parent/router layer.

Question 60

Gotcha: over-using global store for UI toggles.

Answer 60

PARTIAL - Increases complexity and coupling. Keep local UI state local unless multiple distant areas truly need it.

Question 61

Mini-drill: reviewer wording for prop-to-state anti-pattern.

Answer 61

FAIL - Component copies props into local state, which can become stale when props update. Prefer controlled pattern or derive UI directly from props.

Question 62

Mini-drill: reviewer wording for boolean soup.

Answer 62

PARTIAL - Multiple boolean props create invalid combinations and unclear API. Replace with a single variant prop (union) and enforce allowed combos.

Question 63

Mini-drill: reviewer wording for context rerender issue.

Answer 63

PARTIAL - Context value changes on every render, causing broad rerenders. Memoize provider value or split context by update frequency.

Question 64

Mini-drill: reviewer wording for giant component.

Answer 64

PARTIAL - Component mixes data fetching, transforms, and UI rendering. Split into a data hook + pure presentational components for clarity and testability.

Question 65

Mini-drill: verdict on cross-feature deep imports.

Answer 65

PARTIAL - Importing internal modules across features increases coupling. Expose a public API from the feature root and import from there.

Question 66

Checklist: architecture review top 10.

Answer 66

1) Clear boundaries (feature/data/domain) 2) State placement correctness 3) No duplicated sources of truth 4) Derived state computed, not stored 5) Component APIs prevent invalid combos 6) Side effects isolated in hooks 7) Context usage scoped and optimized 8) Stable keys and stable props 9) Error handling boundaries 10) Testability and dependency injection

Question 67

Pattern: presentational + container (example). ``` // Container function UsersPage() { const { data, isLoading } = useUsers(); return ; } // Presentational function UsersTable({ users, loading }: { users: User[]; loading: boolean }) { if (loading) return ; return

{users.map(u =>
• {u.name}
)}

; } ```

Answer 67

PASS - Fetching/state in container; rendering in presentational component. Improves testability and isolates side effects.

Question 68

Pattern: discriminated props for component variants (example). ``` type ButtonProps = | { kind: 'button'; onClick: () => void; href?: never } | { kind: 'link'; href: string; onClick?: never }; function Action(props: ButtonProps) { return props.kind === 'link' ? Go : Do; } ```

Answer 68

PASS - API prevents invalid combinations and documents intent.

Question 69

Pattern: split context by update frequency (example). ``` const AuthStateCtx = createContext(null); const AuthActionsCtx = createContext<{ logout: () => void } | null>(null); ```

Answer 69

PASS - Reduces rerender fan-out by separating changing state from stable actions.

Question 70

Pattern: URL state for filters (high level).

Answer 70

Use URL query params for search/sort/page when shareable and bookmarkable. Keep validation and defaults centralized (parse + serialize functions).

Question 71

Anti-pattern: store server cache in Redux (why).

Answer 71

Server cache needs normalization/invalidation and is solved by React Query/SWR. Redux is better for client state and app events; do not duplicate server cache.

Question 72

Anti-pattern: useEffect for derived state syncing.

Answer 72

Effects to keep state in sync are usually a smell. Prefer deriving values directly in render or using memoization.

Question 73

Anti-pattern: magic context for everything.

Answer 73

Global context hides dependencies. Prefer explicit props or feature-scoped context; reserve app-level context for truly global concerns.

Question 74

Mini-drill: decide where state belongs (rule).

Answer 74

If only one component needs it: local state. If siblings coordinate: lift. If many distant consumers: context/store. If fetched: server cache.

Question 75

Mini-drill: component API design one-liner.

Answer 75

A good component API makes correct usage easy and incorrect usage hard (via types, naming, and defaults).

Question 76

Mini-drill: review wording for duplicated source of truth.

Answer 76

FAIL - Data is duplicated across state sources (server cache + local copy), causing drift. Keep a single authority and derive the UI view from it.

Question 77

Mini-drill: review wording for derived state.

Answer 77

FAIL - Derived value is stored in state and can get out of sync. Compute it from inputs (memoize if expensive) instead.

Question 78

Mini-drill: review wording for unstable props objects.

Answer 78

PARTIAL - Inline objects/functions create unstable props and can trigger rerenders. Memoize or hoist constants where appropriate.

Question 79

Mini-drill: review wording for state machine need.

Answer 79

PARTIAL - Flow has multiple dependent states and edge cases. Model it as a state machine/discriminated union to prevent impossible UI states.

Question 80

Mini-drill: review wording for leaky component API.

Answer 80

PARTIAL - Component exposes internal implementation details via props. Prefer intent-based props/events and keep internals encapsulated.