Udit Takkar
7a9fdd5a0c
## What does this PR do? This PR adds https://vercel.com/blog/introducing-react-best-practices for your coding agent using `npx add-skill vercel-labs/agent-skills` command The skills are added to `.claude/`, `.cursor/`, and `.opencode/` directories to provide React and Next.js performance optimization guidance for AI-assisted workflows. ## Updates since last revision Addressed Cubic AI review feedback for issues with confidence >= 9/10: - **rerender-dependencies.md** - Replaced `console.log(user.id)` with `fetchUserDetails(user.id)` to avoid logging sensitive information - **server-after-nonblocking.md** - Removed `sessionCookie` from `logUserAction` call to avoid logging sensitive authentication data, added `await` to async call - **bundle-conditional.md** - Added `loadError` state and `setLoadError` setter to fix undefined `setEnabled` reference - **advanced-event-handler-refs.md** - Updated `useWindowEvent` handler signature to accept `Event` parameter and forward it to the stored handler - **rerender-derived-state.md** - Closed `<nav>` elements in both examples for valid JSX Fixes applied to both `.claude` and `.cursor` skill directories for consistency. ## Mandatory Tasks (DO NOT REMOVE) - [x] I have self-reviewed the code (A decent size PR without self-review might be rejected). - [x] N/A I have updated the developer docs in /docs if this PR makes changes that would require a [documentation change](https://cal.com/docs). If N/A, write N/A here and check the checkbox. - [x] N/A, I confirm automated tests are in place that prove my fix is effective or that my feature works. ## How should this be tested? These are documentation files for AI coding agents. No runtime testing required - review the markdown files to verify the example code snippets are correct. ## Checklist for human review - [ ] Verify example code snippets in the skill files are syntactically correct - [ ] Confirm the fixes don't introduce new issues in the documentation examples - [ ] Check that `.claude` and `.cursor` directories have consistent content --- Link to Devin run: https://app.devin.ai/sessions/f7f7e67fdeea4b22a4817d63ed9e1759 Requested by: unknown ()
2.5 KiB
2.5 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Strategic Suspense Boundaries | HIGH | faster initial paint | async, suspense, streaming, layout-shift |
Strategic Suspense Boundaries
Instead of awaiting data in async components before returning JSX, use Suspense boundaries to show the wrapper UI faster while data loads.
Incorrect (wrapper blocked by data fetching):
async function Page() {
const data = await fetchData() // Blocks entire page
return (
<div>
<div>Sidebar</div>
<div>Header</div>
<div>
<DataDisplay data={data} />
</div>
<div>Footer</div>
</div>
)
}
The entire layout waits for data even though only the middle section needs it.
Correct (wrapper shows immediately, data streams in):
function Page() {
return (
<div>
<div>Sidebar</div>
<div>Header</div>
<div>
<Suspense fallback={<Skeleton />}>
<DataDisplay />
</Suspense>
</div>
<div>Footer</div>
</div>
)
}
async function DataDisplay() {
const data = await fetchData() // Only blocks this component
return <div>{data.content}</div>
}
Sidebar, Header, and Footer render immediately. Only DataDisplay waits for data.
Alternative (share promise across components):
function Page() {
// Start fetch immediately, but don't await
const dataPromise = fetchData()
return (
<div>
<div>Sidebar</div>
<div>Header</div>
<Suspense fallback={<Skeleton />}>
<DataDisplay dataPromise={dataPromise} />
<DataSummary dataPromise={dataPromise} />
</Suspense>
<div>Footer</div>
</div>
)
}
function DataDisplay({ dataPromise }: { dataPromise: Promise<Data> }) {
const data = use(dataPromise) // Unwraps the promise
return <div>{data.content}</div>
}
function DataSummary({ dataPromise }: { dataPromise: Promise<Data> }) {
const data = use(dataPromise) // Reuses the same promise
return <div>{data.summary}</div>
}
Both components share the same promise, so only one fetch occurs. Layout renders immediately while both components wait together.
When NOT to use this pattern:
- Critical data needed for layout decisions (affects positioning)
- SEO-critical content above the fold
- Small, fast queries where suspense overhead isn't worth it
- When you want to avoid layout shift (loading → content jump)
Trade-off: Faster initial paint vs potential layout shift. Choose based on your UX priorities.