skip to content

In a component library, why render each component in isolation in a component workshop instead of only reviewing it inside the running app?

level: juniorimportance: should knowfreq 50%

answer

  1. reaching a state on demand
  2. no login, no backend, no route
  3. hidden dependencies surface
  4. build before the page exists
  5. isolation cannot show the real page

basics

~20 s

Isolation makes every state reachable on demand without the app's data, login or routes, lets teams build before pages exist, and exposes hidden dependencies. It cannot show real page layout or data, so it complements in-app review.

solid answer

~50 s

A **component workshop** renders each library component on its own, outside any app, with named examples of its variants and states. Inside the running app, reaching a state often needs specific data and steps: in a vet clinic booking app, seeing the slot picker's *fully booked* day means filling a real clinic's calendar. In the workshop it is one click. Isolation also lets a component be built and reviewed before any page uses it, gives designers, engineers and QA one shared place to look, and **exposes hidden dependencies**: a component that will not render without the app's user store or router was never really reusable. What isolation cannot show is how the component behaves on a real page — layout next to real neighbours, real data volumes — so it complements in-app review rather than replacing it. Native teams get the same benefit from preview catalogs.

go deeper

for a junior

Recall what a component workshop is and the main win: every state of a component reachable on demand without the app's data or navigation.

for a middle

Explain how isolation exposes hidden dependencies on app context, and list what isolation cannot show about real pages.

for a senior

Show how you would bring a library whose components only render inside the app into a workshop, turning each dependency into an explicit input.

for a principal

Decide how much the organisation invests in the workshop versus in-app review, and how it serves web and native teams from one set of component specs.

## What a component workshop is A **component workshop** is a separate environment that renders library components one at a time, outside any product app. Each component has a set of **examples** — a named rendering with specific inputs and data, such as *slot picker, fully booked day* — and often **property controls** that let a viewer change inputs live. Web teams usually run it as a small standalone site; native mobile teams get the same thing from preview panes and in-app catalog screens. The idea is identical: see each component in each state without the rest of the product. ## What isolation buys | Need | In the running app | In the workshop | |---|---|---| | See a rare state | set up data, log in, navigate, often ask a backend team | open the named example | | Work before the page exists | wait for the page, or fake one | build and review the component alone | | Share a reference | a screenshot or a staging link that changes | a stable link to an example | | Spot app-context coupling | hidden, because the app supplies everything | fails to render, loudly | ## A worked example: the slot picker A veterinary clinic booking app has an **appointment slot picker**. Its states include: loading, a normal day, *one slot left*, *fully booked*, *clinic closed* for a public holiday, and *could not load availability*. In the running app, the fully booked and error states are hard to reach: someone has to fill a clinic's calendar or break the availability service. In the workshop, each is an example with mocked data, reachable in one click, by a designer checking copy, an engineer fixing spacing or a tester writing a checklist. ## Isolation exposes hidden dependencies When a component will not render in the workshop, the workshop is usually telling the truth: - It reads the **logged-in user** from a global store instead of taking what it needs as input. - It depends on the **current route** or a page-level provider it never declared. - It **fetches its own data** from inside, so it cannot be shown without a live backend. - It relies on **styles the app happens to load** globally. Each of these is a reuse problem the product would hit sooner or later in a second app. The fix is to make the dependency an explicit input or a documented context, which is also what makes the component usable in the workshop. A library component that renders cleanly in isolation is, almost by definition, one that other apps can adopt. ## What isolation cannot show Isolation is a strength and a blind spot: - **Real layout.** How the picker sits beside the real sidebar and form at an awkward screen width. - **Real data.** A clinic with forty vets, or pet names in scripts nobody mocked. - **Interaction with neighbours.** Focus moving from the picker into the next field, or two overlays competing. - **Real performance.** A month view with thousands of real slots. So the workshop is where a component is built and reviewed, and the running app is where its integration is checked. Treating a green workshop as proof that every page is fine is the mistake. ## Who uses it - **Designers** compare each built state with the design and catch missing or wrong states before release. - **Engineers** build and debug one component at a time, and reproduce a bug by opening the example that shows it. - **Testers** turn the list of examples into a checklist of states to cover. - **Product and support staff** see what a user is describing — *the card said overdue* — without reproducing it in production. - **Native teams** compare their implementation with the web one, state by state. ## Keeping the workshop honest 1. **Same build and theme as consumers.** Examples should load the component the way apps do, so what the workshop shows is what users get. 2. **Examples next to the component.** Kept in the same place as the component's code, they change in the same review. 3. **Reviewed in every change.** A reviewer opens the affected examples instead of reading code alone. 4. **Owned.** Broken examples are fixed like broken builds, or the catalog quietly rots and people stop trusting it.

  • The slot picker renders in the app but not in the workshop without the app's session store. What do you do?
    Treat it as a finding, not a workshop problem. Identify what the picker actually needs from the session — perhaps just the clinic identifier and the user's time zone — and make those explicit inputs, or a documented context the example can supply. The component becomes reusable, and the example renders with plain mocked values.
  • A product manager says the workshop is redundant because QA tests the real app. How do you respond?
    They answer different questions. The app shows integration: layout, real data, flows. The workshop shows every state of one component on demand, including states QA rarely reaches, and lets teams build and review before pages exist. Removing it means rare states get seen for the first time by users.

A mechanic's test bench runs an engine outside the car, so every speed and fault can be tried on demand; whether it fits under this car's hood still has to be checked in the car.

saying these in an interview costs you the question

  • If a component looks right in the workshop, it will look right on every page.
  • A component that fails in isolation just needs the workshop to load the whole app.
  • The workshop replaces reviewing components inside the running app.
  • Rare states can be checked later in staging when they come up.
  • Isolation is only useful for designers, not engineers.