Managing large applications in React - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does code splitting affect a React app's initial load?

Consider a large React app using code splitting with React.lazy and Suspense. What is the main effect on the app's initial load?

React

const LazyComponent = React.lazy(() => import('./HeavyComponent'));

function App() {
  return (
    <React.Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </React.Suspense>
  );
}

A The initial load time is unaffected because code splitting only works on server side.

B The initial load is slower because all code is bundled together and loaded at once.

C The app crashes because lazy loading is not supported in React.

D The initial load is faster because only essential code is loaded first, and heavy parts load later.

💡 Hint

Think about how loading parts of the app only when needed can help speed up the start.

Code splitting with React.lazy loads only the code needed initially, deferring heavy components until they are needed. This reduces the initial bundle size and speeds up loading.

❓ state_output

intermediate

What is the final state after multiple context updates?

Given a React context managing a counter, what is the final value of count after these updates?

React

const CountContext = React.createContext();

function CounterProvider({ children }) {
  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    setCount(c => c + 1);
    setCount(c => c + 1);
    setCount(c => c + 1);
  }, []);

  return <CountContext.Provider value={count}>{children}</CountContext.Provider>;
}

function Display() {
  const count = React.useContext(CountContext);
  return <div>{count}</div>;
}

A 3

B 1

C 0

D NaN

💡 Hint

Remember that using the updater function form of setState batches updates correctly.

Using the updater function c => c + 1 three times in one effect results in the count increasing by 3 because React batches these updates and applies them sequentially.

🔧 Debug

advanced

Why does this React app freeze on large state updates?

This React app freezes when updating a large list in state. What is the main cause?

React

function LargeList() {
  const [items, setItems] = React.useState(Array(100000).fill(0));

  function updateItems() {
    const newItems = items.map(x => x + 1);
    setItems(newItems);
  }

  return <button onClick={updateItems}>Update</button>;
}

A The entire large array is recreated and causes slow rendering on each update.

B React does not support arrays larger than 1000 items in state.

C The button's onClick handler is not properly bound, so updateItems is never called.

D The map function mutates the original array causing infinite loops.

💡 Hint

Think about what happens when you create a new large array and React re-renders.

Updating a very large array by creating a new one and setting it in state causes React to re-render the whole list, which can freeze the app due to heavy computation and rendering.

📝 Syntax

advanced

Which option correctly uses React's useContext with TypeScript?

Given a React context with a default value, which code correctly accesses the context value in a functional component using TypeScript?

React

const UserContext = React.createContext<{name: string} | null>(null);

function UserName() {
  // Access context here
}

A

const user = React.useContext(UserContext);
return <div>{user.name}</div>;

B

const user = React.useContext(UserContext)!;
return <div>{user.name}</div>;

C

const user = React.useContext(UserContext) ?? {name: 'Guest'};
return <div>{user.name}</div>;

D

const user = React.useContext(UserContext) as {name: string};
return <div>{user.name}</div>;

💡 Hint

Consider how to safely assert the context is not null when you know it will be provided.

Using the non-null assertion operator ! tells TypeScript the context value is not null, allowing safe access to user.name. Option B causes a TypeScript error because user might be null.

🧠 Conceptual

expert

What is the main benefit of using a state management library like Redux in large React apps?

In very large React applications, why do developers often choose to use Redux or similar libraries?

A To automatically optimize rendering performance without any code changes.

B To replace React's built-in state and context APIs completely for all components.

C To centralize and organize application state, making it easier to manage and debug complex state changes.

D To avoid writing any reducer functions or actions manually.

💡 Hint

Think about how managing state across many components can get complicated.

Redux centralizes state in one place, making it easier to track, update, and debug state changes in large apps. It does not automatically optimize rendering or replace React state entirely.