1f:I[31853,["/_next/static/immutable/chunks/2peiblsc-6rfd.js","/_next/static/immutable/chunks/03ldrz4np9p02.js","/_next/static/immutable/chunks/151v68cy9jntc.js","/_next/static/immutable/chunks/1thuwnronvqv-.js","/_next/static/immutable/chunks/1akm3wh7wpekt.js","/_next/static/immutable/chunks/0m7ndiic1i5e6.js"],"default"] 20:I[1744,["/_next/static/immutable/chunks/2peiblsc-6rfd.js","/_next/static/immutable/chunks/03ldrz4np9p02.js","/_next/static/immutable/chunks/151v68cy9jntc.js","/_next/static/immutable/chunks/1thuwnronvqv-.js","/_next/static/immutable/chunks/1akm3wh7wpekt.js","/_next/static/immutable/chunks/0m7ndiic1i5e6.js"],"default"] 21:T712,

SEO Benefits: Search engines have an easier time crawling and indexing content in HTML files. With SSR, search engines can quickly access the fully-rendered content, which can improve search engine rankings.
Improved Initial Page Load Time: Since the server sends a fully-rendered page to the client, the user can see the content sooner. This can lead to better perceived performance, especially on slower networks.
Better Social Sharing: When you share a link on social media platforms, the platform often fetches a preview of the page. With SSR, the platform can easily access the fully-rendered HTML, ensuring accurate previews.
Accessibility and Performance on Low-Powered Devices: Devices with limited processing power, like older smartphones or IoT devices, may struggle with heavy client-side rendering. SSR can provide a better user experience on such devices.
Avoidance of Flash of Unstyled Content (FOUC): With client-side rendering, there's a brief moment where the page might appear unstyled until the JavaScript loads and applies the styles. SSR helps avoid this FOUC.
Easier Caching and CDN Integration: Fully-rendered HTML can be easily cached, which improves performance and reduces the load on servers. CDNs can also cache the HTML content.

22:T405,

Fast Initial Load: CSR can provide a fast initial load time, especially for smaller applications. Only essential HTML, CSS, and JavaScript are sent from the server.
Smooth User Experience: Once the initial load is complete, interactions are fast and smooth. Changes in the UI can happen instantly without requiring full page reloads because of SPA.
Rich Interactivity: CSR allows for highly interactive web applications with dynamic content updates based on user actions.
Better for Web Applications: CSR is well-suited for web applications where a lot of the content and interactivity is generated dynamically based on user input or API calls.

23:Ta22,

Metric / Feature	CSR	SSR	SSG
Initial Page Load Speed	Slow (Waiting for JS to download & run)	Fast (HTML arrives completed)	Blazing Fast (Served instantly via edge CDN)
Data Freshness	Real-time (Fetched on demand)	Real-time (Computed on every request)	Delayed (Fixed at build time unless using ISR)
Server Cost	Very Low (Static files served via storage)	High (Requires continuous active node server)	Very Low (Static asset hosting only)
SEO	Poor (Bots struggle to execute heavy client JS)	Excellent	Excellent

24:T5ae,

Using Browser-Only APIs During Render: Referencing window, document, or localStorage directly in your component markup (the server evaluates it as undefined, while the client evaluates the real value).
Dynamic / Non-Deterministic Data: Using new Date() or Math.random(). The server generates one timestamp during the build/request, but the client generates a slightly later timestamp during hydration.
Invalid HTML Structure: Nesting a <div> inside a <p> tag. The browser's native parser automatically forces a fix to the broken HTML structure before React can hydrate it, destroying the expected layout matching template.

25:T598,

SSR/RSC/SSG/ISR
Automatic Code Splitting
Default Routing support (without using any external library)
Image Optimisation: Images are automatically optimised for different screen sizes and devices, improving website performance and user experience. Next.js uses techniques like lazy loading, responsive images, and format detection to deliver the most efficient image experience.
API Proxying
Built in Internationalisation (i18n) Support (without using any external library)
Many options of Data Fetching (getStaticProps, getServerSideProps)
Built-in Typescript support
Turbopack Bundler (based in Rust, introduced in Next 14)
Server Actions (introduced in Next 14, allows us to run server-side code directly from React components, simplifying data mutations and user interactions without API routes in specific scenarios.)

