Component Design — Series 2

Preview — 3 of 10 questions

Why is Card considered more flexible/reusable than a version hardcoding a specific title/body structure like <Card title={...} body={...} />?

javascript

function Card({ children }) {
  return <div className="card">{children}</div>;
}

function App() {
  return (
    <Card>
      <h2>Title</h2>
      <p>Some content.</p>
    </Card>
  );
}

Achildren lets the caller pass any arbitrary JSX structure — not just a title and body, but any combination of elements (a form, a list, another component) — Card doesn't need to know or care what's inside it, only that it should wrap whatever's given in its card styling; a title/body prop version would need new named props (or a rewrite) every time a caller needs a structure that doesn't fit that exact two-slot shape

BIt isn't more flexible — both approaches produce identical component APIs with no meaningful difference

Cchildren is required by React for any component with more than one child element

DThis pattern only works for text content — passing other components as children is not supported

MouseTracker doesnt render any specific visible output itself — it takes a `render` prop, which is a function. What does this pattern let the caller control that a hardcoded internal render wouldnt?

javascript

function MouseTracker({ render }) {
  const [position, setPosition] = useState({ x: 0, y: 0 });
  return (
    <div onMouseMove={e => setPosition({ x: e.clientX, y: e.clientY })}>
      {render(position)}
    </div>
  );
}

// Usage:
<MouseTracker render={(pos) => <p>Mouse at {pos.x}, {pos.y}</p>} />

Arender must always be a class component instance, never a plain function — this pattern only works with class-based render props

BMouseTracker owns and tracks the actual mouse-position state/logic, but hands the decision of what to actually display with that data entirely to the caller — different usages of MouseTracker can render completely different UI (a tooltip, a custom cursor, plain text, a chart) from the exact same underlying position-tracking logic, without needing to modify MouseTracker itself for each different display need

CThis pattern is functionally identical to just calling useState directly in the consuming component — there's no actual benefit to wrapping it this way

Drender can only return plain strings, never JSX elements

What does withLoading actually do, structurally?

javascript

function withLoading(Component) {
  return function WithLoadingWrapper({ isLoading, ...rest }) {
    if (isLoading) return <Spinner />;
    return <Component {...rest} />;
  };
}

const UserProfileWithLoading = withLoading(UserProfile);

// Usage:
<UserProfileWithLoading isLoading={loading} user={user} />

AIt's a function that takes a component as input and returns a new component that wraps the original — adding the shared "show a spinner while loading, otherwise render the wrapped component with the remaining props" behavior around whatever component is passed in, without needing to modify that component's own definition at all; the same withLoading function could wrap any number of different components, each gaining the same loading behavior

BIt permanently modifies UserProfile's own source code/definition, adding loading behavior directly into it

CwithLoading can only be applied to a single specific component — UserProfile — and cannot be reused for any other component

DThis pattern requires class components — it cannot wrap function components like UserProfile

Answer all 10 questions (7 more), see explanations for every answer, and track your score.