Importing and exporting components in code
export function TicketRow() {
return <li>Auth ticket</li>;
}
import { TicketRow } from "./TicketRow";Read the example from data and control flow to the resulting UI. Keep the component boundary small.
Back to week 1
Topic
Importing and exporting components
Definition
ES modules expose named or default exports that other modules import to reuse component code.
In simpler words
Export a component from its file, then import it where a parent needs to render it.
Named exports, default exports, and module boundaries.
After this you can
- Share components without copying their JSX between pages.
- Explain the trade-off to a teammate using a small example.
- Name at least one common bug pattern for this topic.
Understand Importing and exporting components
Named exports, default exports, and module boundaries.
Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.
Apply Importing and exporting components
Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.
Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.
Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?
Where bugs hide
Definition
High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.
In simpler words
Each mistake below shows Wrong vs Right code — compare them side by side.
When something misbehaves, match the symptom to a pattern below before rewriting the feature.
Prefer fixing the ownership or update path over adding another Effect or sync step.
Mistake: Default vs named mismatch
// Wrong
// TicketRow.tsx
export function TicketRow() {}
// page.tsx
import TicketRow from "./TicketRow";
// Right
import { TicketRow } from "./TicketRow";
// or export default and import without braces — stay consistentImport style must match the export style.
Mistake: Circular imports
// Wrong
// A.tsx imports B; B.tsx imports A → undefined at runtime
// Right
// Extract shared bits to C.ts that both importBreak cycles with a shared module.
Mistake: Server-only in Client Component
// Wrong
"use client";
import { db } from "@/server/db";
// Right
"use client";
import { ticketsApi } from "@/lib/api";Client bundles cannot import Nest/DB modules.
Live playground
Importing and exporting components sandbox
Change one input at a time and predict the next render.
Parent imports TicketRow and composes it — same idea as import { TicketRow } from "./TicketRow".
TicketList
• Fix cookie auth
import { TicketRow } from "./TicketRow";
function TicketList() {
return (
<ul>
<TicketRow title="Fix cookie auth" />
</ul>
);
}Keep in mind
- Keep the formal definition in mind; it explains which tool belongs where.
- Prefer one source of truth over synchronized copies of the same value.
- When behavior surprises you, trace: input → update → render → committed UI.
- Study the Wrong vs Right examples in “Where bugs hide” before you merge.
Test
Check your understanding
At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥ 80% (enforced by the API) to save progress.
Checking your session…
10 questions · concept 3 · syntax 3 · practical 2 · logic 2