3. React Architecture and Component Engineering

Introduction and Context

React is a JavaScript library for building user interfaces through composable, state-aware components. Its importance in modern frontend engineering does not arise merely from its syntax or popularity. React provides a way to model an interface as a function of application data, user interaction, and time. This model encourages developers to divide complex interfaces into manageable units, express relationships declaratively, and allow the framework to determine the most efficient way to update the browser.

At postgraduate level, React should be understood as both a programming tool and an architectural approach. Writing a component that renders a button is relatively simple. Designing a component system that remains understandable, testable, accessible, performant, and adaptable as an application grows requires considerably deeper reasoning. The developer must distinguish local state from shared state, separate reusable behavior from presentation, choose suitable component boundaries, and understand how rendering and reconciliation influence program behavior.

This chapter examines the engineering principles behind functional React components, JSX, properties, composition, hooks, context, custom hooks, error boundaries, reusable APIs, reconciliation, and lifecycle behavior. These concepts form a foundation for larger subjects such as routing, data fetching, state-management libraries, testing, server rendering, and frontend architecture.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Explain React's component model, declarative rendering model, and reconciliation process.

2. Construct functional components using JSX, props, state, and composition.

3. Select appropriate hooks and apply the Rules of Hooks correctly.

4. Distinguish local, lifted, derived, and contextual state.

5. Design custom hooks and reusable component APIs.

6. Explain effect timing, dependency behavior, cleanup, and lifecycle-like transitions.

7. Apply context and error boundaries without creating unnecessary coupling.

8. Identify common architectural, performance, accessibility, and maintainability problems.

9. Evaluate component designs in professional application scenarios.

React as a Rendering Architecture

A React application can be viewed as a tree of elements and components. A component receives inputs, commonly called props, and returns a description of the interface. In functional components, this description is produced by a function. The function should be treated as a calculation rather than as a command sequence that directly manipulates the DOM.

For example:

```jsx

function Greeting({ name }) {

return <h1>Hello, {name}</h1>;

}

```

The component does not locate an existing heading and change its text. It describes what the heading should look like for a particular value of `name`. React compares this description with the previous description and applies the necessary changes to the browser's DOM.

This declarative model has an important consequence: rendering should be pure. Given the same props, state, and relevant context, a component should produce the same output and should not cause unrelated observable effects. Network requests, subscriptions, timers, logging with operational significance, and imperative DOM operations generally belong in effects or in event handlers rather than in the rendering calculation.

A React update usually follows a conceptual sequence:

1. An event, parent update, state setter, context change, or external subscription triggers an update.

2. React renders the affected component tree to calculate a new element description.

3. React reconciles the new description with the previous one.

4. React commits required changes to the host environment, normally the browser DOM.

5. Effects are executed according to their scheduling rules.

The terms render and commit are therefore not interchangeable. Rendering is the calculation of what should exist; committing is the application of the result. A component may render without producing a visible DOM change if reconciliation determines that the resulting structure is equivalent.

JSX, Props, and Component Boundaries

JSX is a syntax extension that allows an interface description to be written in a form resembling HTML. It is transformed into JavaScript expressions that create React elements. JSX is not a template language that is independently executed by the browser. Expressions are placed inside braces, attributes are generally written using JavaScript naming conventions such as `className`, and a component must return one coherent element tree, often achieved with a fragment.

Props are read-only inputs supplied by a parent. They establish a data interface between components:

```jsx

function ProductCard({ product, onSelect }) {

return (

<article>

<h2>{product.name}</h2>

<p>{product.price}</p>

<button onClick={() => onSelect(product.id)}>Select</button>

</article>

);

}

```

The component does not modify `product` or replace `onSelect`. If a child needs to communicate upward, the parent passes a callback. This unidirectional flow makes data movement easier to trace, although deeply nested callback passing can become cumbersome.

A sound component boundary reflects a meaningful responsibility, not merely a convenient number of lines. A component may be a visual primitive, a feature component, a layout component, or a coordination component. Boundaries should be considered in relation to change: pieces that change together may belong together, while pieces that vary independently may deserve separate components.

Keys are another essential part of component identity. When rendering a collection, a key allows React to associate an element in the new tree with the corresponding element in the previous tree:

```jsx

{items.map(item => <Row key={item.id} item={item} />)}

```

Stable keys should represent domain identity. Array indexes are unsafe when items can be inserted, removed, or reordered, because React may associate existing component state with the wrong item.

Composition Rather Than Inheritance

