diff --git a/README.md b/README.md
index 1bf5805..ba679ab 100644
--- a/README.md
+++ b/README.md
@@ -28,6 +28,7 @@ That knowledge usually lives in private Slack threads, internal docs, and the he
| Section | What's Inside |
|---|---|
| [`react/`](react/) | React patterns, anti-patterns, and best practices |
+| [`next/`](next/) | Next patterns, anti-patterns, and best practices |
| [`typescript/`](typescript/) | TypeScript techniques, type design, and gotchas |
| [`architecture/`](architecture/) | Frontend architecture, project structure, and design decisions |
| [`performance/`](performance/) | Performance optimization strategies and measurement |
@@ -80,6 +81,7 @@ All contributions follow a consistent structure so the knowledge base stays high
```text
frontend-engineering-lab/
├── react/
+├── next/
├── typescript/
├── architecture/
├── performance/
diff --git a/next/Introduction-to-nextjs.md b/next/Introduction-to-nextjs.md
new file mode 100644
index 0000000..68b68ce
--- /dev/null
+++ b/next/Introduction-to-nextjs.md
@@ -0,0 +1,327 @@
+# Introduction to Next.js
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+## The Problem
+
+React is one of the most popular libraries for building user interfaces. It makes it easy to create reusable components and build interactive web applications.
+
+However, React focuses only on the **view layer** of an application. It doesn't provide everything required to build a complete production-ready application.
+
+When building a real-world React application, you'll often need additional tools for:
+
+- Routing
+- Data fetching
+- Search Engine Optimization (SEO)
+- Image optimization
+- Authentication
+- Server-side rendering
+- API endpoints
+- Performance optimization
+
+To add these features, developers typically install and configure multiple third-party libraries such as React Router, TanStack Query, authentication libraries, image optimization tools, and more.
+
+As your application grows, managing all these tools can become complex and time-consuming.
+
+This is where **Next.js** helps.
+
+Next.js is a React framework that provides many of these features out of the box, allowing you to focus on building your application instead of configuring your tooling.
+
+## The Solution
+
+### What is Next.js?
+
+Next.js is an open-source React framework created by **Vercel**.
+
+It extends React with features that make building modern, production-ready web applications faster and easier.
+
+Some of the core features include:
+
+- File-based routing
+- Server Components and Client Components
+- Multiple rendering strategies (SSR, SSG, ISR, CSR)
+- Built-in data fetching
+- Route Handlers for building APIs
+- Image optimization
+- Font optimization
+- Script optimization
+- Metadata API for SEO
+- TypeScript support
+- Fast Refresh
+- Production-ready build system
+
+Instead of installing and configuring many libraries yourself, Next.js provides sensible defaults and conventions that help you build scalable applications.
+
+### Creating Your First Next.js Project
+
+Create a new project using:
+
+```bash
+npx create-next-app@latest
+```
+
+or
+
+```bash
+npm create next-app@latest
+```
+
+You'll be asked a few questions during installation:
+
+```text
+✔ What is your project named?
+✔ Would you like to use TypeScript?
+✔ Would you like to use ESLint?
+✔ Would you like to use Tailwind CSS?
+✔ Would you like your code inside a src/ directory?
+✔ Would you like to use the App Router?
+✔ Would you like to use Turbopack?
+✔ Would you like to customize the import alias?
+```
+
+Navigate into your project:
+
+```bash
+cd my-next-app
+```
+
+Start the development server:
+
+```bash
+npm run dev
+```
+
+Visit:
+
+```
+http://localhost:3000
+```
+
+Your first Next.js application should now be running.
+
+### Understanding the Project Structure
+
+A typical Next.js project looks like this:
+
+```text
+my-next-app/
+
+├── app/
+│ ├── layout.tsx
+│ ├── page.tsx
+│ ├── globals.css
+│
+├── public/
+├── components/
+├── lib/
+├── next.config.ts
+├── package.json
+└── tsconfig.json
+```
+
+#### `app/`
+
+The `app` directory contains your application's routes.
+
+Each folder represents a route, and every route must contain a `page.tsx` file.
+
+Example:
+
+```text
+app/
+│
+├── page.tsx
+├── about/
+│ └── page.tsx
+└── contact/
+ └── page.tsx
+```
+
+Creates:
+
+```
+/
+/about
+/contact
+```
+
+#### `layout.tsx`
+
+A layout wraps pages and is shared across multiple routes.
+
+Instead of repeating common UI like navigation bars or footers on every page, you define them once inside a layout.
+
+Example:
+
+```tsx
+export default function RootLayout({
+ children,
+}: {
+ children: React.ReactNode;
+}) {
+ return (
+
+
{children}
+
+ );
+}
+```
+
+#### `public/`
+
+Stores static assets such as:
+
+- Images
+- Videos
+- Fonts
+- Icons
+
+Example:
+
+```text
+public/logo.png
+```
+
+Use it like this:
+
+```tsx
+
+```
+
+#### `components/`
+
+A common place to store reusable UI components.
+
+Example:
+
+```text
+components/
+ Navbar.tsx
+ Footer.tsx
+ Button.tsx
+```
+
+#### `lib/`
+
+Many developers use this folder for shared utilities such as:
+
+- API clients
+- Database functions
+- Helper functions
+- Validation schemas
+
+#### `next.config.ts`
+
+Contains project-specific Next.js configuration.
+
+### creating your first Next.js page
+
+Create the following page inside `app/page.tsx`:
+
+```tsx
+export default function Home() {
+ return
Hello, World!
;
+}
+```
+
+Visit:
+
+```
+http://localhost:3000
+```
+
+You'll see:
+
+```
+Hello, World!
+```
+
+Congratulations! You've created your first Next.js page.
+
+### Client Components vs Server Components
+
+By default, every component in the `app` directory is a **Server Component**.
+
+Server Components render on the server before being sent to the browser. They can fetch data directly and reduce the amount of JavaScript sent to the client.
+
+If a component needs browser features such as:
+
+- `useState`
+- `useEffect`
+- Event handlers (`onClick`)
+- Browser APIs (`localStorage`, `window`, etc.)
+
+you must mark it as a **Client Component** using the `"use client"` directive.
+
+Example:
+
+```tsx
+"use client";
+
+import { useState } from "react";
+
+export default function Counter() {
+ const [count, setCount] = useState(0);
+
+ return ;
+}
+```
+
+#### What about `"use server"`?
+
+Unlike `"use client"`, you usually **do not need** to add `"use server"` to regular Server Components because they are server-rendered by default.
+
+The `"use server"` directive is primarily used to define **Server Actions**, allowing functions to execute securely on the server.
+
+Example:
+
+```tsx
+"use server";
+
+export async function createPost(formData: FormData) {
+ // Save data to the database
+}
+```
+
+### Why Developers Like Next.js
+
+Next.js simplifies modern web development by providing:
+
+- Better SEO through server rendering
+- Built-in routing
+- Optimized images and fonts
+- Fast page loading
+- API development with Route Handlers
+- Automatic code splitting
+- Streaming and Server Components
+- Great developer experience
+
+These features make it an excellent choice for:
+
+- Blogs
+- Portfolios
+- Company websites
+- SaaS products
+- Dashboards
+- E-commerce applications
+- Marketing websites
+
+## Tradeoffs
+
+- **When this shines:** Best for Production-ready React applications, SEO-focused websites, Large-scale applications, E-commerce, SaaS products, and Content-heavy websites.
+- **When to avoid it:** Small React learning projects, Simple single-page applications that don't require SEO or server rendering, and Teams that only need client-side rendering.
+- **What you give up:** More concepts to learn than React alone, Different rendering strategies (SSR, SSG, ISR, CSR, RSC), A framework with conventions and opinions and Slightly steeper learning curve
+
+## Key Takeaways
+
+- React is a library for building user interfaces, while Next.js is a full React framework for building production-ready applications.
+- Next.js provides routing, rendering strategies, data fetching, optimization, and API capabilities out of the box.
+- The App Router uses file-based routing, making navigation simple and intuitive.
+- Components are Server Components by default; use `"use client"` only when browser interactivity is required.
+- Next.js helps developers build faster, more scalable, and SEO-friendly applications with minimal configuration.
+
+## References
+
+- [https://nextjs.org/docs](https://nextjs.org/docs)
+- [https://nextjs.org/learn](https://nextjs.org/learn)
+- [https://react.dev](https://react.dev)
diff --git a/next/README.md b/next/README.md
new file mode 100644
index 0000000..a4297af
--- /dev/null
+++ b/next/README.md
@@ -0,0 +1,29 @@
+# Next
+
+Next patterns, anti-patterns, and best practices from production codebases.
+
+## Articles
+
+- [Introduction to nextjs](./introduction-to-nextjs.md)
+- [Routing Mechanism in Next.js](./routing-mechanism-in-nextjs.md)
+- [Custom Not Found (404) Pages in Next.js](./custom-not-found-pages-in-nextjs.md)
+- [File Colocation in Next](./file-colocation-in-next.md)
+- [Private Folder in Next](./private-folder.md)
+- [Understanding Layout in Next](./understanding-layout-in-nextjs.md)
+- [Using Metadata in Next](./using-metadata-in-next.md)
+- [Templates file in Next](./templates-file-in-next.md)
+- [Loading UI in Next](./loading-UI-in-next.md)
+- [Error Handling in Next.js](./error-handling-in-nextjs.md)
+
+
+## Ideas for Contributions (but not limited to)
+
+- Component composition patterns (compound components, render props, slots)
+- Error boundaries in practice
+- Custom hooks: when to extract, when not to
+- Server components and data fetching strategies
+- Re-render debugging and `memo`/`useMemo` done right
+- Form handling patterns at scale
+- Anti-patterns you've seen (and fixed) in real codebases
+
+See [CONTRIBUTING.md](../CONTRIBUTING.md) for the article format, and copy [the template](../templates/article-template.md) to get started.
diff --git a/next/custom-not-found-pages-in-nextjs.md b/next/custom-not-found-pages-in-nextjs.md
new file mode 100644
index 0000000..2c5447d
--- /dev/null
+++ b/next/custom-not-found-pages-in-nextjs.md
@@ -0,0 +1,184 @@
+# Custom Not Found (404) Pages in Next.js
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+## The Problem
+
+Users don't always navigate to valid pages. They might:
+
+- Enter an incorrect URL.
+- Click an outdated bookmark.
+- Follow a broken link from another website.
+- Request a resource that no longer exists.
+
+In a traditional React application, you typically configure a catch-all (`*`) route in React Router to display a custom 404 page.
+
+In Next.js, this is handled differently. The framework automatically detects unknown routes and renders a **404 Not Found** page. While the default page works, most applications need a custom experience that matches their branding and helps users navigate back to useful content.
+
+## The Solution
+
+The Next.js App Router provides built-in support for custom **404 Not Found** pages. You can:
+
+- Create a global `not-found.tsx` page.
+- Display a custom 404 page for specific route segments.
+- Programmatically show a 404 page using the `notFound()` function when requested data doesn't exist.
+- This article applies to the Next.js App Router (app/), not the Pages Router (pages/).
+
+### Global Not Found Page
+
+Create a not-found.tsx file inside the app directory to define a custom global 404 page.
+
+```
+app/
+├── layout.tsx
+├── page.tsx
+└── not-found.tsx
+```
+
+```tsx
+// app/not-found.tsx
+
+import Link from "next/link";
+
+export default function NotFound() {
+ return (
+
+
404
+
+
+ Sorry, the page you're looking for doesn't exist.
+
+
+
+ Go back home
+
+
+ );
+}
+```
+
+Whenever a user visits a route that doesn't exist, Next.js automatically renders this page.
+
+### Handling Missing Resources with notFound()
+
+Sometimes the route exists, but the requested resource does not.
+
+For example:
+
+- `/blog/nextjs-routing` → exists ✅
+- `/blog/random-post` → does not exist ❌
+
+Instead of showing an error or blank page, you can render the 404 page by calling `notFound()`.
+
+```tsx
+// app/blog/[slug]/page.tsx
+
+import { notFound } from "next/navigation";
+
+export default async function BlogPost({ params }) {
+ const post = await getPost(params.slug);
+
+ if (!post) {
+ notFound();
+ }
+
+ return {post.title};
+}
+```
+
+Calling notFound() throws a special Next.js error that immediately stops rendering the current page and displays the nearest not-found.tsx, if post does not exist.
+
+### Route-Specific Not Found Pages
+
+In larger applications, different sections may require their own customized 404 experience.
+
+For example:
+
+```
+app/
+├── dashboard/
+│ ├── page.tsx
+│ └── not-found.tsx
+├── blog/
+│ ├── page.tsx
+│ └── not-found.tsx
+└── not-found.tsx
+```
+
+If `notFound()` is called inside the `dashboard` route, Next.js searches for the closest not-found.tsx in the current route segment. If none exists, it falls back to the global app/not-found.tsx:
+
+```
+app/dashboard/not-found.tsx
+```
+
+instead of the global one.
+
+This allows different parts of your application to have customized error messages and navigation.
+
+Example:
+
+```tsx
+// app/dashboard/not-found.tsx
+
+import Link from "next/link";
+
+export default function DashboardNotFound() {
+ return (
+
+
Dashboard page not found
+
+ Return to Dashboard
+
+ );
+}
+```
+
+### Why Use `notFound()` Instead of Returning JSX?
+
+#### Before
+
+```tsx
+if (!user) {
+ return
User not found
;
+}
+```
+
+The URL still returns a successful page (HTTP 200), which isn't ideal for SEO or APIs.
+
+#### After
+
+```tsx
+import { notFound } from "next/navigation";
+
+if (!user) {
+ notFound();
+}
+```
+
+Next.js returns the correct **404 HTTP status** while displaying your custom 404 page.
+
+This improves:
+
+- SEO
+- User experience
+- Search engine indexing
+- Proper HTTP semantics
+
+## Tradeoffs
+
+- **When this shines:** Building production applications where users may request invalid routes or missing resources.
+- **When to avoid it:** Don't use `notFound()` for permission or authentication errors. Those should return an authorization page or redirect users to sign in.
+- **What you give up:** Calling `notFound()` immediately stops rendering the current page, so no additional code after it will execute.
+
+## Key Takeaways
+
+- Next.js automatically provides a 404 page for routes that don't exist.
+- Create `app/not-found.tsx` to customize the global 404 page.
+- Use `notFound()` from `next/navigation` when requested data cannot be found.
+- Route segments can have their own `not-found.tsx` files for customized experiences.
+- Using `notFound()` returns the proper HTTP 404 status, improving SEO and user experience.
+
+## References
+
+- [api-reference/file-conventions/not-found](https://nextjs.org/docs/app/api-reference/file-conventions/not-found)
+- [api-reference/functions/not-found](https://nextjs.org/docs/app/api-reference/functions/not-found)
diff --git a/next/error-handling-in-nextjs.md b/next/error-handling-in-nextjs.md
new file mode 100644
index 0000000..684646c
--- /dev/null
+++ b/next/error-handling-in-nextjs.md
@@ -0,0 +1,292 @@
+# Error Handling in Next.js
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+## The Problem
+
+Applications don't always work as expected.
+
+A network request may fail, a database query may throw an exception, a component may crash because of unexpected data, or a third-party service may become unavailable.
+
+Without proper error handling:
+
+- Users see a blank page or an unhelpful browser error.
+- A single broken component can crash an entire page.
+- Developers have little information for debugging.
+- Users cannot recover without manually refreshing the page.
+
+In traditional React applications, developers typically create **Error Boundaries** manually to catch rendering errors. While this works, it requires extra configuration and careful placement throughout the application.
+
+Next.js simplifies this process by providing **file-based error handling**. By creating special files such as `error.tsx` and `global-error.tsx`, you can display friendly error pages, isolate failures to specific route segments, and even allow users to recover without leaving the page.
+
+## The Solution
+
+The App Router provides built-in support for handling errors at different levels of your application.
+
+There are three primary ways to handle errors:
+
+- Recovering from route errors using `error.tsx`
+- Handling errors in nested routes
+- Handling application-wide failures with `global-error.tsx`
+
+### Recovering from Errors
+
+To handle errors for a specific route segment, create an `error.tsx` file inside that route.
+
+```
+app
+│── dashboard
+│ ├── page.tsx
+│ ├── error.tsx
+│ └── loading.tsx
+```
+
+When an error occurs inside `dashboard/page.tsx` or any of its child components, Next.js automatically renders `error.tsx` instead of crashing the entire application.
+
+#### Example
+
+```tsx
+// app/dashboard/error.tsx
+
+"use client";
+
+export default function Error({
+ error,
+ reset,
+}: {
+ error: Error;
+ reset: () => void;
+}) {
+ return (
+
+
Something went wrong!
+
+
{error.message}
+
+
+
+ );
+}
+```
+
+#### Why `"use client"`?
+
+Error components must be **Client Components** because they:
+
+- Receive the `error` object
+- Use the `reset()` function
+- Handle user interactions like button clicks
+
+Without `"use client"`, the component cannot access these features.
+
+---
+
+#### The `error` object
+
+The `error` parameter contains information about the failure.
+
+```tsx
+console.log(error.message);
+```
+
+Example output:
+
+```
+Failed to fetch data
+```
+
+During development, the error contains the full stack trace.
+
+In production, Next.js intentionally hides sensitive details to improve security.
+
+
+
+#### Recovering with `reset()`
+
+One of the best features of `error.tsx` is the `reset()` function.
+
+Instead of forcing users to reload the browser, `reset()` attempts to re-render the failed route.
+
+```tsx
+
+```
+
+This is useful for temporary problems such as:
+
+- Network failures
+- API timeouts
+- Temporary server issues
+
+---
+
+### Handling Errors in Nested Routes
+
+Error boundaries are **nested**.
+
+Each `error.tsx` only catches errors inside its own route segment and child segments.
+
+Example folder structure:
+
+```
+app
+│── dashboard
+│ ├── error.tsx
+│ ├── page.tsx
+│ └── settings
+│ ├── page.tsx
+│ └── error.tsx
+```
+
+Here:
+
+- `dashboard/error.tsx` handles errors inside the dashboard.
+- `settings/error.tsx` handles only errors inside the settings page.
+
+If an error occurs in:
+
+```
+app/dashboard/settings/page.tsx
+```
+
+Next.js first looks for:
+
+```
+settings/error.tsx
+```
+
+If none exists, it bubbles up to:
+
+```
+dashboard/error.tsx
+```
+
+This allows different parts of your application to display customized error UIs.
+
+---
+
+#### Example
+
+```
+Dashboard
+├── Analytics
+├── Users
+└── Settings
+```
+
+If the Settings page crashes, only the Settings section displays its error screen.
+
+The rest of the Dashboard continues working normally.
+
+This improves the user experience because one broken feature does not take down the entire application.
+
+---
+
+### Handling Global Errors
+
+Some errors happen outside individual routes.
+
+For example:
+
+- The root layout crashes.
+- The HTML document cannot render.
+- A shared provider throws an exception.
+- An application-wide component fails.
+
+For these cases, create a `global-error.tsx` file.
+
+```
+app
+│── global-error.tsx
+│── layout.tsx
+│── page.tsx
+```
+
+Unlike `error.tsx`, this file replaces the **entire application**.
+
+---
+
+#### Example
+
+```tsx
+// app/global-error.tsx
+
+"use client";
+
+export default function GlobalError({
+ error,
+ reset,
+}: {
+ error: Error;
+ reset: () => void;
+}) {
+ return (
+
+
+
Application Error
+
+
{error.message}
+
+
+
+
+ );
+}
+```
+
+Notice that the component returns both:
+
+```tsx
+
+ ...
+
+```
+
+Since this component replaces the entire application, it must render the root HTML elements.
+
+---
+
+### Throwing an Error
+
+Errors can be thrown manually.
+
+```tsx
+export default async function Dashboard() {
+ throw new Error("Failed to load dashboard");
+
+ return
Dashboard
;
+}
+```
+
+Next.js automatically displays the nearest `error.tsx`.
+
+### Best Practices
+
+- Keep error messages simple and user-friendly.
+- Log errors to monitoring services like Sentry or LogRocket for debugging.
+- Use `reset()` for recoverable errors such as failed network requests.
+- Create nested `error.tsx` files for independent sections of large applications.
+- Reserve `global-error.tsx` for failures that affect the entire application.
+- Never expose sensitive server details or stack traces to users in production.
+
+## Tradeoffs
+
+Consider the following:
+
+- **When this shines:** Large applications with multiple route segments. Applications that depend on APIs or databases. Dashboards and admin panels where isolated failures improve user experience. Production applications that require graceful error recovery.
+
+- **When to avoid it:** Very small applications where a single error boundary is sufficient. Components that can safely handle errors with local conditional rendering instead of throwing exceptions.
+
+- **What you give up:** Additional files (`error.tsx`, `global-error.tsx`) to maintain.Errors in event handlers (such as button clicks) are **not** caught by route error boundaries and should be handled using `try...catch`. Developers still need proper logging and monitoring to diagnose production issues.
+
+## Key Takeaways
+
+- Next.js provides built-in file-based error handling using `error.tsx` and `global-error.tsx`.
+- `error.tsx` catches errors for a route segment and its children without crashing the rest of the application.
+- Use the `reset()` function to let users retry rendering after a recoverable error.
+- Nested routes can have their own error boundaries, allowing failures to be isolated to specific sections.
+- Use `global-error.tsx` to handle application-wide failures that affect the root layout or entire app.
+
+## References
+
+- [https://nextjs.org/docs/app/building-your-application/routing/error-handling](https://nextjs.org/docs/app/building-your-application/routing/error-handling)
+- [https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary)
diff --git a/next/file-colocation-in-next.md b/next/file-colocation-in-next.md
new file mode 100644
index 0000000..5512f06
--- /dev/null
+++ b/next/file-colocation-in-next.md
@@ -0,0 +1,178 @@
+# File Colocation in Next.js
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+## The Problem
+
+As an application grows, organizing files becomes increasingly difficult. In a traditional React project, components, hooks, styles, utilities, and tests are often grouped by file type.
+
+For example:
+
+```text
+src/
+├── components/
+│ ├── Button.tsx
+│ ├── ProductCard.tsx
+├── hooks/
+│ ├── useProducts.ts
+├── styles/
+│ ├── product.css
+├── utils/
+│ ├── formatPrice.ts
+└── pages/
+ ├── products.tsx
+```
+
+While this structure works, finding everything related to a single feature can become frustrating. Every time you work on the product page, you may need to jump between several folders.
+
+As projects become larger, this scattered structure makes development slower and maintenance more difficult.
+
+## The Solution
+
+Next.js App Router introduces **file colocation**, a pattern that allows you to keep files related to a route together.
+
+Instead of organizing your project by file type, you organize it by **feature** or **route**.
+
+The App Router only treats specific files as routes or special files, such as:
+
+- `page.tsx`
+- `layout.tsx`
+- `loading.tsx`
+- `error.tsx`
+- `not-found.tsx`
+- `route.ts`
+
+Every other file inside the folder is ignored by the routing system, allowing you to colocate components, hooks, utilities, styles, tests, and other supporting files next to the page that uses them.
+
+### How File Colocation Works
+
+Suppose you're building a dashboard.
+
+Instead of placing every component inside a global `components` folder. Your folder might look like this:
+
+```text
+app/
+└── dashboard/
+ ├── page.tsx
+ ├── layout.tsx
+ ├── loading.tsx
+ ├── UserCard.tsx
+ ├── Sidebar.tsx
+ ├── useDashboard.ts
+ ├── dashboard.css
+ ├── formatDate.ts
+ └── dashboard.test.tsx
+```
+
+Only these files become part of Next.js routing:
+
+- `page.tsx`
+- `layout.tsx`
+- `loading.tsx`
+
+The remaining files are simply supporting files that can be imported where needed.
+
+```tsx
+// app/dashboard/page.tsx
+
+import UserCard from "./UserCard";
+import Sidebar from "./Sidebar";
+
+export default function DashboardPage() {
+ return (
+ <>
+
+
+ >
+ );
+}
+```
+
+Since `UserCard.tsx` is only used by the dashboard page, keeping it inside the same folder makes the project easier to understand.
+
+### Colocate Shared vs Route-Specific Files
+
+A common question is:
+
+> **Should every component be colocated?**
+
+Not necessarily.
+
+#### Colocate files when they belong to one route
+
+```text
+app/
+└── products/
+ ├── page.tsx
+ ├── ProductCard.tsx
+ └── ProductFilter.tsx
+```
+
+If `ProductCard` is only used on the products page, keeping it inside the route folder is a great choice.
+
+#### Move shared files outside the route
+
+If multiple routes need the same component, place it in a shared folder.
+
+```text
+components/
+├── Button.tsx
+├── Navbar.tsx
+└── Modal.tsx
+```
+
+These components can then be imported anywhere in the application.
+
+A good rule of thumb is:
+
+- **Used in one route?** Colocate it.
+- **Used in multiple routes?** Move it to a shared location.
+
+### Benefits of File Colocation
+
+- Easier Navigation: Everything related to a feature is located in one folder, reducing the time spent searching for files.
+- Better Maintainability: Developers can quickly understand a feature without exploring unrelated parts of the project.
+- Better Scalability: As your application grows, each feature remains self-contained, making it easier to modify or remove.
+- Cleaner Imports: Because related files are close together, imports become shorter.
+
+```tsx
+import UserCard from "./UserCard";
+import useDashboard from "./useDashboard";
+```
+
+instead of
+
+```tsx
+import UserCard from "@/components/dashboard/UserCard";
+import useDashboard from "@/hooks/dashboard/useDashboard";
+```
+
+### Best Practices
+
+- Keep route-specific files inside the route folder.
+- Extract components to a shared folder only when multiple routes need them.
+- Avoid placing every component in a global `components` directory by default.
+- Keep helper functions, custom hooks, styles, and tests close to the feature that uses them.
+- Don't over-colocate. If a file becomes widely reused, move it to a shared location.
+
+## Tradeoffs
+
+File colocation has advantages and limitations.
+
+- **When this shines:** Large applications with many routes where keeping feature-related files together improves maintainability and developer productivity.
+- **When to avoid it:** For utilities or UI components shared across many routes. Duplicating shared code in multiple route folders can make maintenance harder.
+- **What you give up:** You may end up with more files inside a single route folder, so it's important to keep the folder organized and extract reusable code when appropriate.
+
+## Key Takeaways
+
+- File colocation means keeping route-specific components, hooks, styles, and utilities alongside the route that uses them.
+- In the App Router, only special files like `page.tsx`, `layout.tsx`, `loading.tsx`, and `error.tsx` affect routing; other files are ignored by the router.
+- Colocation makes features easier to navigate, understand, and maintain.
+- Shared components should live in a common directory, while route-specific code should stay with its route.
+- Organizing by feature instead of file type helps Next.js applications scale more effectively.
+
+## References
+
+- Next.js App Router documentation: [https://nextjs.org/docs/app](https://nextjs.org/docs/app)
+- Project Organization: [https://nextjs.org/docs/app/getting-started/project-structure](https://nextjs.org/docs/app/getting-started/project-structure)
+- Routing Fundamentals: [https://nextjs.org/docs/app/building-your-application/routing](https://nextjs.org/docs/app/building-your-application/routing)
diff --git a/next/loading-UI-in-next.md b/next/loading-UI-in-next.md
new file mode 100644
index 0000000..280689a
--- /dev/null
+++ b/next/loading-UI-in-next.md
@@ -0,0 +1,190 @@
+# Loading UI in Next.js
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+# Loading UI in Next.js
+
+## The Problem
+
+Modern web applications often fetch data from APIs, databases, or external services before a page can be displayed. Depending on network speed or server response time, users may have to wait several seconds before seeing the page.
+
+Without a loading state, users are presented with a blank screen or an unresponsive interface, making the application feel slow or broken.
+
+In traditional React applications, developers typically manage loading states manually using `useState`, `useEffect`, and conditional rendering.
+
+```tsx
+const [loading, setLoading] = useState(true);
+
+if (loading) {
+ return ;
+}
+```
+
+As applications grow, manually managing loading states for every page becomes repetitive and difficult to maintain.
+
+The Next.js App Router solves this problem with the **`loading.tsx` convention**, allowing you to define loading interfaces for routes without writing extra loading state logic.
+
+# The Solution
+
+In the App Router, placing a `loading.tsx` file inside a route folder automatically creates a loading UI for that route.
+
+Whenever the page is waiting for server-rendered data or asynchronous components to finish rendering, Next.js instantly displays the loading component.
+
+For example:
+
+```
+app/
+│
+├── dashboard/
+│ ├── page.tsx
+│ └── loading.tsx
+```
+
+When a user visits `/dashboard`, Next.js behaves like this:
+
+1. Navigation starts.
+2. `loading.tsx` is rendered immediately.
+3. `page.tsx` loads in the background.
+4. The loading UI is automatically replaced with the completed page.
+
+No additional state management is required.
+
+### Creating a Loading UI
+
+Create a `loading.tsx` file in the route folder.
+
+```tsx
+// app/dashboard/loading.tsx
+
+export default function Loading() {
+ return
Loading dashboard...
;
+}
+```
+
+Your page can then fetch data normally.
+
+```tsx
+// app/dashboard/page.tsx
+
+async function getUsers() {
+ const res = await fetch("https://jsonplaceholder.typicode.com/users");
+
+ return res.json();
+}
+
+export default async function DashboardPage() {
+ const users = await getUsers();
+
+ return (
+
+
Dashboard
+
+ {users.map((user: any) => (
+
{user.name}
+ ))}
+
+ );
+}
+```
+
+While `getUsers()` is fetching data, users will automatically see the loading component.
+
+### Route-Level Loading
+
+Each route can have its own loading UI.
+
+```
+app/
+│
+├── dashboard/
+│ ├── loading.tsx
+│ └── page.tsx
+│
+├── profile/
+│ ├── loading.tsx
+│ └── page.tsx
+```
+
+Visiting `/dashboard` displays the dashboard loading screen.
+
+Visiting `/profile` displays the profile loading screen.
+
+Each loading UI is isolated to its own route.
+
+### Designing Better Loading Screens
+
+A loading screen doesn't have to be plain text.
+
+You can display:
+
+- Skeleton placeholders
+- Spinners
+- Animated cards
+- Placeholder avatars
+- Loading tables
+- Progress indicators
+
+Example:
+
+```tsx
+// app/dashboard/loading.tsx
+
+export default function Loading() {
+ return (
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+Skeleton loaders provide a better user experience because they preview the page layout while content is loading.
+
+### How `loading.tsx` Works
+
+The `loading.tsx` file is automatically wrapped in a React Suspense boundary by Next.js.
+
+Conceptually, Next.js does something similar to:
+
+```tsx
+}>
+
+
+```
+
+This means you don't need to manually add a Suspense boundary for route-level loading. Next.js handles it automatically.
+
+### Best Practices
+
+- Keep loading screens lightweight so they render immediately.
+- Use skeleton loaders instead of generic spinners when possible.
+- Make the loading layout resemble the final page to reduce perceived waiting time.
+- Avoid fetching data inside `loading.tsx`; it should only display placeholder content.
+- Create route-specific loading screens rather than using the same loader everywhere.
+
+## Tradeoffs
+
+- **When this shines:** Loading server-rendered pages, Displaying immediate feedback during route navigation, Building applications with streamed content, and Reducing boilerplate by avoiding manual loading state management.
+
+- **When to avoid it:** When loading a small part of a page instead of the entire route. In such cases, use your own `Suspense` boundary around the specific component. For client-side interactions such as submitting forms or handling button clicks, where component-level loading states are more appropriate.
+- **What you give up:** `loading.tsx` only applies to route segments, not arbitrary components. It doesn't replace all loading states; you'll still manage loading manually for client-side interactions and mutations.
+
+## Key Takeaways
+
+- `loading.tsx` provides automatic route-level loading UI in the Next.js App Router.
+- Next.js displays `loading.tsx` immediately while the corresponding page is rendering or fetching data.
+- Every route segment can define its own loading experience by adding a `loading.tsx` file.
+- `loading.tsx` is automatically wrapped in a React Suspense boundary.
+- Skeleton loaders usually provide a better user experience than simple text or spinner loaders.
+
+## References
+
+- [Next.js App Router Documentation](https://nextjs.org/docs/app)
+- [Next.js Loading UI and Streaming Documentation](https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming)
+- [React Suspense Documentation](https://react.dev/reference/react/Suspense)
diff --git a/next/private-folder.md b/next/private-folder.md
new file mode 100644
index 0000000..99432b8
--- /dev/null
+++ b/next/private-folder.md
@@ -0,0 +1,107 @@
+# Private Folder in Next.js
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+## The Problem
+
+As your Next.js application grows, the `app` directory can become cluttered with files that are only meant to support a route. These may include:
+
+- Utility functions
+- Data fetching helpers
+- Validation schemas
+- Constants
+- Custom hooks
+- Internal components
+
+Since the App Router creates routes based on the file system, it's natural to wonder whether adding more folders will accidentally create new routes.
+
+For example, you might organize your project like this:
+
+```text
+app/
+├── dashboard/
+│ ├── page.tsx
+│ ├── utils/
+│ ├── hooks/
+│ └── components/
+```
+
+Although folders without special files (`page.tsx`, `layout.tsx`, `route.ts`, etc.) don't become routes, Next.js provides an even clearer way to indicate that a folder contains implementation details that should never be treated as part of the routing structure.
+
+This is where **Private Folders** come in.
+
+## The Solution
+
+A **Private Folder** is a folder whose name begins with an underscore (`_`).
+
+```text
+app/
+└── dashboard/
+ ├── page.tsx
+ ├── _lib/
+ ├── _components/
+ └── _hooks/
+```
+
+Folders prefixed with `_` are ignored by the Next.js routing system. They exist purely for organizing code.
+
+Private folders help communicate that their contents are **internal implementation details** for a specific route or feature.
+
+### Why use Private Folders?
+
+Private folders provide several benefits:
+
+- Keep route-specific code close to the route that uses it.
+- Clearly separate implementation details from route segments.
+- Prevent accidental route creation.
+- Improve project organization as applications grow.
+- Make it easier for other developers to understand which files are intended for reuse and which are local to a feature.
+
+### Example
+
+Suppose you have a dashboard page that needs helper functions and validation logic.
+
+```text
+app/
+└── dashboard/
+ ├── page.tsx
+ ├── _lib/
+ │ ├── fetch-users.ts
+ │ └── format-date.ts
+ └── _components/
+ └── UserTable.tsx
+```
+
+You can import files normally:
+
+```tsx
+import { fetchUsers } from "./_lib/fetch-users";
+import { UserTable } from "./_components/UserTable";
+
+export default async function DashboardPage() {
+ const users = await fetchUsers();
+
+ return ;
+}
+```
+
+Even though `_lib` and `_components` are inside the `app` directory, they **do not become routes**.
+
+## Tradeoffs
+
+- **When this shines:** Large applications where each route has its own helpers, components, hooks, or business logic.
+- **When to avoid it:** Very small projects where adding many folders creates unnecessary complexity.
+- **What you give up:** Route-specific code becomes less reusable. If multiple routes need the same utilities, move them to a shared location like `lib/` or `components/` instead of duplicating them in multiple private folders.
+
+## Key Takeaways
+
+- A **Private Folder** is any folder whose name starts with an underscore (`_`).
+- Private folders are ignored by the Next.js routing system and never become routes.
+- Use folders like `_lib`, `_components`, and `_hooks` to organize route-specific implementation details.
+- Keeping implementation code close to the route improves maintainability and project structure.
+- Shared code should live outside private folders in common directories such as `lib/` or `components/`.
+
+## References
+
+- [app/building-your-application/routing/colocation](https://nextjs.org/docs/app/building-your-application/routing/colocation)
+- [nextjs.org/docs/app](https://nextjs.org/docs/app)
diff --git a/next/routing-mechanism-in-nextjs.md b/next/routing-mechanism-in-nextjs.md
new file mode 100644
index 0000000..1517a72
--- /dev/null
+++ b/next/routing-mechanism-in-nextjs.md
@@ -0,0 +1,463 @@
+# Routing Mechanism in Next
+
+> **Topic:** Next.js · **Level:** Beginner · **Author:** [@geliettech](https://github.com/geliettech)
+
+## The Problem
+
+Navigation is one of the core building blocks of every web application. Whether you're building a blog, e-commerce platform, dashboard, or social media application, users need a way to move between pages seamlessly.
+
+In traditional React applications, developers often have to install and configure third-party routing libraries like React Router. They also need to manually define routes, handle nested layouts, manage dynamic URLs, and implement navigation logic.
+
+Next.js simplifies all of this by providing a **file-based routing system**. Simply creating folders and files inside the `app` directory automatically generates application routes, making routing faster, more intuitive, and easier to maintain.
+
+Understanding how routing works in Next.js allows you to:
+
+- Build scalable applications with clean URL structures.
+- Create dynamic pages from database content.
+- Share layouts across multiple pages.
+- Navigate between pages without full-page reloads.
+- Organize large applications more effectively.
+
+## The Solution
+
+Next.js uses **file-system routing**, meaning the folder and file structure inside the `app` directory defines your application's routes automatically.
+
+```
+app/
+├── page.tsx
+├── about/
+│ └── page.tsx
+├── blog/
+│ └── page.tsx
+```
+
+Produces:
+
+```
+/ -> Home
+/about -> About
+/blog -> Blog
+```
+
+### Routing
+
+Every route in the App Router is created by adding a `page.tsx` file inside a folder.
+
+Example:
+
+```
+app/
+├── page.tsx
+├── about/
+│ └── page.tsx
+├── contact/
+│ └── page.tsx
+```
+
+```tsx
+// app/about/page.tsx
+
+export default function AboutPage() {
+ return