🎤 Top 81 Interview Questions
Yeh sabse common Java interview questions hain — tap karke answer kholo.
Vercel dwara maintain kiya jaane waala, EK React framework hai — server-side rendering, static site generation, aur file-based routing "out of the box" provide karta hai.
React, EK library hai (UI banane ke liye). Next.js, EK framework hai jo React ke upar bana hai aur routing, data fetching, bundling jaisi extra pieces add karta hai.
Jab SEO ya SSR ki zaroorat ho — pure client-side dashboards (jahan SEO matter nahi karta) ke liye, plain React kaafi ho sakta hai.
Routes aur pages ko hold karta hai — har folder EK URL segment represent karta hai, aur page.js uski content DEFINE karta hai.
Static assets (images, fonts, favicon) ke liye — directly root URL se accessible hote hain (jaise /logo.png).
Ek naya Next.js project setup karta hai — interactive prompts mein TypeScript, ESLint, Tailwind, aur App/Pages Router jaisi choices poochta hai.
dev = development server (hot reload). build = production build banata hai. start = production server run karta hai (build ke baad).
Ye MODERN aur actively developed routing system hai — purane "Pages Router" ke mukable mein.
File-based hai — app/ folder ke andar har subfolder EK URL segment represent karta hai, page.js woh component hai jo us route par render hota hai.
Shared UI define karta hai jo multiple pages ke beech persist karta hai (jaise navigation sidebar) — page navigate karne par layout re-render nahi hota.
Square brackets mein ek folder naam, ek dynamic segment define karta hai — jaise app/blog/[slug]/page.js, /blog/anything ko match karta hai.
Multiple segments ko match karte hain — jaise /shop/a/b/c.
<html> aur <body> tags isi mein define hote hain — App Router ke liye zaroori hai.
Nahi — jab user ek sibling page par navigate karta hai, sirf page.js ka content change hota hai, layout preserve rehta hai.
URL structure ko affect nahi karte — sirf code organization aur DIFFERENT root layouts banane ke liye use hote hain.
params, ek Promise hai — async function ke andar await params se access karna padta hai, directly access karne ke bajaye.
HAR request PAR server PAR HTML generate hota hai — SEO ke liye good hai, lekin server PAR har request ke saath computation hoti hai.
Pages BUILD-TIME PAR hi HTML mein generate ho jaate hain — runtime PAR koi server computation nahi hota.
SSG ki speed aur SSR ki freshness ko combine karta hai — pages statically generate hote hain lekin ek specified interval ke baad background mein revalidate ho jaate hain.
Agar woh koi dynamic function (cookies, headers, search params) use nahi karta.
Batata hai ki build-time PAR kaun si dynamic pages generate karni hain.
N seconds ke baad, data ko stale mark karta hai — agla request purani (stale) copy instantly dekhta hai, background mein nayi copy generate hoti hai.
Ek component ko browser mein render/hydrate hone ke liye mark karta hai — interactive features (onClick, useState) ke liye zaroori hai.
Directly async/await use karke — koi useEffect ya useState loading pattern ki zaroorat nahi.
Individual fetch() calls ke results ko cache karti hai — persist hota hai multiple requests aur deployments ke beech.
Poore rendered HTML ko cache karta hai (static routes ke liye).
Browser mein recently visited routes ko cache karti hai — navigation instant feel hoti hai.
revalidatePath(), ek specific path ko invalidate karta hai. revalidateTag(), tagged fetch calls ko invalidate karta hai — specific data ko target karke.
Har fetch, previous ke complete hone ka wait karta hai, chahe woh ek dusre PAR depend na karte hon — total time SUM ho jaata hai.
Multiple independent fetches ko parallel mein start karta hai — total time slowest request ke barabar hota hai, SUM ke bajaye.
App Router mein DEFAULT hai — server PAR render hota hai, aur uska JavaScript code client ko kabhi bheja nahi jaata.
Interactivity ke liye JavaScript runtime chahiye, jo server par nahi hai.
"use client" se mark kiya gaya component — browser mein hydrate/render hota hai, hooks aur browser APIs use kar sakta hai.
Haan, props pass karke. Lekin ULTA nahi — Client Component, directly Server Component import nahi kar sakta.
children ki tarah — ye "slot" pattern, ek Client Component ko Server Component content render karne deta hai, bina use "use client" mein convert kiye.
JITNA possible ho "leaf" (sabse neeche ke) components mein — poore page ko "use client" mark karne se bundle size badh jaata hai.
Ek file ko client component mein import hone se rokta hai — accidental leaks (jaise database credentials) ko build-time PAR hi prevent karta hai.
HTTP methods (GET, POST) export karke, ek API endpoint banata hai.
Nahi — jaise app/api/users/route.js, ek /api/users API endpoint banata hai, UI page nahi.
"use server" directive se mark kiya gaya function — client se directly call ho sakta hai, execution server PAR hoti hai.
Progressive enhancement ke saath kaam karte hain — JavaScript disabled hone PAR bhi, ek regular form submission ki tarah kaam karte hain.
Ek form ke submission state (pending) ko — loading spinners aur disabled buttons banane ke liye.
Ek UI ko IMMEDIATELY update karta hai server response ka wait kiye bina — agar action fail hoti hai, UI automatically revert ho jaata hai.
Traditional API banane ke liye — internal form submissions ke liye aksar Server Actions simpler choice hoti hai.
Locally scoped class names — har component ki styles automatically unique class names generate karti hain, naming conflicts avoid karte hue.
create-next-app setup ke DAURAN hi directly integrate kiya ja sakta hai — utility classes directly JSX mein use ki ja sakti hain.
Automatic image optimization — lazy loading (default mein), responsive sizing, aur modern format conversion (WebP/AVIF) built-in hain.
Cumulative Layout Shift (CLS) ko prevent karte hain — browser ko pehle se pata hota hai ki image kitni space legi.
Default lazy loading ko override karta hai — hero images jo immediately visible hain, unke liye use karna chahiye.
Fonts ko build-time PAR hi download karke self-host kar deta hai — runtime PAR external font server (jaise Google Fonts CDN) se request karne ki zaroorat khatam.
Font, build-time PAR hi bundle mein embedded hoti hai — extra network request ki wajah se hone waala text "jump" khatam ho jaata hai.
Har request ko actual page/route tak pahunchne se pehle intercept karta hai — redirect, rewrite, ya headers modify kiye ja sakte hain.
Edge Runtime PAR — bahut fast hai.
OAuth providers (Google, GitHub), credentials-based login, aur session management "out of the box".
Middleware se EARLY check, PLUS Server Component level PAR bhi ek check — sirf ek layer PAR rely karna risky hai.
next/headers se — Server Components aur Server Actions mein cookies read/set karne ke liye.
Cookie ko client-side JavaScript se access hone se rokta hai — XSS attacks se session tokens ko safe rakhta hai.
redirect(), browser ka URL change karta hai (visible). rewrite(), URL bar mein same rakhte hue internally ek different page serve karta hai.
Seamless deployment experience — git push karte hi automatic build/deploy, ISR/edge functions/image optimization seamlessly kaam karte hain.
Ek minimal self-contained build banata hai (sirf zaroori dependencies ke saath) — Docker images ki size significantly kam karta hai.
Build-time PAR client bundle mein embed ho jaati hain — browser mein bhi accessible hoti hain, isliye sensitive data ke liye kabhi use na karo.
Sirf server PAR — process.env.MY_SECRET sirf Server Components/Actions mein kaam karega.
LCP (Largest Contentful Paint), FID/INP (Interactivity), CLS (Layout Shift) — Google dwara define ki gayi key user-experience metrics, jo search ranking ko bhi affect karti hain.
Lightweight hai — Node.js ke saare APIs support nahi karta (jaise fs), lekin multiple geographic locations PAR deploy ho sakta hai, extremely low latency ke saath.
Ek Route Handler ya Page ko Edge Runtime PAR run karne ke liye mark karta hai.
Project-wide configuration ke liye — image domains, redirects, aur build settings jaisi cheezein isme define hoti hain.
Route groups, sirf code organization aur DIFFERENT layouts ke liye hain — URL structure ko affect nahi karte.
Ek minimal HTML — poora UI, user ke device PAR hi JavaScript se "assemble" hota hai.
Kaafi kam hota hai — data-fetching logic kabhi browser ko bheji hi nahi jaati, sirf result (HTML) bheja jaata hai.
Haan — Next.js unhe bhi initial HTML ke liye server PAR pre-render karta hai, phir client PAR hydrate karta hai interactivity ke liye.
Ek Server Action ke result (jaise validation errors) ko — form ke previous state ko maintain karte hue.
Automatically "purge" kar deta hai — sirf wohi utility classes ka CSS bundle mein jaata hai, jo actually code mein use hui hain.
Specify karta hai ki middleware kin routes PAR run hoga — REGEX-jaise patterns support karta hai.
Visually dikhata hai ki JavaScript bundle mein kaun se packages kitni space le rahe hain — large dependencies identify karne ke liye.
SSR ya dynamic features (jaise API routes) support nahi hote — sirf poori tarah static HTML/CSS/JS output generate hota hai.
Database queries jaisi non-fetch operations ko bhi cache karne deta hai — fetch() ki tarah hi caching benefits milte hain.
Ek file ko sirf Server Components mein import hone se rokta hai (jaise ek file jo window PAR depend karti hai aur server PAR crash ho jaayegi).
Second argument mein params object se — jaise page.js mein milta hai.
Self-hosted custom fonts (jaise ek company ka proprietary font) ke liye — same optimization benefits deta hai jaise Google Fonts ke liye.
CSRF (Cross-Site Request Forgery) protection — "strict" ya "lax" values se control kiya jaata hai.
Har git branch/PR ke liye ek unique preview URL automatically banate hain — team members changes ko merge se pehle hi live dekh sakte hain.