React generally favors composition over inheritance for reuse. A component can accept children or specialized slots as props, allowing a parent to control structure while a reusable component controls common behavior and styling.

```jsx

function Panel({ title, actions, children }) {

return (

<section className="panel">

<header><h2>{title}</h2>{actions}</header>

<div className="panel-body">{children}</div>

</section>

);

}

```

This design is more flexible than a hierarchy of subclasses. `Panel` does not need to know every possible body or action. Composition also supports compound components, in which several components work together through shared context or conventions, and render-prop patterns, in which a component receives a function describing part of its output.

Reusable components should expose a deliberate API. The API includes prop names, accepted values, event semantics, ref behavior, accessibility expectations, and styling conventions. A component with dozens of unrelated boolean props often indicates an unstable API. Prefer meaningful variants, explicit slots, or composition when these make the permitted states clearer.

State, Events, and Data Ownership

State is information that can change over time and whose change may require a new render. Local state is appropriate when only one component or a small subtree needs the information. State should be owned by the lowest common ancestor that genuinely needs to coordinate it. This practice, known as lifting state up, avoids duplicated sources of truth.

```jsx

function SearchBox() {

const [query, setQuery] = useState('');

return (

<input value={query} onChange={event => setQuery(event.target.value)} />

);

}

```

Controlled components receive their current value from React state and notify changes through callbacks. Uncontrolled components allow the DOM to retain part of the value, commonly accessed through a ref. Controlled inputs provide stronger synchronization and validation, while uncontrolled inputs can be useful for simple forms or integration with non-React code.

State should not be duplicated when it can be derived. If `fullName` can be calculated from `firstName` and `lastName`, storing all three values creates a risk of inconsistency. Similarly, filtering a list during render is usually preferable to storing a second filtered-list state. State updates may be batched, so code should not assume that a setter immediately changes the current render's variable. Functional updates are appropriate when the next value depends on the previous one:

```jsx

setCount(previousCount => previousCount + 1);

```

Hooks and Function-Based Component Logic

Hooks allow functional components to use state, effects, refs, context, and other React capabilities. They must be called at the top level of a component or custom hook, never conditionally, inside loops, or inside nested ordinary functions. React relies on consistent hook call order to associate each call with its stored state.

`useState` manages local state. `useReducer` is useful when transitions are numerous, structured, or best expressed as actions. A reducer should be a pure function that receives a current state and an action and returns the next state.

`useRef` stores a mutable value that persists across renders without causing a render when changed. It is suitable for DOM references, timers, previous values, and other instance-like data that is not itself visual state. A ref should not be used as a hidden substitute for state when the interface must update.

`useEffect` synchronizes a component with an external system. Examples include subscriptions, browser APIs, timers, and network interactions. An effect may return cleanup logic:

```jsx

useEffect(() => {

const connection = connect(roomId);

return () => connection.disconnect();

}, [roomId]);

```

The dependency array describes the reactive values used by the effect. It is not merely an optimization switch. Omitting a necessary dependency can produce stale closures; adding unstable values may cause repeated synchronization. Effects should not be used to calculate values that can be calculated during rendering, nor should they be used to respond to a user event that is more naturally handled by the event handler itself.

`useMemo` and `useCallback` can preserve calculated values or function identities, but they are not general solutions for slow code. They should be introduced when identity stability has a clear purpose, such as preventing an avoidable child render or stabilizing an effect dependency, and their cost should be considered.

Context and Custom Hooks

Context provides a mechanism for making a value available to descendants without passing it through every intermediate component. It is appropriate for concerns such as theme, locale, authenticated-user information, or a carefully designed application service. Context is not automatically a replacement for all state management. If a context value changes frequently, many consumers may rerender; splitting contexts or selecting a more suitable store may be necessary.

A context provider should expose a coherent contract. It is often useful to pair the provider with a custom hook that validates usage:

```jsx

const AuthContext = createContext(null);

function useAuth() {

const value = useContext(AuthContext);

if (!value) throw new Error('useAuth must be used within AuthProvider');

return value;

}

```

Custom hooks are functions whose names begin with `use` and which encapsulate reusable stateful logic. They share behavior, not state: each call normally receives its own independent hook state. A custom hook should have a focused purpose, a clear input-output contract, and minimal knowledge of the component using it.

For example, a `useOnlineStatus` hook may subscribe to browser online and offline events, maintain a boolean state, and clean up its listeners. A `useDebouncedValue` hook may delay publication of a rapidly changing value. In both cases, the consuming component benefits from a reusable behavior without knowing subscription details.

Reconciliation, Identity, and Lifecycle Behavior

