MDX Validation Page
Front matter metadata loaded from content/test.mdx:
{
"title": "MDX Test Page",
"description": "Validate MDX compilation and front matter parsing",
"date": "2026-03-05",
"tags": [
"mdx",
"setup"
]
}title: "MDX Test Page" description: "Validate MDX compilation and front matter parsing" date: "2026-03-05" tags:
- mdx
- setup
MDX Test Content
This file validates MDX compilation in the Next.js setup.
- It includes front matter metadata.
- It should be imported and rendered in
/mdx-test.
ProjectIntroduction Component Test
Personal Website
A statically exported personal website built with Next.js, MDX, and Tailwind CSS. Supports interactive components embedded in markdown content.
- Next.js
- TypeScript
- MDX
- Tailwind CSS
TechnicalConcept Component Test
Server Components
intermediateArchitectureReact Server Components allow rendering on the server without shipping component JavaScript to the client, reducing bundle size and improving initial load performance.
Prerequisites
- React basics
- Client/server model
Key Points
- Components render on the server by default in Next.js App Router
- No useState or useEffect — those require 'use client'
- Data fetching can happen directly inside the component
export default async function Page() {
const data = await fetch('https://api.example.com/posts');
const posts = await data.json();
return <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>;
}References
Comparison Component Test
REST vs GraphQL
Two dominant approaches to building APIs, each with distinct trade-offs for different use cases.
- Simple, well-understood conventions
- Cacheable via HTTP semantics
- Multiple endpoints per resource
- Risk of over-fetching or under-fetching
- Single endpoint, flexible queries
- Client specifies exact data shape
- Requires dedicated tooling and schema design
- Built-in introspection and type system
Choose REST for straightforward CRUD services with caching needs; prefer GraphQL when clients have diverse data requirements or you need to reduce round trips.
ExpansionBlock Component Test
ℹWhat is static site generation?
Static Site Generation (SSG) pre-renders pages at build time, producing plain HTML files that can be served from a CDN. This results in extremely fast page loads because there is no server-side computation at request time.
Key benefits include improved performance, better SEO, and simplified deployment.
💡Performance Tip: Image Optimization
Always use the Next.js Image component instead of raw <img> tags. It provides automatic lazy loading, responsive sizing, and modern format conversion (WebP/AVIF).
⚠Breaking Changes in v2.0
The getStaticProps API has been replaced by the App Router's server component data fetching pattern. Migrate existing pages before upgrading to avoid build failures.
📝A Note on Browser Compatibility
The details and summary HTML elements used by this component are supported in all modern browsers. No JavaScript is required for the expand/collapse interaction.
QuestionModule Component Test
Which rendering strategy sends zero component JS to the client?
mediumReact and Next.js support multiple rendering strategies. Understanding when JavaScript is shipped to the browser is key to optimizing performance.
AClient Components with useEffect
Incorrect.Client Components require shipping their JS bundle to the browser.BReact Server Components
Correct!Server Components render on the server and send only the resulting HTML — no component JavaScript reaches the client.CStatic Site Generation with hydration
Incorrect.SSG pre-renders HTML but still ships JS for hydration.DIncremental Static Regeneration
Incorrect.ISR regenerates pages on the server but the client still receives hydration JS.
Hint:Think about which approach was introduced specifically to avoid sending component code to the browser.