26:T4d6,

Usage: Used in a page component to fetch data on each request, on the server-side (Server Side Rendering).
Execution: Runs on the server every time a request is made to the page.
export async function getServerSideProps / geStaticProps() {
        const response = await fetch('https://api.example.com/data'); // Fetch data from an API or database
        const data = await response.json();
        return {
                props: { data, }
        };
}
The getStaticProps & getServerSideProps function must return an object with a props key. The value of props will be passed as props to the page component.

27:T7ae,

Feature Strategy	Pages Router (Old)	App Router (Modern)
Static Generation (SSG)	getStaticProps	fetch(url) (Default behavior)
Server-Side Rendering (SSR)	getServerSideProps	fetch(url, { cache: 'no-store' })
Incremental Static (ISR)	getStaticProps + revalidate	fetch(url, { next: { revalidate: 60 } })
Dynamic Path Generation	getStaticPaths	generateStaticParams()

28:T4ff,

page.js: Makes a route publicly accessible and renders its unique UI.
layout.js: Shared shell (navbar/sidebar) across child routes; persists state on navigation.
loading.js: Automatic loading skeleton using React Suspense.
error.js: Client-side error boundary to catch runtime crashes gracefully.
not-found.js: UI displayed when notFound() is invoked or a URL does not exist.
route.js: Backend REST API endpoint handling GET, POST, PUT, or DELETE.

29:T5e3,

[slug] (Dynamic Route): Captures variable URL segments (e.g., shop/[id] → /shop/123).
[...slug] (Catch-all): Captures all nested sub-paths (e.g., docs/[...slug] → /docs/v1/auth).
(folder) (Route Group): Organizes multiple routes into groups without changing the URL path.
_folder (Private Folder): Excludes the directory and its contents from routing entirely.
@slot (Parallel Route): Displays multiple independent pages simultaneously inside one layout.
src/middleware.js: Intercepts requests on the edge for authentication, redirects, and headers.