Reconciliation is React's process for comparing a new element tree with the previous tree. React uses element types, positions, keys, and props to determine which parts can be preserved and which must be replaced. If a component remains at the same identity, its state can generally be preserved. If its identity changes, its state may be reset.

Keys therefore do more than remove warnings. They control identity in lists and can intentionally reset a subtree. For example, giving a form a different key when its associated record changes can cause the form's local state to start afresh. This should be deliberate, because resetting state can also discard user input.

React does not expose class-style lifecycle methods for functional components, but lifecycle behavior can be reasoned about through mount, update, and unmount transitions. An effect setup runs after a relevant commit, and its cleanup runs before the effect is replaced or when the component is removed. Development configurations may deliberately invoke setup and cleanup more than once to reveal unsafe assumptions. Code should therefore make setup and cleanup symmetrical and idempotent.

A component should not depend on a particular number of render calls. Rendering may occur because of parent updates, development checks, interrupted work, or state changes even when the final DOM output is unchanged. The robust approach is to keep rendering pure, treat effects as synchronization, and make external operations safely repeatable.

Error Boundaries and Fault Isolation

Errors in rendering, lifecycle-like effects, or descendant component code can damage a portion of the interface. Error boundaries provide a recovery boundary that can render fallback UI when descendant rendering fails. In current React practice, error boundaries are commonly implemented with class components or through a framework-level facility; ordinary function components do not themselves become error boundaries merely by using a hook.

A useful boundary is placed around a meaningful unit such as a dashboard region, editor, or route-level feature. The fallback should communicate the problem, offer an appropriate recovery action, and avoid exposing sensitive implementation details. Error boundaries do not replace input validation, server error handling, logging, or defensive programming. They also do not automatically catch every error, such as failures in event handlers or arbitrary asynchronous callbacks; those cases require explicit handling.

An Illustrative Case: Modernising an Operations Dashboard

Background

A fictional logistics company, Northstar Freight, maintains a React operations dashboard showing shipment status, alerts, driver availability, and route metrics. The first version was built quickly. It contained large components, repeated fetching logic, duplicated filters, and numerous boolean props controlling visual variations.

Problem

Users reported that filters reset unexpectedly, dashboard cards displayed stale data, and a failure in one chart sometimes blanked the entire page. Developers were reluctant to modify the interface because changes in one component frequently affected unrelated areas.

Analysis

An architectural review identified several causes. Filter state was stored both in a parent and in individual cards. Effects had incomplete dependency arrays and therefore captured old values. Lists used array indexes as keys, causing local expansion state to move between shipments after sorting. A global context contained frequently changing dashboard data, forcing all consumers to rerender. Finally, there was no fault-isolation boundary around independent visualizations.

Approach and Solution

The team established a feature-oriented component tree. The dashboard owned shared filter state and passed a stable filter model to a results region. Each chart received only the data and callbacks it required. Repeated subscription and polling behavior was extracted into custom hooks with explicit cleanup. Stable shipment identifiers became keys. Frequently changing chart data was removed from the broad application context and supplied closer to its consumers.

The team also introduced a route-level error boundary and smaller boundaries around non-critical charts. Components adopted composition: a reusable `Panel` accepted a title, actions, and children rather than accumulating flags such as `isChart`, `hasToolbar`, and `compact`. Loading, empty, and error states became explicit parts of each feature's API.

Outcome

The redesign made ownership of state visible and reduced accidental coupling. A chart failure no longer removed the operational controls, and changing filters did not reset unrelated local interface state. The most important result was not a particular performance number but improved changeability: developers could reason about a feature without understanding the whole dashboard.

Learning Points

The case demonstrates that React architecture is primarily about boundaries and ownership. Hooks can organize behavior, but they do not compensate for unclear data flow. Context is valuable when used for genuinely cross-cutting values, while composition often produces more adaptable APIs than a growing collection of configuration flags.

Engineering Risks and Common Mistakes

Several recurring mistakes deserve explicit attention. Mutating props or state breaks assumptions about identity and makes updates difficult to trace. Copying props into state without a clear synchronization policy produces stale or conflicting values. Using effects for derived data creates unnecessary render cycles. Omitting effect dependencies leads to stale closures, while placing object literals or functions in dependencies without considering identity may cause repeated work.

Overusing context creates hidden dependencies and broad rerender surfaces. Overusing memoization makes code harder to understand and may provide no benefit. Very small components can obscure domain meaning, whereas very large components become difficult to test and evolve. Index keys, unstable keys, and random keys can all produce incorrect state preservation.

