Nextjs Component Communication
Data flows down. Events flow up. Get this wrong and your app becomes a wiring nightmare.
Every component communication pattern has a cost. Props are explicit but verbose. Context is convenient but hides dependencies. URL state survives navigation but adds complexity. Choose based on scope and lifetime.
Communication Patterns
| Pattern | Scope | Lifetime | Reactivity | Best For |
|---|---|---|---|---|
| Props | Parent to child | Render cycle | Automatic | Direct data passing |
| Callback props | Child to parent | Render cycle | Manual | Event delegation |
| React Context | Subtree | Provider mount | Automatic | Theme, auth, locale |
| URL search params | Global | Navigation | Manual | Filters, pagination, sharing |
| Server Components | Server to client | Request | None (static) | Initial data, layout |
| Zustand | Global | App lifetime | Selective | Client-side shared state |
| Server Actions | Client to server | Request | Manual | Mutations, form submissions |
Decision Rule
| Question | If Yes | If No |
|---|---|---|
| Does only one child need it? | Props | Keep reading |
| Do siblings need it? | Lift state or URL params | Keep reading |
| Should it survive refresh? | URL state or server fetch | Keep reading |
| Is it global client state? | Zustand | Keep reading |
| Is it server data? | Server Component + fetch | Reconsider the requirement |
Context
- State Management — The broader state picture
- Data Fetching — Server-side data flow
- Server Components — The server-client boundary
- React Hooks — The mechanism behind most patterns
Links
Questions
What is the true cost of adding a global state layer?
- When does prop drilling become a signal to restructure rather than add context?
- How does the server-client boundary change which patterns are available?
- What communication patterns become unnecessary with server components?