e:["$","$L1f",null,{"initialMode":"$undefined","children":[["$","title",null,{"children":"Next Js | MNgo Interview Prep"}],["$","meta",null,{"name":"robots","content":"index, follow"}],["$","div",null,{"className":"flex flex-col flex-1 w-full min-h-0","children":[["$","$L20",null,{}],["$","$L1b",null,{"state":{"mutations":[],"queries":[{"dehydratedAt":1791337133896,"state":{"data":{"pages":[{"data":{"questions":[{"_id":"6a7c1ffd068516ed8a151de4","slug":"ssg-static-site-generation","solution":["

Entire application is fully built and compiled into flat, static HTML, CSS, and JS files at build time (during the CI/CD deployment pipeline). These static files are pushed directly to a globally distributed Content Delivery Network (CDN). When a visitor hits your URL, the CDN instantly serves the pre-built files from the edge node nearest to them.

"],"title":"SSG - Static Site Generation"},{"_id":"6a7c1ffd068516ed8a151de5","slug":"ssr-server-side-rendering","solution":["

In (SSR), a web page is rendered on the server (where the web app is deployed) and then sends the fully rendered HTML page to the client (browser), then client hydrates it (attach event listeners)

","

Advantages of Server-Side Rendering:

","$21"],"title":"SSR - Server-Side Rendering"},{"_id":"6a7c1ffd068516ed8a151de6","slug":"csr-client-side-rendering","solution":["

In CSR, the server sends a basic HTML file along with a JavaScript bundle. The JavaScript code is responsible for generating the content and rendering it in the browser (client).

","

Advantages of Client-Side Rendering:

","$22","

In practice, many applications use a combination of both Server-Side Rendering and Client-Side Rendering (CSR) for the best of both worlds. This is sometimes referred to as \"Hybrid Rendering\" or \"Universal Rendering\".

","

SSR is often used for the initial page load, while client-side rendering takes over for subsequent interactions, providing a more interactive experience.

"],"title":"CSR - Client-Side Rendering"},{"_id":"6a7c1ffd068516ed8a151de7","slug":"how-will-you-select-between-csr-ssr-and-ssg-for-your-application-what-parameters-will-you-consider","solution":["

1. When to use CSR (Client-Side Rendering)

","

Use CSR when your application is highly interactive, locked behind a login screen, and does not require search engine visibility.

","

Best Used For: Authenticated user dashboards (e.g., finance tracking, analytics portals).

","

Internal company tools and inventory management systems.
SaaS web applications (e.g., Notion, Trello) where content is dynamic but private.

","

The Rule of Thumb: If a user must log in to see the content, use CSR. Google cannot crawl gated pages anyway, so server pre-rendering is a waste of resources.

","

2. When to use SSR (Server-Side Rendering)

","

Use SSR when your data changes constantly, needs to be updated in real-time on every click, but must be indexed perfectly by search engines.

","

Best Used For:

","

E-commerce product pages with shifting prices, stock counts, or flash sales.
Social media feeds and live trend timelines (e.g., X/Twitter feed layouts).
Live news websites or sports tickers where content becomes stale within minutes.

","

The Rule of Thumb: If the data changes frequently and public users/search bots need to see the exact same fresh data instantly upon arrival, use SSR.

","

3. When to use SSG (Static Site Generation)

","

Use SSG when the content is public, rarely changes, and your primary goals are maximum speed and top-tier SEO.

","

Best Used For:

","

Company landing pages and marketing websites.
Documentation platforms and product manuals.
Personal portfolios, blogs, and case studies.

","

The Rule of Thumb: If the content is identical for every single visitor and only changes when you manually update it, pre-build it using SSG for blistering CDN speeds.

","

","$23","

"],"title":"How will you select between CSR, SSR & SSG for your application? What parameters will you consider?"},{"_id":"6a7c1ffd068516ed8a151de8","slug":"what-is-hydration-in-next-js-and-when-can-it-cause-ui-mismatches","solution":["

Hydration is the process where React takes the static HTML pre-rendered by Next.js on the server and injects JavaScript event listeners (onClick, onChange, etc) into it once it reaches the browser, making the page fully interactive.

","

What is a Hydration Mismatch?

","

When the HTML generated on the server does not perfectly match the initial HTML React calculates in the browser. When they don't align, React loses track of the DOM and throws an error.

","$24","

Fix: Use a useEffect Guard: Keep browser-dependent stuffs inside useEffect so it only triggers after the initial client hydration is complete.

"],"title":"What is hydration in Next.js and when can it cause UI mismatches?"},{"_id":"6a7c1ffd068516ed8a151de9","slug":"react-server-components","solution":["

React Server Components (RSC) is an architectural paradigm/pattern that splits React components into two categories based on where they execute: Server Components and Client Components.

","

Server Components (Default): These run exclusively on the server (during build time or on each request). They can fetch data directly from databases or file systems, and their source code is never sent to the browser, keeping the client bundle size incredibly small.
Client Components: These are marked with the \"use client\" directive. They are sent to the browser to handle user interactivity, state management (useState), and lifecycle effects (useEffect).

","

Instead of sending heavy JavaScript libraries to the browser, RSC renders static parts on the backend and sends a lightweight UI description (the RSC payload) to the client, which seamlessly merges with interactive components.

"],"title":"React Server Components"},{"_id":"6a7c1ffd068516ed8a151dea","slug":"features-of-next-js","solution":["

TL;DR:

","$25","

","

Rendering Strategies

","

SSR (Server-Side Rendering): HTML generated on every request. Best for dynamic, personalized data.
SSG (Static Site Generation): HTML generated at build time. Extremely fast, ideal for SEO and static content (blogs, marketing).
ISR (Incremental Static Regeneration): Revalidates and updates static pages in the background after deployment without full rebuilds.

","

Routing (App Router)

","

File-Based Routing: Directory structure defines URL paths (`app/dashboard/page.js` -> `/dashboard`).
Special Files:

","

• `layout.js`: Shared UI across sub-routes; preserves state on navigation.

","

• `loading.js`: Automatic loading UI using React Suspense.

","

• `error.js`: Isolated error boundaries for graceful degradation.

","

Dynamic Routes: Folders named with brackets ( `[id]` ) capture dynamic path parameters.

","

Data Fetching & Full-Stack

","

Server Actions: Direct execution of asynchronous server-side code from client forms/events without manual API endpoints.
Route Handlers: Custom backend endpoints (`GET`, `POST`, etc.) built inside `route.js` using standard Web APIs.
Middleware: Code executed before a request is completed; ideal for auth, redirects, and geo-targeting.

","

Built-In Optimizations

","

next/image: Automatic resizing, modern formats (WebP), lazy-loading, prevents Layout Shift (CLS).
next/font: Self-hosts fonts automatically; eliminates external network requests and avoids font flicker (FOUT).
Code Splitting: Splitting bundles per page so users only download necessary JS.

","

Tooling & DX

","

SWC / Turbopack: Rust-based compiler replacing Babel/Webpack for fast build times.
Fast Refresh: Instant live-editing while preserving component state.
TypeScript: Out-of-the-box support with automatic type generation for routes.

"],"title":"Features of Next.js"},{"_id":"6a7c1ffd068516ed8a151deb","slug":"next-js-streaming-ui","solution":["

Next.js Streaming allows a server to break down a webpage's HTML into chunks and send them to the browser piece-by-piece over a single HTTP connection as soon as they are ready.

","

Instead of waiting for slow database queries to load the entire page, Next.js streams the static layout (headers, sidebars) instantly, leaving loading placeholders where the slow data will eventually slide in.

","

It can be done in 2 ways

","

Component Level Streaming: By wrapping a slow React Server Component in a <Suspense> boundary, we isolate its loading state from the rest of the layout.
Page Level Streaming: We can use Next.js's file convention. By creating a loading.tsx file inside a route folder, Next.js automatically wraps the entire page.tsx in a fallback boundary.

","

Ref: https://github.com/adityasuman2025/coreJs/tree/master/nextjs

"],"title":"Next.js Streaming UI"},{"_id":"6a7c1ffd068516ed8a151dec","slug":"server-actions","solution":["

Server Actions are a feature in modern React frameworks (like Next.js) built on top of React Server Components (RSC). They allow you to define server-side functions that you can invoke directly from client-side components without manually writing an API route, handling fetch requests, or managing loading states manually.

","

Earlier: [ Client UI Form ] ──( fetch('/api/update') )──> [ Next.js API Route ] ──> [ Database ]

","

With Server Actions: [ Client UI Form ] ──( Invokes Action Directly )──> [ Server Action Function ] ──> [ Database ]

","

Instead of capturing a form submission, writing a manual fetch('/api/endpoint') call, and setting up a separate API route file to handle the request, you define a function with the \"use server\" directive to directly access the database. Next.js automatically handles the network communication behind the scenes.

","

Basic Example:

","

// A Server Component

","

export default function OrderForm() {

","

// The Server Action runs entirely on the server

","

async function createOrder(formData) {

","

\"use server\";

","

const itemId = formData.get(\"itemId\");

","

// Securely run database operations directly here

","

await db.order.create({ data: { itemId } });

","

}

","

return (

","

","

","

<button type=\"submit\">Place Order</button>

","

</form>

","

);

","

}

"],"title":"Server Actions"},{"_id":"6a7c1ffd068516ed8a151ded","slug":"getstaticpaths-getstaticprops-getserversideprops-getinitialprops-legacy-stuffs","solution":["

getStaticPaths (Before Next 14)

","

getStaticPaths is a method in Next.js that allows us to specify which paths should be pre-rendered at build time when using Static Site Generation (SSG).

","

getStaticProps (SSG - Before Next 14):

","

Usage: Used in a page component to fetch data at build time for Static Site Generation - SSG
Execution: Runs at build time, not in the client-side JavaScript bundle.
revalidate in getStaticProps: revalidate in getStaticProps, specifies how often Next.js should re-generate the static page.

","

getServerSideProps (SSR - Before Next 14):

","$26","

getInitialProps (obsolete - the ancient way - not used anymore):

","

Usage: Used in both page components and regular React components.
Execution:

","

In page components, it can run on both the server and the client. On the server, it runs during the initial request. On the client, it runs when navigating to the page using the client-side router.
In regular React components, it only runs on the client.

","

Return Value: Should return an object with the data that will be merged into the component's props.
MyComponent.getInitialProps = async () => {
        const response = await fetch('https://api.example.com/data'); // Fetch data from an API
        const data = await response.json();
        return { data };
};

","

","$27","

","

"],"title":"getStaticPaths, getStaticProps, getServerSideProps, getInitialProps (Legacy Stuffs)"},{"_id":"6a865da0068516ed8a15d018","title":"Why is next.js better for low powered devices and slow internet?","slug":"why-is-next-js-better-for-low-powered-devices-and-slow-internet","solution":["

By default, Next.js generates and renders web pages on the server side and sends ready HTML along with only the minimal JS bundle needed to make the page dynamic & interactive.

","

For slow internet: The JS bundle is very small in size, so very less code is transferred over the internet and the page content loads much faster.
For low-powered devices: Since the heavy rendering is already done on the server, very less CPU and memory of the client device are used by the browser to run and display the web page.

"]},{"_id":"6a865da0068516ed8a15d019","title":"Next.js App Routing","slug":"next-js-app-routing","solution":["

Special File Conventions

","$28","

Folder & Routing Patterns

","$29","

Data Fetching & Core Utilities

","

generateStaticParams(): Pre-computes dynamic paths at build time (SSG).
generateMetadata(): Dynamically generates <head> tags (title, description, Open Graph) for SEO.
revalidatePath() / revalidateTag(): Purges and refreshes cached data on-demand.
cookies() / headers(): Reads/modifies request cookies and headers inside server code.

"]},{"_id":"6a865da0068516ed8a15d01a","title":"What is “use client”?","slug":"what-is-use-client","solution":["

In Next.js app router by default all components are server components means they will be rendered on server i.e. page will be generated on server and then sent to the browser (client). But if we want to do client specific stuffs like accessing localStorage, window, using react hooks (useEffect, useState, etc), handling browser DOM events (like click, scroll, etc) then we write “use client” at the very top of a file.

","

When we use “use client” then also the component are pre-rendered on server to generate initial static HTML (for better FCP and SEO) and sent to the browser along with a js bundle (which includes client specific code) to hydrate it.

","

When we write “use client” at top of any component then all the child components, imports, etc used inside that component will automatically become part of the client bundle i.e they also become part of client rendered javascript, so it is best practice to keep the main root file as server rendered and using “use client” only in smallest interactive leaf file/component. This phenomenon is k/n as boundary propagation.

"]}],"pagination":{"page":1,"size":20,"totalItems":13,"totalPages":1,"hasMore":false}}}],"pageParams":[1]},"dataUpdateCount":1,"dataUpdatedAt":1791337133896,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":["getTopicQuestionApi","6a7c15e8068516ed8a151cc1"],"queryHash":"[\"getTopicQuestionApi\",\"6a7c15e8068516ed8a151cc1\"]","queryType":"infinite"}]},"children":"$L2a"}]]}]]}]

1. When to use CSR (Client-Side Rendering)

2. When to use SSR (Server-Side Rendering)

3. When to use SSG (Static Site Generation)

Rendering Strategies

Routing (App Router)

Data Fetching & Full-Stack

Built-In Optimizations

Tooling & DX