Accessibility must be treated as part of component engineering. Reusable controls should expose semantic HTML, keyboard behavior, focus management, labels, and appropriate ARIA only where native semantics are insufficient. A visually reusable button that cannot be operated by keyboard is not a successful component API.

Security and governance also matter. User-provided content should not be inserted through unsafe HTML mechanisms without rigorous sanitization. Authentication context must not be mistaken for authorization: the server must enforce permissions. Logging and error reporting should avoid exposing tokens, personal data, or confidential business information. Components handling personal or regulated information should follow organizational retention, privacy, and access policies.

Current Directions in React Engineering

Contemporary React development increasingly emphasizes concurrent rendering capabilities, server-oriented rendering models offered by supporting frameworks, streaming interfaces, and more sophisticated static analysis. These developments reinforce rather than eliminate the core principles in this chapter. Rendering must remain pure, effects must synchronize external systems carefully, and component boundaries must reflect ownership and change.

Tooling also plays an expanding role. Linters can detect Rules of Hooks violations and suspicious effect dependencies. Type systems can document component contracts, constrain variants, and improve refactoring safety. Automated tests can verify behavior, accessibility tools can identify semantic defects, and performance profiling can reveal expensive renders. AI-assisted coding may generate component scaffolding, but human review remains necessary for state ownership, security, accessibility, error handling, and architectural coherence.

Best Practices for Component Engineering

A professional React codebase commonly follows these principles:

• Keep rendering pure and place external synchronization in effects or event handlers.
• Give state a single clear owner and derive values whenever practical.
• Use stable, domain-based keys for collections.
• Prefer composition and focused APIs to inheritance and excessive boolean flags.
• Treat hooks as ordered declarations and follow the Rules of Hooks.
• Write effect cleanup that is symmetrical and safe to run repeatedly.
• Use context for stable cross-cutting concerns, not as an indiscriminate global store.
• Encapsulate repeated behavior in custom hooks with documented contracts.
• Place error boundaries around meaningful failure domains.
• Design reusable components with semantic HTML, keyboard support, and explicit loading, empty, and error states.
• Measure performance before applying memoization.
• Review privacy, security, and authorization implications of data displayed by the interface.

Chapter Summary

React architecture is based on describing interfaces as trees of composable components whose output depends on props, state, and context. JSX expresses this description, while reconciliation compares successive descriptions and preserves or replaces component identity according to types, positions, and keys. Functional components and hooks provide a unified way to manage state, references, effects, and reusable behavior, but rendering must remain pure and effects must be reserved for external synchronization.

Good component engineering depends on state ownership, purposeful boundaries, composition, stable keys, and explicit APIs. Context can simplify cross-cutting dependencies, while custom hooks encapsulate behavior without merging the state of their callers. Error boundaries isolate failures, and lifecycle behavior is best understood through render, commit, effect, cleanup, and unmount transitions. Professional React development additionally requires attention to accessibility, security, privacy, performance measurement, and maintainability.

Key Terms

Component: A reusable unit that describes a portion of a user interface and its behavior.

JSX: Syntax that expresses React element structures within JavaScript.

Props: Read-only inputs passed from a parent component to a child.

State: Data managed by a component that can change and trigger rendering.

Declarative rendering: Describing the desired interface rather than issuing direct DOM commands.

Composition: Combining components and supplied content to create flexible structures.

Hook: A function-based React mechanism for accessing state or other framework capabilities.

Effect: Code that synchronizes a component with an external system after rendering.

Ref: A persistent mutable object that does not normally trigger rendering when changed.

Context: A mechanism for providing values to descendants without explicit prop passing through every level.

Custom hook: A reusable function that composes hooks to encapsulate stateful behavior.

Reconciliation: The comparison of new and previous element descriptions to determine updates.

Commit: The phase in which React applies calculated changes to the host environment.

Key: A stable identity marker used to match elements across renders.

Controlled component: A component whose current input value is governed by React state.

Error boundary: A recovery boundary that renders fallback UI for certain descendant errors.

Stale closure: A function that refers to values from an older render than intended.

Lifting state: Moving shared state to a common ancestor that coordinates its consumers.

Pure rendering: Rendering that produces no unintended side effects and is consistent for the same inputs.

Review Questions

Short Answer Questions

1. Why should React rendering generally be pure?

2. What information does a key provide during reconciliation?

3. Distinguish a ref from state.

4. When is lifting state up appropriate?

5. What is the principal purpose of an effect cleanup function?

Long Answer Questions

1. Explain the relationship among rendering, reconciliation, committing, and effects in a React update.

2. Discuss how composition supports reusable component API design, using an illustrative example.

3. Explain the Rules of Hooks and the problems caused by violating them.

4. Compare local state, lifted state, derived data, and context as mechanisms for managing information.

5. Explain how error boundaries contribute to fault isolation and identify their limitations.

Analytical / Application Questions

1. A sortable list uses array indexes as keys and contains expandable rows. Analyze the likely behavior after sorting and propose a correction.

2. A dashboard places rapidly changing metrics in one global context, causing many unrelated components to rerender. Evaluate the design and recommend an alternative architecture.

3. A component uses an effect to calculate a filtered list from props and stores the result in state. Analyze the risks and redesign the component.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the distinction between rendering and committing in React?

A. Rendering directly changes the DOM, while committing validates props.

B. Rendering calculates a new interface description, while committing applies necessary host-environment changes.

C. Rendering runs only effects, while committing runs event handlers.

D. Rendering occurs only on mounting, while committing occurs only on unmounting.

Correct Answer: B. Rendering calculates a new interface description, while committing applies necessary host-environment changes.

Question 2

Why is an array index often an unsafe key for a reorderable list?

A. Indexes cannot be used in JSX expressions.

B. Indexes prevent React from rendering more than ten items.

C. Indexes may cause component state to become associated with a different item after insertion or reordering.

D. Indexes always cause a network request for each list item.

Correct Answer: C. Indexes may cause component state to become associated with a different item after insertion or reordering.

Question 3

Which situation is the strongest justification for using an effect?

A. Calculating a full name from first and last name.

B. Filtering an array during rendering.

C. Synchronizing a component with a browser subscription that requires cleanup.

D. Choosing between two JSX elements based on a prop.

Correct Answer: C. Synchronizing a component with a browser subscription that requires cleanup.

Question 4

A child component needs to notify its parent that a product was selected. Which design best follows React's data-flow model?

A. The child directly edits the parent's state object.

B. The parent passes a callback prop that the child invokes with the product identity.

C. The child searches the DOM for the parent and changes its properties.

D. The child stores the selection only in a ref and never communicates it.

Correct Answer: B. The parent passes a callback prop that the child invokes with the product identity.

Question 5

What is a defining characteristic of a custom hook?

A. It creates shared state automatically among all components that call it.

B. It must return JSX rather than values or functions.

C. It encapsulates reusable hook-based behavior while each call normally retains independent state.

D. It can be called conditionally because React does not track it.

Correct Answer: C. It encapsulates reusable hook-based behavior while each call normally retains independent state.

Question 6

Which use of context is most appropriate?

A. Passing a rapidly changing value to every component regardless of whether it needs it.

B. Providing a cross-cutting concern such as theme or locale to a subtree.

C. Replacing all event handlers with global mutable variables.

D. Avoiding all component boundaries in a large application.

Correct Answer: B. Providing a cross-cutting concern such as theme or locale to a subtree.

Question 7

A form must reset whenever the selected customer changes. Which React mechanism can intentionally establish a new form identity?

A. Assigning a different stable key based on the customer identity.

B. Mutating the existing form's props during rendering.

C. Calling a hook conditionally when the customer changes.

D. Using an array index as the form key.

Correct Answer: A. Assigning a different stable key based on the customer identity.

Question 8

Which statement about error boundaries is accurate?

A. Every function component becomes an error boundary when it uses useEffect.

B. Error boundaries can provide fallback UI for certain descendant rendering failures but do not replace event-handler error handling.

C. Error boundaries guarantee that server authorization errors are resolved.

D. Error boundaries prevent all asynchronous failures automatically.

Correct Answer: B. Error boundaries can provide fallback UI for certain descendant rendering failures but do not replace event-handler error handling.

Question 9

A developer adds useMemo to every calculated value without measuring performance. What is the principal concern?

A. useMemo permanently stores values in the database.

B. useMemo changes all values into strings.

C. Unnecessary memoization increases complexity and may provide no meaningful benefit.

D. useMemo prevents components from receiving props.

Correct Answer: C. Unnecessary memoization increases complexity and may provide no meaningful benefit.

Question 10

Which design most directly reduces the risk of duplicated and inconsistent state?

A. Store both source data and every derived representation in state.

B. Keep a single clear owner for shared state and derive filtered or combined values during rendering when practical.

C. Place all values in one global context regardless of update frequency.

D. Use refs for every value that appears in the interface.

Correct Answer: B. Keep a single clear owner for shared state and derive filtered or combined values during rendering when practical.